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
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser un bon vieux Shell et si vraiment on veux gerer des grosses tables en mode clef valeurs (c'est quand meme vachement basique comme principe), on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris oui l'on a une cle unique par champs plus il y a de donnees plus il y a de cles bonjour les performance
et le dico sert a ameloirer les performances cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut cle n a cles n+100 coucou les trous
mais se qui me titille il y a une limitation liee a la taille des cles et vue le gaspillage il vaut mieux voir grand
En fait, le principe de base, à priori pas idiot, est au contraire d'éviter les informations redondantes.
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION 01 Jerome 12:30 02 Remy 12:45 03 Jerome 13:20 04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS 01 Jerome 12:30;13:20 02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels, et on peut arriver au même résultat en créant des tables liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
a condition que le dico cela soit CONNEXIONS
je cherche dans le dico connexion 13:20 et je tombe sur id 01 qui donne Jerome
et comment je fais si je veux toutes les connexions de Jerome il faut que je cree un autre dico ?
helios va nous expliquer il est un expert du pic
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
Jerome Lambert wrote:
En gros, oui.
Un lien un peu plus recommandable sur le bidule:
http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi
j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser
un bon vieux Shell et si vraiment on veux gerer des grosses tables en
mode clef valeurs (c'est quand meme vachement basique comme principe),
on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris
oui l'on a une cle unique par champs
plus il y a de donnees plus il y a de cles
bonjour les performance
et le dico sert a ameloirer les performances
cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut
cle n a cles n+100
coucou les trous
mais se qui me titille
il y a une limitation liee a la taille des cles
et vue le gaspillage il vaut mieux voir grand
En fait, le principe de base, à priori pas idiot, est au contraire
d'éviter les informations redondantes.
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION
01 Jerome 12:30
02 Remy 12:45
03 Jerome 13:20
04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS
01 Jerome 12:30;13:20
02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels,
et on peut arriver au même résultat en créant des tables liées dans un
SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
a condition que le dico cela soit CONNEXIONS
je cherche dans le dico connexion 13:20 et je tombe sur id 01 qui donne
Jerome
et comment je fais si je veux toutes les connexions de Jerome
il faut que je cree un autre dico ?
helios va nous expliquer il est un expert du pic
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser un bon vieux Shell et si vraiment on veux gerer des grosses tables en mode clef valeurs (c'est quand meme vachement basique comme principe), on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris oui l'on a une cle unique par champs plus il y a de donnees plus il y a de cles bonjour les performance
et le dico sert a ameloirer les performances cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut cle n a cles n+100 coucou les trous
mais se qui me titille il y a une limitation liee a la taille des cles et vue le gaspillage il vaut mieux voir grand
En fait, le principe de base, à priori pas idiot, est au contraire d'éviter les informations redondantes.
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION 01 Jerome 12:30 02 Remy 12:45 03 Jerome 13:20 04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS 01 Jerome 12:30;13:20 02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels, et on peut arriver au même résultat en créant des tables liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
a condition que le dico cela soit CONNEXIONS
je cherche dans le dico connexion 13:20 et je tombe sur id 01 qui donne Jerome
et comment je fais si je veux toutes les connexions de Jerome il faut que je cree un autre dico ?
helios va nous expliquer il est un expert du pic
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
seb666fr2
remy wrote in message news:<42e4961f$0$3111$...
(...)
Je ne vois aucune bonne raison pour donner une surcouche aussi stupide a un OS qui assure tout cela tres bien tout seul. Si c'est pour faire un systeme d'exploitation, fais un systeme d'exploitation.
"6.1 - Description du système Pick
Le système PICK est à la fois, à l'origine, un système d'exploitation multi utilisateurs et un système d'organisation du stockage des données. Il date de 1965 et fête cette année son 40e anniversaire. Cette longévité, qui pourrait passer pour une pérennité, ne doit pas faire illusion : le faible nombre d'utilisateurs d'un tel système à travers le monde, comme sa décrue dans un univers l'informatique en forte expansion, le condamne à terme.
Pour comprendre son obsolescence et par conséquent les risques inhérents à sa disparition, il faut en expliquer la structure et le fonctionnement afin de voir pourquoi il ne répond plus aux principales attentes du marché informatique.
En fait Pick fait partie de cette famille de produit comme Prologue qui mélangeait à la fois l'OS (operating System) et la gestion des données (organisation, accès, stockage). Ces systèmes sont aujourd'hui en voie de disparition."
a non pas prologue j'ai eu un jour il y a bien lontemps une presentation de se langage et cela m'a assis serieux je suis reste ... je n'ai pas ete foutu de comprendre comment cela fct
a ma decharge j'etais jeune et impressionnable quoique aller je vais dire que je le suis encore
Prologue c'est un système d'exploitation. Prolog c'est le langage.
remy <remy@fctpas.fr> wrote in message news:<42e4961f$0$3111$8fcfb975@news.wanadoo.fr>...
(...)
Je ne vois aucune bonne raison pour donner une surcouche aussi stupide a
un OS qui assure tout cela tres bien tout seul. Si c'est pour faire un
systeme d'exploitation, fais un systeme d'exploitation.
"6.1 - Description du système Pick
Le système PICK est à la fois, à l'origine, un système d'exploitation
multi utilisateurs et un système d'organisation du stockage des données.
Il date de 1965 et fête cette année son 40e anniversaire. Cette
longévité, qui pourrait passer pour une pérennité, ne doit pas faire
illusion : le faible nombre d'utilisateurs d'un tel système à travers le
monde, comme sa décrue dans un univers l'informatique en forte
expansion, le condamne à terme.
Pour comprendre son obsolescence et par conséquent les risques inhérents
à sa disparition, il faut en expliquer la structure et le fonctionnement
afin de voir pourquoi il ne répond plus aux principales attentes du
marché informatique.
En fait Pick fait partie de cette famille de produit comme Prologue qui
mélangeait à la fois l'OS (operating System) et la gestion des données
(organisation, accès, stockage). Ces systèmes sont aujourd'hui en voie
de disparition."
a non pas prologue
j'ai eu un jour il y a bien lontemps une presentation de se langage
et cela m'a assis serieux je suis reste ... je n'ai pas ete foutu
de comprendre comment cela fct
a ma decharge j'etais jeune et impressionnable quoique aller
je vais dire que je le suis encore
Prologue c'est un système d'exploitation. Prolog c'est le langage.
Je ne vois aucune bonne raison pour donner une surcouche aussi stupide a un OS qui assure tout cela tres bien tout seul. Si c'est pour faire un systeme d'exploitation, fais un systeme d'exploitation.
"6.1 - Description du système Pick
Le système PICK est à la fois, à l'origine, un système d'exploitation multi utilisateurs et un système d'organisation du stockage des données. Il date de 1965 et fête cette année son 40e anniversaire. Cette longévité, qui pourrait passer pour une pérennité, ne doit pas faire illusion : le faible nombre d'utilisateurs d'un tel système à travers le monde, comme sa décrue dans un univers l'informatique en forte expansion, le condamne à terme.
Pour comprendre son obsolescence et par conséquent les risques inhérents à sa disparition, il faut en expliquer la structure et le fonctionnement afin de voir pourquoi il ne répond plus aux principales attentes du marché informatique.
En fait Pick fait partie de cette famille de produit comme Prologue qui mélangeait à la fois l'OS (operating System) et la gestion des données (organisation, accès, stockage). Ces systèmes sont aujourd'hui en voie de disparition."
a non pas prologue j'ai eu un jour il y a bien lontemps une presentation de se langage et cela m'a assis serieux je suis reste ... je n'ai pas ete foutu de comprendre comment cela fct
a ma decharge j'etais jeune et impressionnable quoique aller je vais dire que je le suis encore
Prologue c'est un système d'exploitation. Prolog c'est le langage.
Richard Delorme
Si tu as besoin de transporter 4 personnes, ou si tu dois traverser un champ tous les jours avec ta bagnole, et bien la lanborghini c'est nul à chier et la 2CV nickel. Idem si tu accorde de l'importance à la quantité de carburant et au coût d'entretien de la bagnole. Une deudeuche ne craint ni le chaud, ni le froid, ni la poussière, ni le sable, peut traverser le sahara ou un champ labouré. C'est beaucoup plus solide et polyvalent qu'une lamborghini, et beaucoup moins souvent en panne.
Cette Lamborghini là va très bien pour rouler dans le sahara avec 4 personnes à bord : http://www.lambocars.com/archive/lm/lm004s.htm
-- Richard
Si tu as besoin de transporter 4 personnes, ou si tu dois traverser un
champ tous les jours avec ta bagnole, et bien la lanborghini c'est nul à
chier et la 2CV nickel.
Idem si tu accorde de l'importance à la quantité
de carburant et au coût d'entretien de la bagnole. Une deudeuche ne
craint ni le chaud, ni le froid, ni la poussière, ni le sable, peut
traverser le sahara ou un champ labouré. C'est beaucoup plus solide et
polyvalent qu'une lamborghini, et beaucoup moins souvent en panne.
Cette Lamborghini là va très bien pour rouler dans le sahara avec 4
personnes à bord :
http://www.lambocars.com/archive/lm/lm004s.htm
Si tu as besoin de transporter 4 personnes, ou si tu dois traverser un champ tous les jours avec ta bagnole, et bien la lanborghini c'est nul à chier et la 2CV nickel. Idem si tu accorde de l'importance à la quantité de carburant et au coût d'entretien de la bagnole. Une deudeuche ne craint ni le chaud, ni le froid, ni la poussière, ni le sable, peut traverser le sahara ou un champ labouré. C'est beaucoup plus solide et polyvalent qu'une lamborghini, et beaucoup moins souvent en panne.
Cette Lamborghini là va très bien pour rouler dans le sahara avec 4 personnes à bord : http://www.lambocars.com/archive/lm/lm004s.htm
-- Richard
Jerome Lambert
Jerome Lambert wrote:
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser un bon vieux Shell et si vraiment on veux gerer des grosses tables en mode clef valeurs (c'est quand meme vachement basique comme principe), on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris oui l'on a une cle unique par champs plus il y a de donnees plus il y a de cles bonjour les performance
et le dico sert a ameloirer les performances cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut cle n a cles n+100 coucou les trous
mais se qui me titille il y a une limitation liee a la taille des cles et vue le gaspillage il vaut mieux voir grand
En fait, le principe de base, à priori pas idiot, est au contraire d'éviter les informations redondantes.
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION 01 Jerome 12:30 02 Remy 12:45 03 Jerome 13:20 04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS 01 Jerome 12:30;13:20 02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels, et on peut arriver au même résultat en créant des tables liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
a condition que le dico cela soit CONNEXIONS
je cherche dans le dico connexion 13:20 et je tombe sur id 01 qui donne Jerome
Voilà. Et dans le cas où on a ID NOM CONNEXIONS 01 Jerome 12:30;13:20;14:00 02 Remy 12:45;13:45;14:00
Si je cherche 14:00, ça me renvoit id 01 Jerome et id 02 Remy. L'avantage dans ce cas est que je ne dois pas "tronconner" moi-même la chaîne de caractère "CONNEXIONS", le système le faisant à ma place...
et comment je fais si je veux toutes les connexions de Jerome il faut que je cree un autre dico ?
Non. Le dictionnaire ne porte que sur la rubrique mutlivaluée, en l'occurence CONNEXIONS. Les reste s'interroge via des systèmes classiques.
Jerome Lambert wrote:
En gros, oui.
Un lien un peu plus recommandable sur le bidule:
http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi
j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser
un bon vieux Shell et si vraiment on veux gerer des grosses tables en
mode clef valeurs (c'est quand meme vachement basique comme principe),
on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris
oui l'on a une cle unique par champs
plus il y a de donnees plus il y a de cles
bonjour les performance
et le dico sert a ameloirer les performances
cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut
cle n a cles n+100
coucou les trous
mais se qui me titille
il y a une limitation liee a la taille des cles
et vue le gaspillage il vaut mieux voir grand
En fait, le principe de base, à priori pas idiot, est au contraire
d'éviter les informations redondantes.
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION
01 Jerome 12:30
02 Remy 12:45
03 Jerome 13:20
04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS
01 Jerome 12:30;13:20
02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques
actuels, et on peut arriver au même résultat en créant des tables
liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte
de vitesse.
a condition que le dico cela soit CONNEXIONS
je cherche dans le dico connexion 13:20 et je tombe sur id 01 qui donne
Jerome
Voilà. Et dans le cas où on a
ID NOM CONNEXIONS
01 Jerome 12:30;13:20;14:00
02 Remy 12:45;13:45;14:00
Si je cherche 14:00, ça me renvoit id 01 Jerome et id 02 Remy.
L'avantage dans ce cas est que je ne dois pas "tronconner" moi-même la
chaîne de caractère "CONNEXIONS", le système le faisant à ma place...
et comment je fais si je veux toutes les connexions de Jerome
il faut que je cree un autre dico ?
Non. Le dictionnaire ne porte que sur la rubrique mutlivaluée, en
l'occurence CONNEXIONS. Les reste s'interroge via des systèmes classiques.
En gros, oui. Un lien un peu plus recommandable sur le bidule: http://en.wikipedia.org/wiki/Pick_operating_system
Oui, enfin ca nous remet quand meme a l'epoque des terminaux VT100, moi j'ai rien contre, mais bon quitte a etre en mode texte, autant utiliser un bon vieux Shell et si vraiment on veux gerer des grosses tables en mode clef valeurs (c'est quand meme vachement basique comme principe), on db-berckeley, au mieux il y a une API Perl.
si j'ai bien compris oui l'on a une cle unique par champs plus il y a de donnees plus il y a de cles bonjour les performance
et le dico sert a ameloirer les performances cela cree des sous tables informelles
debit de tatie ginette ou ce que l'on veut cle n a cles n+100 coucou les trous
mais se qui me titille il y a une limitation liee a la taille des cles et vue le gaspillage il vaut mieux voir grand
En fait, le principe de base, à priori pas idiot, est au contraire d'éviter les informations redondantes.
Par exemple, pour un log de connexion et un SGBD traditionnel, on aurait
ID NOM CONNEXION 01 Jerome 12:30 02 Remy 12:45 03 Jerome 13:20 04 Remy 13:45
et avec un SGBD multivalué:
ID NOM CONNEXIONS 01 Jerome 12:30;13:20 02 Remy 12:45;13:45
Ca fait un peu gagne-petit, surtout vu les tailles des disques actuels, et on peut arriver au même résultat en créant des tables liées dans un SGBDR, d'où le fait que ce genre de bases soit en perte de vitesse.
a condition que le dico cela soit CONNEXIONS
je cherche dans le dico connexion 13:20 et je tombe sur id 01 qui donne Jerome
Voilà. Et dans le cas où on a ID NOM CONNEXIONS 01 Jerome 12:30;13:20;14:00 02 Remy 12:45;13:45;14:00
Si je cherche 14:00, ça me renvoit id 01 Jerome et id 02 Remy. L'avantage dans ce cas est que je ne dois pas "tronconner" moi-même la chaîne de caractère "CONNEXIONS", le système le faisant à ma place...
et comment je fais si je veux toutes les connexions de Jerome il faut que je cree un autre dico ?
Non. Le dictionnaire ne porte que sur la rubrique mutlivaluée, en l'occurence CONNEXIONS. Les reste s'interroge via des systèmes classiques.
Vincent Bernat
OoO Vers la fin de l'après-midi du lundi 25 juillet 2005, vers 16:49, Stephane Zuckerman disait:
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait, ça commence au niveau 1. Je pense qu'il parlait des runlevels de Linux (en System V)
S'il le colle au runlevel 0 sa bestiole, il faut qu'il la démarre en tapant halt. À mon avis, il raconte juste n'importe quoi. -- I CAN'T SEE DEAD PEOPLE I CAN'T SEE DEAD PEOPLE I CAN'T SEE DEAD PEOPLE -+- Bart Simpson on chalkboard in episode BABF05
OoO Vers la fin de l'après-midi du lundi 25 juillet 2005, vers 16:49,
Stephane Zuckerman <szuckerm@etu.utc.fr> disait:
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait,
ça commence au niveau 1.
Je pense qu'il parlait des runlevels de Linux (en System V)
S'il le colle au runlevel 0 sa bestiole, il faut qu'il la démarre en
tapant halt. À mon avis, il raconte juste n'importe quoi.
--
I CAN'T SEE DEAD PEOPLE
I CAN'T SEE DEAD PEOPLE
I CAN'T SEE DEAD PEOPLE
-+- Bart Simpson on chalkboard in episode BABF05
OoO Vers la fin de l'après-midi du lundi 25 juillet 2005, vers 16:49, Stephane Zuckerman disait:
Le modèle OSI du réseau appliqué au SGBD. Il faut l'oser. Ah, au fait, ça commence au niveau 1. Je pense qu'il parlait des runlevels de Linux (en System V)
S'il le colle au runlevel 0 sa bestiole, il faut qu'il la démarre en tapant halt. À mon avis, il raconte juste n'importe quoi. -- I CAN'T SEE DEAD PEOPLE I CAN'T SEE DEAD PEOPLE I CAN'T SEE DEAD PEOPLE -+- Bart Simpson on chalkboard in episode BABF05
Vincent Bernat
OoO Vers la fin de l'après-midi du lundi 25 juillet 2005, vers 16:44, "helios" disait:
avec un sgbdmv en plus de cracker via le remote il faudra que tu crack le system pick ou linux pour acceder a des fichiers qui ne sont pas les tiens tandis qu' avec vos sgbd il suffit d'avoir cracke le remote pour avoir tout les fichiers et droit du sgbd donc pick a plus de securite puisque que cracke le remote ne suffit pas
Stéphane, bon courage ! -- I WILL NOT USE ABBREV. I WILL NOT USE ABBREV. I WILL NOT USE ABBREV. -+- Bart Simpson on chalkboard in episode 2F33
OoO Vers la fin de l'après-midi du lundi 25 juillet 2005, vers 16:44,
"helios" <helios@com02.com> disait:
avec un sgbdmv en plus de cracker via le remote il faudra que tu crack le
system pick ou linux pour acceder a des fichiers qui ne sont pas les tiens
tandis qu' avec vos sgbd il suffit d'avoir cracke le remote pour avoir tout
les fichiers et droit du sgbd donc pick a plus de securite puisque que
cracke le remote ne suffit pas
Stéphane, bon courage !
--
I WILL NOT USE ABBREV.
I WILL NOT USE ABBREV.
I WILL NOT USE ABBREV.
-+- Bart Simpson on chalkboard in episode 2F33
OoO Vers la fin de l'après-midi du lundi 25 juillet 2005, vers 16:44, "helios" disait:
avec un sgbdmv en plus de cracker via le remote il faudra que tu crack le system pick ou linux pour acceder a des fichiers qui ne sont pas les tiens tandis qu' avec vos sgbd il suffit d'avoir cracke le remote pour avoir tout les fichiers et droit du sgbd donc pick a plus de securite puisque que cracke le remote ne suffit pas
Stéphane, bon courage ! -- I WILL NOT USE ABBREV. I WILL NOT USE ABBREV. I WILL NOT USE ABBREV. -+- Bart Simpson on chalkboard in episode 2F33
Guillaume L.
le theoreme de ferrarri n'a qu'un seul point commun avec le discrinant l'usages des coefficients pour resoudre l'equation , les discrimant
Répète après moi : dis-cri-mi-nant.
Guillaume Leconte.
-- You're not a beautiful and unique snowflake.
le theoreme de ferrarri n'a qu'un seul point commun avec le discrinant
l'usages des coefficients pour resoudre l'equation , les discrimant
Ce qui a remplace dbase, c'est access, une autre merdouille gentillete pour bidouiller.
Je croyais que access c'était la base que Microsoft a achetée à Sybase, auquel cas elle serait du même niveau de qualité que Oracle.
--
Michel TALON
talon
Stephane TOUGARD wrote:
Donc, si j'interprete bien, ton programme sait gerer tous les filesystem Linux (ext2, ext3, XFS, JFS, VFAT ...) et ecrit directement sur le file systeme sans passer par le noyau.
Il écrit peut être tout simplement sur des partitions "raw" comme pas mal de systèmes performants qui se respectent.
--
Michel TALON
Stephane TOUGARD <stephane@unices.org> wrote:
Donc, si j'interprete bien, ton programme sait gerer tous les filesystem
Linux (ext2, ext3, XFS, JFS, VFAT ...) et ecrit directement sur le file
systeme sans passer par le noyau.
Il écrit peut être tout simplement sur des partitions "raw" comme
pas mal de systèmes performants qui se respectent.
Donc, si j'interprete bien, ton programme sait gerer tous les filesystem Linux (ext2, ext3, XFS, JFS, VFAT ...) et ecrit directement sur le file systeme sans passer par le noyau.
Il écrit peut être tout simplement sur des partitions "raw" comme pas mal de systèmes performants qui se respectent.
--
Michel TALON
Jerome Lambert
Stephane TOUGARD wrote:
Ce qui a remplace dbase, c'est access, une autre merdouille gentillete pour bidouiller.
Je croyais que access c'était la base que Microsoft a achetée à Sybase, auquel cas elle serait du même niveau de qualité que Oracle.
Access est sorti peu après le rachat de Fox Software (SGBD Fox Pro, pour ceux qui s'en souviennent). L'inspiration vient donc de là...
Stephane TOUGARD <stephane@unices.org> wrote:
Ce qui a remplace dbase, c'est access, une autre merdouille gentillete
pour bidouiller.
Je croyais que access c'était la base que Microsoft a achetée à Sybase,
auquel cas elle serait du même niveau de qualité que Oracle.
Access est sorti peu après le rachat de Fox Software (SGBD Fox Pro, pour
ceux qui s'en souviennent). L'inspiration vient donc de là...
