Comment reconnaitre un bon Linuxien d'un vrai neuneu ?
832 réponses
Xandros
Salut,
Depuis les quelques mois que je suis sous Linux et que je fréquente les
Forums dédiés, j'ai pu remarquer une chose.
Il existe 3 types de personnes :
1) Les novices qui viennent du monde Windows et qui posent pleins de
questions sans vraiment chercher les réponses. J'en faisais parti, mais
je me soigne depuis ;)
2) Les neuneux de base, qui n'y connaissent pas grand chose et qui se
défoulent sur le premier novice venu. On les reconnait par leurs
réponses standards : "trop gros - passera pas" - "va chercher sur
Google" - "Prouves le" - "Vas lire MAN ou HOWTO"
En fait, il n'apportent jamais rien au débat, mais font croire qu'ils
s'y connaissent trop pour perdre leur temps avec des novices.
3) Enfin, les "vrais", ceux qui t'apportent LA solution, on les
reconnait par la simplicité de leurs réponses, un lien, une commande,
une solution quoi.
Un grand merci à eux !!!
Tout ça pour dire que le monde Linux serait bien plus simple si la 2eme
cathégorie pouvait simplement admettre qu'ils font parti de la 1er, ou
alors si ils veulent se prétendre de la 3eme, qu'ils apportent de l'aide
ou bien qu'il ferme leurs gue...le.
--
Message envoyé avec ThunderBird
Sous Linux Xandros Deluxe 3.0
Le Thu, 28 Jul 2005 11:59:29 +0200, helios a écrit : (...)
Qu'on fasse l'effort d'adapter un soft à *chaque* système sur lequel on veut le porter, en réinventant la roue presque à chaque fois ne signifie pas que ledit soft soit portable, juste qu'il est porté.
Un exemple de système très portable est NetBSD par exemple, où, si j'ai bien compris, très peu de choses (proportionnellement à l'ensemble de l'OS bien sûr) doivent être modifiées pour le faire tourner sur une nouvelle architecture.
il y a peu de modif entre un pick unix pick linux pick bsd mais beaucoup plus entre pick as400 et pick sous linux
et NetBSD auraist besoin d'enormement de modif pour tourner sur un as400 ou un DEC
Ah bon?
Pourtant NetBSD tourne sur AS/400, et même sur DEC PDP-10 http://netbsd.unixtech.be/Ports/#suggested-other
Quand Pick tournera sur autant de plate-formes, on pourra alors parler de portabilité...
par contre si je prend une base pick elle est portable partout ou il y a un pick sans modif
tu peut par exemple prendre la base pick sur pc sous unix et la transferer telle quel sur un as400 sans rien changer (la base pas l'administration)
Waouw, là je suis soufflé. Quelle nouveauté...
(...)
Ah, et au fait, kermit, c'est pas un peu mort ? -- kermit est la norme de transfert je parle du programme mskermit
C'est encore pire...
Le Thu, 28 Jul 2005 11:59:29 +0200, helios a écrit :
(...)
Qu'on fasse l'effort d'adapter un soft à *chaque* système sur lequel on
veut le porter, en réinventant la roue presque à chaque fois ne signifie
pas que ledit soft soit portable, juste qu'il est porté.
Un exemple de système très portable est NetBSD par exemple, où, si j'ai
bien compris, très peu de choses (proportionnellement à l'ensemble de l'OS
bien sûr) doivent être modifiées pour le faire tourner sur une nouvelle
architecture.
il y a peu de modif entre un pick unix pick linux pick bsd mais beaucoup
plus entre pick as400 et pick sous linux
et NetBSD auraist besoin d'enormement de modif pour tourner sur un as400 ou
un DEC
Ah bon?
Pourtant NetBSD tourne sur AS/400, et même sur DEC PDP-10
http://netbsd.unixtech.be/Ports/#suggested-other
Quand Pick tournera sur autant de plate-formes, on pourra alors parler de
portabilité...
par contre si je prend une base pick elle est portable partout ou il y a un
pick sans modif
tu peut par exemple prendre la base pick sur pc sous unix et la transferer
telle quel sur un as400 sans rien changer (la base pas l'administration)
Waouw, là je suis soufflé. Quelle nouveauté...
(...)
Ah, et au fait, kermit, c'est pas un peu mort ?
--
kermit est la norme de transfert je parle du programme mskermit
Le Thu, 28 Jul 2005 11:59:29 +0200, helios a écrit : (...)
Qu'on fasse l'effort d'adapter un soft à *chaque* système sur lequel on veut le porter, en réinventant la roue presque à chaque fois ne signifie pas que ledit soft soit portable, juste qu'il est porté.
Un exemple de système très portable est NetBSD par exemple, où, si j'ai bien compris, très peu de choses (proportionnellement à l'ensemble de l'OS bien sûr) doivent être modifiées pour le faire tourner sur une nouvelle architecture.
il y a peu de modif entre un pick unix pick linux pick bsd mais beaucoup plus entre pick as400 et pick sous linux
et NetBSD auraist besoin d'enormement de modif pour tourner sur un as400 ou un DEC
Ah bon?
Pourtant NetBSD tourne sur AS/400, et même sur DEC PDP-10 http://netbsd.unixtech.be/Ports/#suggested-other
Quand Pick tournera sur autant de plate-formes, on pourra alors parler de portabilité...
par contre si je prend une base pick elle est portable partout ou il y a un pick sans modif
tu peut par exemple prendre la base pick sur pc sous unix et la transferer telle quel sur un as400 sans rien changer (la base pas l'administration)
Waouw, là je suis soufflé. Quelle nouveauté...
(...)
Ah, et au fait, kermit, c'est pas un peu mort ? -- kermit est la norme de transfert je parle du programme mskermit
C'est encore pire...
helios
"Stephane TOUGARD" a écrit dans le message de news:
remy wrote: programmes comme pick totalement incomprehensibles a nos yeux.
Sous Unix, un programme ne fait qu'une chose, il est petit, il a des API ou des entrees sorties relativement standardisees ...
pick a des api et clients
Pick, ca tourne tout seul, ca fait tout, il y a des belles procedures et la seule raison pour la quelle ce n'est pas un OS, c'est que ca ne sait pas gerer le hard directement, il faut donc un noyau en dessous, quel qu'il soit (Linux, Windows, OS/3x0 ...).
pick a l'origine etait un OS puis la couche OS a ete supprime et deleguer a
d'autre OS tel UNIX , windows, dos .....
En fait, les packageurs auraient tout interet a livrer pick avec un noyau Linux directement et une belle procedure d'install, ou bien de livrer un package directement utilisable sous hercule, ce qui eviterait de salir un Unix avec ces grosses pattes (surtout qu'OS/360 est deja completement free, ca pourrait faire un bel ensemble).
ou tout simplement inclure un pick deja installe sur une distri linux en live cd (la kaella par exemple ? ) voila du boulot pour la communaute libre
Est ce que ca a un interet ? autre que personnelle pour avoir une autre vision des SGBD et decouvrir un peu la philosophie des mainframes, non aucun interet au niveau professionnel. Apprendre a utiliser et administrer Pick, c'est comme apprendre le Cobol, ca permet de travailler dans un millieu non Unixiens, sur des vieux systemes dans le millieux des operateurs, des banques ou des assurances. En attendant que le Cobol devienne du Java et que pick soit remplace par Oracle (ce qui ne manquera pas d'arriver).
Cobol sera a terme remplacer par java car sauf erreur java peut faire tout ce que cobol fait en etat portable
par contre pick ne sera pas remplacer par oracle mais par un sgbd qui auras integres les concepts MV (il est plus facile d'integres du Mv dans un relationnel que de rendre relationnel toute les bases MV et comme le MV n'empeches pas le relationnel .....)
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
"Stephane TOUGARD" <stephane@unices.org> a écrit dans le message de
news:g7lmr2-udg.ln1@gulliver.unices.org...
remy wrote:
programmes comme pick totalement incomprehensibles a nos yeux.
Sous Unix, un programme ne fait qu'une chose, il est petit, il a des
API ou des entrees sorties relativement standardisees ...
pick a des api et clients
Pick, ca tourne tout seul, ca fait tout, il y a des belles procedures et
la seule raison pour la quelle ce n'est pas un OS, c'est que ca ne sait
pas gerer le hard directement, il faut donc un noyau en dessous, quel
qu'il soit (Linux, Windows, OS/3x0 ...).
pick a l'origine etait un OS puis la couche OS a ete supprime et deleguer a
d'autre OS tel UNIX , windows, dos .....
En fait, les packageurs auraient tout interet a livrer pick avec un
noyau Linux directement et une belle procedure d'install, ou bien de
livrer un package directement utilisable sous hercule, ce qui eviterait
de salir un Unix avec ces grosses pattes (surtout qu'OS/360 est deja
completement free, ca pourrait faire un bel ensemble).
ou tout simplement inclure un pick deja installe sur une distri linux en
live cd (la kaella par exemple ? )
voila du boulot pour la communaute libre
Est ce que ca a un interet ? autre que personnelle pour avoir une autre
vision des SGBD et decouvrir un peu la philosophie des mainframes, non
aucun interet au niveau professionnel. Apprendre a utiliser et
administrer Pick, c'est comme apprendre le Cobol, ca permet de
travailler dans un millieu non Unixiens, sur des vieux systemes dans le
millieux des operateurs, des banques ou des assurances. En attendant que
le Cobol devienne du Java et que pick soit remplace par Oracle (ce qui
ne manquera pas d'arriver).
Cobol sera a terme remplacer par java car sauf erreur java peut faire tout
ce que cobol fait en etat portable
par contre pick ne sera pas remplacer par oracle mais par un sgbd qui auras
integres les concepts MV
(il est plus facile d'integres du Mv dans un relationnel que de rendre
relationnel toute les bases MV et comme le MV n'empeches pas le relationnel
.....)
--
http://www.unices.org Les meilleurs modules de Perl
http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul
http://artlibre.org/ Free Art License
"Stephane TOUGARD" a écrit dans le message de news:
remy wrote: programmes comme pick totalement incomprehensibles a nos yeux.
Sous Unix, un programme ne fait qu'une chose, il est petit, il a des API ou des entrees sorties relativement standardisees ...
pick a des api et clients
Pick, ca tourne tout seul, ca fait tout, il y a des belles procedures et la seule raison pour la quelle ce n'est pas un OS, c'est que ca ne sait pas gerer le hard directement, il faut donc un noyau en dessous, quel qu'il soit (Linux, Windows, OS/3x0 ...).
pick a l'origine etait un OS puis la couche OS a ete supprime et deleguer a
d'autre OS tel UNIX , windows, dos .....
En fait, les packageurs auraient tout interet a livrer pick avec un noyau Linux directement et une belle procedure d'install, ou bien de livrer un package directement utilisable sous hercule, ce qui eviterait de salir un Unix avec ces grosses pattes (surtout qu'OS/360 est deja completement free, ca pourrait faire un bel ensemble).
ou tout simplement inclure un pick deja installe sur une distri linux en live cd (la kaella par exemple ? ) voila du boulot pour la communaute libre
Est ce que ca a un interet ? autre que personnelle pour avoir une autre vision des SGBD et decouvrir un peu la philosophie des mainframes, non aucun interet au niveau professionnel. Apprendre a utiliser et administrer Pick, c'est comme apprendre le Cobol, ca permet de travailler dans un millieu non Unixiens, sur des vieux systemes dans le millieux des operateurs, des banques ou des assurances. En attendant que le Cobol devienne du Java et que pick soit remplace par Oracle (ce qui ne manquera pas d'arriver).
Cobol sera a terme remplacer par java car sauf erreur java peut faire tout ce que cobol fait en etat portable
par contre pick ne sera pas remplacer par oracle mais par un sgbd qui auras integres les concepts MV (il est plus facile d'integres du Mv dans un relationnel que de rendre relationnel toute les bases MV et comme le MV n'empeches pas le relationnel .....)
-- http://www.unices.org Les meilleurs modules de Perl http://www.unices.org/photo/ 250 photos de Singapour, Sydney et Seoul http://artlibre.org/ Free Art License
helios
"Stephane Zuckerman" a écrit dans le message de news:
alors tu as compris ou je m'inquete pour les eleves
en resume le relationnel est pour chaque lien il y a un depart et une arrive
(bijection)
Tu te rends compte qu'en parlant de bijection tu invalides ton affirmation selon laquelle "PICK qui fait du MV peut faire du relationnel mais l'inverse est faux" ? Si ton application est bijective, ça signifie que tu peux partir de f(x) pour retrouver ton x de départ.
le relationnel ne sait traite que des bijections le MV sait traite toute les applications et fonctions meme les bijections
"Stephane Zuckerman" <szuckerm@etu.utc.fr> a écrit dans le message de
news:Pine.OSF.4.58.0507281217070.342864@vega.utc.fr...
alors tu as compris ou je m'inquete pour les eleves
en resume le relationnel est pour chaque lien il y a un depart et une
arrive
(bijection)
Tu te rends compte qu'en parlant de bijection tu invalides ton affirmation
selon laquelle "PICK qui fait du MV peut faire du relationnel mais
l'inverse est faux" ? Si ton application est bijective, ça signifie que tu
peux partir de f(x) pour retrouver ton x de départ.
le relationnel ne sait traite que des bijections
le MV sait traite toute les applications et fonctions meme les bijections
"Stephane Zuckerman" a écrit dans le message de news:
alors tu as compris ou je m'inquete pour les eleves
en resume le relationnel est pour chaque lien il y a un depart et une arrive
(bijection)
Tu te rends compte qu'en parlant de bijection tu invalides ton affirmation selon laquelle "PICK qui fait du MV peut faire du relationnel mais l'inverse est faux" ? Si ton application est bijective, ça signifie que tu peux partir de f(x) pour retrouver ton x de départ.
le relationnel ne sait traite que des bijections le MV sait traite toute les applications et fonctions meme les bijections
Vincent Bernat
OoO En cette fin de matinée radieuse du jeudi 28 juillet 2005, vers 11:23, "helios" disait:
comment s'appelle une fonction qui est aussi une application ? une bijection (revois le cours de math de 6eme)
Moi qui croyait que c'était une fonction injective et surjective. -- die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
OoO En cette fin de matinée radieuse du jeudi 28 juillet 2005, vers
11:23, "helios" <helios@com02.com> disait:
comment s'appelle une fonction qui est aussi une application ? une bijection
(revois le cours de math de 6eme)
Moi qui croyait que c'était une fonction injective et surjective.
--
die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
OoO En cette fin de matinée radieuse du jeudi 28 juillet 2005, vers 11:23, "helios" disait:
comment s'appelle une fonction qui est aussi une application ? une bijection (revois le cours de math de 6eme)
Moi qui croyait que c'était une fonction injective et surjective. -- die_if_kernel("Kernel gets FloatingPenguinUnit disabled trap", regs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
Vincent Bernat
OoO En cette matinée pluvieuse du jeudi 28 juillet 2005, vers 10:28, "helios" disait:
Shell-Metzer est le plus performant mais seulement sur les gros tris (on est dans le secteur des sgbd donc gros tris)
Justement, c'est l'inverse. Quand $n$ est grand, le quicksort l'emporte. Par contre, pour des petits tris, on peut vouloir utiliser autre chose. -- BOFH excuse #201: RPC_PMAP_FAILURE
OoO En cette matinée pluvieuse du jeudi 28 juillet 2005, vers 10:28,
"helios" <helios@com02.com> disait:
Shell-Metzer est le plus performant mais seulement sur les gros tris (on est
dans le secteur des sgbd donc gros tris)
Justement, c'est l'inverse. Quand $n$ est grand, le quicksort
l'emporte. Par contre, pour des petits tris, on peut vouloir utiliser
autre chose.
--
BOFH excuse #201:
RPC_PMAP_FAILURE
OoO En cette matinée pluvieuse du jeudi 28 juillet 2005, vers 10:28, "helios" disait:
Shell-Metzer est le plus performant mais seulement sur les gros tris (on est dans le secteur des sgbd donc gros tris)
Justement, c'est l'inverse. Quand $n$ est grand, le quicksort l'emporte. Par contre, pour des petits tris, on peut vouloir utiliser autre chose. -- BOFH excuse #201: RPC_PMAP_FAILURE
helios
Pas la peine de vous battre sur des chiffres qui, entre nous, ne prouvent pas grand chose. Tout d'abord, qu'est-ce qu'un utilisateur? S'agit-il d'un compte, d'une connexion ou d'une requête... Autrement dit, quelle base utilise Google et combien d'utilisateurs sont connectés dessus à un instant t ?
Bref. Ca ne fait pas avancer le débat.
exact
PICK existe, c'est un fait. Et merci à Helios de me l'avoir fait découvrir. Maintenant, il reste beaucoup de chemin à parcourir pour le faire adopter dans les nouveaux projets (le principal problème étant le manque de personnes qui connaissent ce système.) Le fait d'avoir une implémentation OpenSource permettra, peut-être, une nouvelle distribution des cartes, qui sait...
mon but est de promouvoir openqm sur deux niveaux
1/ le commercial openqm est 5 fois moins chers que les autres 2/ l'opensource avec une communaute francaise l'idee etant d'integres openqm dans un livecd style kaella ou knoppix64
Pour le moment, les bases relationnelles régnent en maîtres. D'ailleurs, il faut bien le reconnaitre, elles répondent aux besoins dans la majorité des projets informatiques (Peut-être pas toujours de manière efficace en terme de consommation CPU... la question reste ouverte.)
les base relationnel sont les plus connu plus exactement et les plus enseigné , le monde pick est un monde cache ce qui ne veux pas dire reduit et sourtout tres truste par les anglophones qui considere les francais comme des idiots le marche francophone est boycotte par les operateurs pick
A mon avis, ce qui lui manque c'est une architecture de type client/serveur, des API pour des langages de haut niveau (Java, Python, Perl...) et un système clair de gestion des utilisateurs.
les client/serveur existe , les client vers les autre appli et language existe, les api existe
Pas la peine de vous battre sur des chiffres qui, entre nous, ne
prouvent pas grand chose.
Tout d'abord, qu'est-ce qu'un utilisateur? S'agit-il d'un compte, d'une
connexion ou d'une requête...
Autrement dit, quelle base utilise Google et combien d'utilisateurs sont
connectés dessus à un instant t ?
Bref. Ca ne fait pas avancer le débat.
exact
PICK existe, c'est un fait. Et merci à Helios de me l'avoir fait
découvrir. Maintenant, il reste beaucoup de chemin à parcourir pour le
faire adopter dans les nouveaux projets (le principal problème étant le
manque de personnes qui connaissent ce système.)
Le fait d'avoir une implémentation OpenSource permettra, peut-être, une
nouvelle distribution des cartes, qui sait...
mon but est de promouvoir openqm sur deux niveaux
1/ le commercial openqm est 5 fois moins chers que les autres
2/ l'opensource avec une communaute francaise l'idee etant d'integres openqm
dans un livecd style kaella ou knoppix64
Pour le moment, les bases relationnelles régnent en maîtres. D'ailleurs,
il faut bien le reconnaitre, elles répondent aux besoins dans la
majorité des projets informatiques (Peut-être pas toujours de manière
efficace en terme de consommation CPU... la question reste ouverte.)
les base relationnel sont les plus connu plus exactement et les plus
enseigné , le monde pick est un monde cache ce qui ne veux pas dire reduit
et sourtout tres truste par les anglophones qui considere les francais comme
des idiots le marche francophone est boycotte par les operateurs pick
A mon avis, ce qui lui manque c'est une architecture de type
client/serveur, des API pour des langages de haut niveau (Java, Python,
Perl...) et un système clair de gestion des utilisateurs.
les client/serveur existe , les client vers les autre appli et language
existe, les api existe
Pas la peine de vous battre sur des chiffres qui, entre nous, ne prouvent pas grand chose. Tout d'abord, qu'est-ce qu'un utilisateur? S'agit-il d'un compte, d'une connexion ou d'une requête... Autrement dit, quelle base utilise Google et combien d'utilisateurs sont connectés dessus à un instant t ?
Bref. Ca ne fait pas avancer le débat.
exact
PICK existe, c'est un fait. Et merci à Helios de me l'avoir fait découvrir. Maintenant, il reste beaucoup de chemin à parcourir pour le faire adopter dans les nouveaux projets (le principal problème étant le manque de personnes qui connaissent ce système.) Le fait d'avoir une implémentation OpenSource permettra, peut-être, une nouvelle distribution des cartes, qui sait...
mon but est de promouvoir openqm sur deux niveaux
1/ le commercial openqm est 5 fois moins chers que les autres 2/ l'opensource avec une communaute francaise l'idee etant d'integres openqm dans un livecd style kaella ou knoppix64
Pour le moment, les bases relationnelles régnent en maîtres. D'ailleurs, il faut bien le reconnaitre, elles répondent aux besoins dans la majorité des projets informatiques (Peut-être pas toujours de manière efficace en terme de consommation CPU... la question reste ouverte.)
les base relationnel sont les plus connu plus exactement et les plus enseigné , le monde pick est un monde cache ce qui ne veux pas dire reduit et sourtout tres truste par les anglophones qui considere les francais comme des idiots le marche francophone est boycotte par les operateurs pick
A mon avis, ce qui lui manque c'est une architecture de type client/serveur, des API pour des langages de haut niveau (Java, Python, Perl...) et un système clair de gestion des utilisateurs.
les client/serveur existe , les client vers les autre appli et language existe, les api existe
Vincent Bernat
OoO En cette matinée pluvieuse du jeudi 28 juillet 2005, vers 10:33, "helios" disait:
Donc toi, t'es au niveau user ?
je suis administrateur et lorsque j'ai besoin de connaitre un fonctionnement interne du moteur j'appel un motoriste
Mais vous savez quand même que Pick, il tourne en mémoire virtuelle, au niveau 0, a un mécanisme de séparation des privilèges et autres conneries que vous débitez au rythme de 20 par heure ? -- panic("aha1740.c"); /* Goodbye */ 2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
OoO En cette matinée pluvieuse du jeudi 28 juillet 2005, vers 10:33,
"helios" <helios@com02.com> disait:
Donc toi, t'es au niveau user ?
je suis administrateur et lorsque j'ai besoin de connaitre un fonctionnement
interne du moteur j'appel un motoriste
Mais vous savez quand même que Pick, il tourne en mémoire virtuelle,
au niveau 0, a un mécanisme de séparation des privilèges et autres
conneries que vous débitez au rythme de 20 par heure ?
--
panic("aha1740.c"); /* Goodbye */
2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
OoO En cette matinée pluvieuse du jeudi 28 juillet 2005, vers 10:33, "helios" disait:
Donc toi, t'es au niveau user ?
je suis administrateur et lorsque j'ai besoin de connaitre un fonctionnement interne du moteur j'appel un motoriste
Mais vous savez quand même que Pick, il tourne en mémoire virtuelle, au niveau 0, a un mécanisme de séparation des privilèges et autres conneries que vous débitez au rythme de 20 par heure ? -- panic("aha1740.c"); /* Goodbye */ 2.2.16 /usr/src/linux/drivers/scsi/aha1740.c
Thierry Boudet
On 2005-07-28, helios wrote:
et NetBSD auraist besoin d'enormement de modif pour tourner sur un as400 ou un DEC
Pour les as400, ma spécialiste préférée étant en vacances, je
ne m'avancerais pas à répondre. A priori, comme elle utilise Linux sur un as400 risc, NetBSD doit aussi pouvoir y tourner.
Par contre, pour DEC, j'ai ça: http://netbsd.org/Ports/alpha/ http://netbsd.org/Ports/arm32/ http://netbsd.org/Ports/i386/ http://netbsd.org/Ports/vax/ http://netbsd.org/Ports/pdp10/ Mais je pense que j'en ai manqué quelques uns...
tu peut par exemple prendre la base pick sur pc sous unix et la transferer telle quel sur un as400 sans rien changer (la base pas l'administration)
Et pour les encodages de caractères, ça se passe comment ?
--
Peer-to-peer, c'est le sujet de ma thèse :) Donc c'est utile, et ca rapporte des diplômes. Et des sous. Ca rapporte une thèse ?
On 2005-07-28, helios <helios@com02.com> wrote:
et NetBSD auraist besoin d'enormement de modif pour tourner sur un as400 ou
un DEC
Pour les as400, ma spécialiste préférée étant en vacances, je
ne m'avancerais pas à répondre. A priori, comme elle utilise
Linux sur un as400 risc, NetBSD doit aussi pouvoir y tourner.
Par contre, pour DEC, j'ai ça:
http://netbsd.org/Ports/alpha/
http://netbsd.org/Ports/arm32/
http://netbsd.org/Ports/i386/
http://netbsd.org/Ports/vax/
http://netbsd.org/Ports/pdp10/
Mais je pense que j'en ai manqué quelques uns...
tu peut par exemple prendre la base pick sur pc sous unix et la transferer
telle quel sur un as400 sans rien changer (la base pas l'administration)
Et pour les encodages de caractères, ça se passe comment ?
--
Peer-to-peer, c'est le sujet de ma thèse :) Donc c'est utile, et ca
rapporte des diplômes. Et des sous.
Ca rapporte une thèse ?
et NetBSD auraist besoin d'enormement de modif pour tourner sur un as400 ou un DEC
Pour les as400, ma spécialiste préférée étant en vacances, je
ne m'avancerais pas à répondre. A priori, comme elle utilise Linux sur un as400 risc, NetBSD doit aussi pouvoir y tourner.
Par contre, pour DEC, j'ai ça: http://netbsd.org/Ports/alpha/ http://netbsd.org/Ports/arm32/ http://netbsd.org/Ports/i386/ http://netbsd.org/Ports/vax/ http://netbsd.org/Ports/pdp10/ Mais je pense que j'en ai manqué quelques uns...
tu peut par exemple prendre la base pick sur pc sous unix et la transferer telle quel sur un as400 sans rien changer (la base pas l'administration)
Et pour les encodages de caractères, ça se passe comment ?
--
Peer-to-peer, c'est le sujet de ma thèse :) Donc c'est utile, et ca rapporte des diplômes. Et des sous. Ca rapporte une thèse ?
Nicolas George
"helios" , dans le message <42e89754$0$4724$, a écrit :
Shell-Metzer est le plus performant
Non.
"helios" , dans le message <42e89754$0$4724$636a15ce@news.free.fr>, a
écrit :
