De plus en plus nombreuses sont les entreprises, qui, ayant fait le
choix de migrer de NT à Linux, on passé sur Windows 2003.
Les problpmes prinicpaux sont:
- L'absence de support
- Le nombre de bug rencontrés
- Les fonctionnalités faibles, comme les outils de gestion des
utilisateurs ou des ressources
- Le choix de la bonne distribution (plus de 300 distros !)
Il est à noter que beaucoup de serveurs de base de données restent en
activité
Il s'agit surtout des services réseaux comme Active directory, DNS et
DHCP qui sont migrés.
qui me liste tous les paquets installés. Et ça me manque tellement qu'un jour, je vais m'y plonger, et voir si je ne peux pas la coder...
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge dedans, que j'essaye de rajouter cette fonction qui me ferais bien plaisir, je suis peut-être isolé, mais pas vraiment incohérent avec le logiciel libre, non ?
Avec le logiciel libre comme bazard oui, mais le manque de cohérence et d'homogénéité qui selon toi caractérise debian, il ne peut qu'être renforcé par des modifications comme ça, ou chacun rajoute son option pour pouvoir faire les choses à sa sauce. Donc tu renforcerais exactement la tendance que tu dénonçais.
Le 26-07-2007, Thierry B. <tth@prout.stex> a écrit :
--{ SL a plopé ceci: }--
# aptitude list
qui me liste tous les paquets installés. Et ça me manque
tellement qu'un jour, je vais m'y plonger, et voir si je ne
peux pas la coder...
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la
doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge
dedans, que j'essaye de rajouter cette fonction qui me ferais bien
plaisir, je suis peut-être isolé, mais pas vraiment incohérent
avec le logiciel libre, non ?
Avec le logiciel libre comme bazard oui, mais le manque de cohérence et
d'homogénéité qui selon toi caractérise debian, il ne peut qu'être
renforcé par des modifications comme ça, ou chacun rajoute son option
pour pouvoir faire les choses à sa sauce. Donc tu renforcerais
exactement la tendance que tu dénonçais.
qui me liste tous les paquets installés. Et ça me manque tellement qu'un jour, je vais m'y plonger, et voir si je ne peux pas la coder...
Ce qui rajoutera encore une façon de faire isolée, peu visible dans la doc, et incohérente avec l'ensemble...
Donc si je prends les sources Debian d'aptitude, que je me plonge dedans, que j'essaye de rajouter cette fonction qui me ferais bien plaisir, je suis peut-être isolé, mais pas vraiment incohérent avec le logiciel libre, non ?
Avec le logiciel libre comme bazard oui, mais le manque de cohérence et d'homogénéité qui selon toi caractérise debian, il ne peut qu'être renforcé par des modifications comme ça, ou chacun rajoute son option pour pouvoir faire les choses à sa sauce. Donc tu renforcerais exactement la tendance que tu dénonçais.
Thierry B.
--{ SL a plopé ceci: }--
# aptitude list
qui me liste tous les paquets installés. Et ça me manque
exactement la tendance que tu dénonçais.
Ouais, donc je vais me contenter de poster dans le bugtrack de Debian une suggestion pour la manpage:
Si vous voulez lister les paquets installés, il faut taper la commande aptitude search "~i" | cut -b 5- qui vous fournira l'information que vous cherchez.
Oui, finalement, c'est très "Unics attitude"...
-- PEBCAK is obsolete. Use PICNIC instead. +----------------------------------------+ | "Problem In Chair, Not In Computer" | +----------------------------------------+
--{ SL a plopé ceci: }--
# aptitude list
qui me liste tous les paquets installés. Et ça me manque
exactement la tendance que tu dénonçais.
Ouais, donc je vais me contenter de poster dans le bugtrack de
Debian une suggestion pour la manpage:
Si vous voulez lister les paquets installés, il faut taper la commande
aptitude search "~i" | cut -b 5-
qui vous fournira l'information que vous cherchez.
Oui, finalement, c'est très "Unics attitude"...
--
PEBCAK is obsolete. Use PICNIC instead.
+----------------------------------------+
| "Problem In Chair, Not In Computer" |
+----------------------------------------+
qui me liste tous les paquets installés. Et ça me manque
exactement la tendance que tu dénonçais.
Ouais, donc je vais me contenter de poster dans le bugtrack de Debian une suggestion pour la manpage:
Si vous voulez lister les paquets installés, il faut taper la commande aptitude search "~i" | cut -b 5- qui vous fournira l'information que vous cherchez.
Oui, finalement, c'est très "Unics attitude"...
-- PEBCAK is obsolete. Use PICNIC instead. +----------------------------------------+ | "Problem In Chair, Not In Computer" | +----------------------------------------+
Didier Couderc
Kevin Denis writes:
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:
C'est pas pour être méchant, mais COLUMNS (et sa petite soeur LINES) sont des variables d'environnement parfaitement respectables et honorablement connues dans tout le quartier.
Même que, sur les xterm de bonne facture : Depending on your system configuration, xterm may also set the follow- ing:
COLUMNS the width of the xterm in characters (cf: "stty columns").
LINES the height of the xterm in characters (cf: "stty rows").
Même qu'elles sont mises à jour quand on redimensionne le xterm.
-- Mog
Kevin Denis <kevin@nowhere.invalid> writes:
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:
C'est pas pour être méchant, mais COLUMNS (et sa petite soeur LINES)
sont des variables d'environnement parfaitement respectables et
honorablement connues dans tout le quartier.
Même que, sur les xterm de bonne facture :
Depending on your system configuration, xterm may also set the follow-
ing:
COLUMNS
the width of the xterm in characters (cf: "stty columns").
LINES
the height of the xterm in characters (cf: "stty rows").
Même qu'elles sont mises à jour quand on redimensionne le xterm.
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:
C'est pas pour être méchant, mais COLUMNS (et sa petite soeur LINES) sont des variables d'environnement parfaitement respectables et honorablement connues dans tout le quartier.
Même que, sur les xterm de bonne facture : Depending on your system configuration, xterm may also set the follow- ing:
COLUMNS the width of the xterm in characters (cf: "stty columns").
LINES the height of the xterm in characters (cf: "stty rows").
Même qu'elles sont mises à jour quand on redimensionne le xterm.
-- Mog
Nicolas George
Didier Couderc , dans le message , a écrit :
Même que, sur les xterm de bonne facture :
Non, sur les xterm de mauvaise facture. Les xterm de bonne facture règlent la taille du terminal au niveau de la couche d'émulation du noyau.
Même qu'elles sont mises à jour quand on redimensionne le xterm.
Ce n'est pas possible, un programme ne peut pas modifier les variables d'environnement d'un autre programme.
Didier Couderc , dans le message <lsabtgl8gs.fsf@leon.dcouderc.com>, a
écrit :
Même que, sur les xterm de bonne facture :
Non, sur les xterm de mauvaise facture. Les xterm de bonne facture règlent
la taille du terminal au niveau de la couche d'émulation du noyau.
Même qu'elles sont mises à jour quand on redimensionne le xterm.
Ce n'est pas possible, un programme ne peut pas modifier les variables
d'environnement d'un autre programme.
Non, sur les xterm de mauvaise facture. Les xterm de bonne facture règlent la taille du terminal au niveau de la couche d'émulation du noyau.
Même qu'elles sont mises à jour quand on redimensionne le xterm.
Ce n'est pas possible, un programme ne peut pas modifier les variables d'environnement d'un autre programme.
Sam Hocevar
On Sat, 28 Jul 2007 19:28:45 +0000 (UTC), Nicolas George wrote:
Même qu'elles sont mises à jour quand on redimensionne le xterm.
Ce n'est pas possible, un programme ne peut pas modifier les variables d'environnement d'un autre programme.
Oh, avec ptrace() on peut faire à peu près tout ce qu'on veut. Mais sans aller jusque là, un programme (du genre xterm) peut envoyer un SIGWINCH à un autre programme (du genre bash) qui peut en faire ce qu'il veut (du genre changer ses variables d'environnement).
On Sat, 28 Jul 2007 19:28:45 +0000 (UTC), Nicolas George wrote:
Même qu'elles sont mises à jour quand on redimensionne le xterm.
Ce n'est pas possible, un programme ne peut pas modifier les variables
d'environnement d'un autre programme.
Oh, avec ptrace() on peut faire à peu près tout ce qu'on veut. Mais
sans aller jusque là, un programme (du genre xterm) peut envoyer un
SIGWINCH à un autre programme (du genre bash) qui peut en faire ce qu'il
veut (du genre changer ses variables d'environnement).
On Sat, 28 Jul 2007 19:28:45 +0000 (UTC), Nicolas George wrote:
Même qu'elles sont mises à jour quand on redimensionne le xterm.
Ce n'est pas possible, un programme ne peut pas modifier les variables d'environnement d'un autre programme.
Oh, avec ptrace() on peut faire à peu près tout ce qu'on veut. Mais sans aller jusque là, un programme (du genre xterm) peut envoyer un SIGWINCH à un autre programme (du genre bash) qui peut en faire ce qu'il veut (du genre changer ses variables d'environnement).
Sam Hocevar , dans le message <slrnfanm1n.bbl.sam+, a écrit :
Oh, avec ptrace() on peut faire à peu près tout ce qu'on veut.
Je te l'accorde.
Mais sans aller jusque là, un programme (du genre xterm) peut envoyer un SIGWINCH à un autre programme (du genre bash) qui peut en faire ce qu'il veut (du genre changer ses variables d'environnement).
Oui (enfin presque : ce n'est pas l'émulateur de terminal qui envoie le SIGWINCH, mais le noyau en réponse au redimensionnement ; sinon ça ne marcherait pas si l'UID a été changé), mais seulement s'il le veut. Et en pratique, il ne le fait pas : sur les systèmes décents, où les pseudo-terminaux fonctionnent correctement, $LINES et $COLUMNS sont des variables internes du shell, et ne s'échappent normalement pas dans l'environnement.
Sam Hocevar , dans le message <slrnfanm1n.bbl.sam+news@poulet.zoy.org>,
a écrit :
Oh, avec ptrace() on peut faire à peu près tout ce qu'on veut.
Je te l'accorde.
Mais
sans aller jusque là, un programme (du genre xterm) peut envoyer un
SIGWINCH à un autre programme (du genre bash) qui peut en faire ce qu'il
veut (du genre changer ses variables d'environnement).
Oui (enfin presque : ce n'est pas l'émulateur de terminal qui envoie le
SIGWINCH, mais le noyau en réponse au redimensionnement ; sinon ça ne
marcherait pas si l'UID a été changé), mais seulement s'il le veut. Et en
pratique, il ne le fait pas : sur les systèmes décents, où les
pseudo-terminaux fonctionnent correctement, $LINES et $COLUMNS sont des
variables internes du shell, et ne s'échappent normalement pas dans
l'environnement.
Sam Hocevar , dans le message <slrnfanm1n.bbl.sam+, a écrit :
Oh, avec ptrace() on peut faire à peu près tout ce qu'on veut.
Je te l'accorde.
Mais sans aller jusque là, un programme (du genre xterm) peut envoyer un SIGWINCH à un autre programme (du genre bash) qui peut en faire ce qu'il veut (du genre changer ses variables d'environnement).
Oui (enfin presque : ce n'est pas l'émulateur de terminal qui envoie le SIGWINCH, mais le noyau en réponse au redimensionnement ; sinon ça ne marcherait pas si l'UID a été changé), mais seulement s'il le veut. Et en pratique, il ne le fait pas : sur les systèmes décents, où les pseudo-terminaux fonctionnent correctement, $LINES et $COLUMNS sont des variables internes du shell, et ne s'échappent normalement pas dans l'environnement.
Thierry B.
--{ Sam Hocevar a plopé ceci: }--
Ce n'est pas possible, un programme ne peut pas modifier les variables d'environnement d'un autre programme.
Oh, avec ptrace() on peut faire à peu près tout ce qu'on veut. Mais sans aller jusque là, un programme (du genre xterm) peut envoyer un SIGWINCH à un autre programme (du genre bash) qui peut en faire ce qu'il veut (du genre changer ses variables d'environnement).
Je me suis même laissé dire que les programmes écrits avec ncurses
géraient très bien ce signal sans s'en rendre compte. Je n'ai en fait jamais cherché à comprendre exactement le principe, mais le SIGWINCH c'est vraiment magique.
.SH BUGS Si vous redimensionnez votre xterm, fBxxxxxxxfP se prend un SIGWINCH, et s'en va probablement visiter le pays des Slashies. Dans la pratique, il en revient très vite.
/ME adore ncurses.
-- ".COM ? Meuhnon, hé, .com, c'est pour le commerce : moi, je fais du vin. Le vin, c'est pas vraiment du commerce, c'est un métier !"
--{ Sam Hocevar a plopé ceci: }--
Ce n'est pas possible, un programme ne peut pas modifier les variables
d'environnement d'un autre programme.
Oh, avec ptrace() on peut faire à peu près tout ce qu'on veut. Mais
sans aller jusque là, un programme (du genre xterm) peut envoyer un
SIGWINCH à un autre programme (du genre bash) qui peut en faire ce qu'il
veut (du genre changer ses variables d'environnement).
Je me suis même laissé dire que les programmes écrits avec ncurses
géraient très bien ce signal sans s'en rendre compte. Je n'ai en
fait jamais cherché à comprendre exactement le principe, mais le
SIGWINCH c'est vraiment magique.
.SH BUGS
Si vous redimensionnez votre xterm, fBxxxxxxxfP se prend un SIGWINCH,
et s'en va probablement visiter le pays des Slashies. Dans la pratique,
il en revient très vite.
/ME adore ncurses.
--
".COM ? Meuhnon, hé, .com, c'est pour le commerce : moi, je fais du
vin. Le vin, c'est pas vraiment du commerce, c'est un métier !"
Ce n'est pas possible, un programme ne peut pas modifier les variables d'environnement d'un autre programme.
Oh, avec ptrace() on peut faire à peu près tout ce qu'on veut. Mais sans aller jusque là, un programme (du genre xterm) peut envoyer un SIGWINCH à un autre programme (du genre bash) qui peut en faire ce qu'il veut (du genre changer ses variables d'environnement).
Je me suis même laissé dire que les programmes écrits avec ncurses
géraient très bien ce signal sans s'en rendre compte. Je n'ai en fait jamais cherché à comprendre exactement le principe, mais le SIGWINCH c'est vraiment magique.
.SH BUGS Si vous redimensionnez votre xterm, fBxxxxxxxfP se prend un SIGWINCH, et s'en va probablement visiter le pays des Slashies. Dans la pratique, il en revient très vite.
/ME adore ncurses.
-- ".COM ? Meuhnon, hé, .com, c'est pour le commerce : moi, je fais du vin. Le vin, c'est pas vraiment du commerce, c'est un métier !"
La suppression d'une libc est un bon exercice. La debian n'est donc pas libc-recover-proof. Slack l'est. Je n'ai pas essaye les autres.
Heu, Sam t'a donné la méthode - enfin, une méthode - pour y arriver. je ne vois pas bien ce que tu veux prouver par là...
A lire Sam, la methode qu'il m'a donne permet de faire redemarrer
la debian. Mais au passage j'ai eventuellement flingue le systeme de package. Je n'appelle pas ca une methode propre pour repartir.
-- Kevin
Kevin Denis
Le 24-07-2007, Thierry B. a écrit :
D'ailleurs, tu viens de me donner une idée, là. Dans un autre post de ce fil géant, je parle de pkgtool et de la fonction[1] qui permet de voir le contenu d'un paquet installé. C'est écrit en bash/dialog, et on doit pouvoir faire un équivalent pour Debian.
J'aime bien, de temps en temps, coder avec bash/dialog, donc ça va être amusant à faire, et c'est un bon moyen de découvrir des choses sur les soubassements[1] de Debian.
Il y a xdialog qui permet aussi de faire assez rapidement des petits
frontends sympathiques.
-- Kevin
Le 24-07-2007, Thierry B. <tth@prout.stex> a écrit :
D'ailleurs, tu viens de me donner une idée, là. Dans un autre
post de ce fil géant, je parle de pkgtool et de la fonction[1]
qui permet de voir le contenu d'un paquet installé. C'est
écrit en bash/dialog, et on doit pouvoir faire un équivalent
pour Debian.
J'aime bien, de temps en temps, coder avec bash/dialog, donc
ça va être amusant à faire, et c'est un bon moyen de découvrir
des choses sur les soubassements[1] de Debian.
Il y a xdialog qui permet aussi de faire assez rapidement des petits
D'ailleurs, tu viens de me donner une idée, là. Dans un autre post de ce fil géant, je parle de pkgtool et de la fonction[1] qui permet de voir le contenu d'un paquet installé. C'est écrit en bash/dialog, et on doit pouvoir faire un équivalent pour Debian.
J'aime bien, de temps en temps, coder avec bash/dialog, donc ça va être amusant à faire, et c'est un bon moyen de découvrir des choses sur les soubassements[1] de Debian.
Il y a xdialog qui permet aussi de faire assez rapidement des petits
