Allons, allons ! Si UTF-8 était un progrès, ça se saurait.
Ça l'est, et ça se sait.
Tu as tort, et tu le sais.
X.B
Sauf qu'il faut repasser derrière pour corriger le millier de conneries que les "développeurs Mandrake" ont laissées passer. attaque gratuite ... vis vis de l'installe sur une machine vierge, un
live cd de base sera imbattable de la mise en configuration un rsync complete le live cd ou de la mise a jours urpmi s'acquitte de sa tache ... entre la 8.2 et la 10.0 il y a presque 3 ans et 5 versions ...
on croirait lire un newbee qui a tente une installe de redhat 5.2 il y a 4 ans et qui explique que linux c'est pas finis ...
Attaque pas gratuite du tout, de la part de quelqu'un qui a essayé Mandrake il y a quelques années et a été obligé de corriger un tas de ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^BINGO!!!!!!!!
permissions foireuses pour faire fonctionner ce qu'il voulait, et qui d'autre part voit encore maintenant ses collègues obligés de se livrer à toutes sortes de contorsions avec Mandrake. de quelles sortent ... paske la j'ai le syteme et j'ai tout ce que j'utilise
et vraiment je ne vois pas .
L'experience que j'en ai est qu'il faut d'abord demander quel est le probleme, plutot que de chercher a faire fonctionner la solutions qu'ils ont elaborés ... surtout quand il y a plusieurs approches ; par exemple avec un graveur, certain prefere donner les droits a l'usager d'autre creer un group et y faire entrer l'usager ... cette solution est plus souple car elle permet a plusieurs usager d'avoir acces au perif (au lock file pret) sans etre obliger de taper sur devfs. La premiere approche obligeant finalement a des contorsions inimaginables, est typiquement la solution elaboree par un usager standart, et celle que je deconseillerai une fois que l'on m'aura exposer le soucis, non pas les carence de la resolution. Et là mandrake peut rien pour toi.
Le jour où les développeurs bon bin c'est sympas de savoir qu'il existe encore des emplois salariés pour
des guignoles ...
Mandrake seront devenus sérieux, on en reparlera. Ca peut à la rigueur convenir pour une machine individuelle sur laquelle on a le temps de paufiner la configuration. Pour un développement en masse il faudrait être fou furieux pour s'y risquer.
Ce qui serait irresponsable ce serait de croire que mandrake, redhat ou suses sont LA solution l'incompétence ...
Mais bon j'ai pas mal travaille sur les systeme solais, et le nombre de binaire S-uid Root sont impressionnants ; surtout que si on supprime le bit root, le systeme devient bancale ...
Sauf qu'il faut repasser derrière pour corriger le millier de conneries
que les "développeurs Mandrake" ont laissées passer.
attaque gratuite ... vis vis de l'installe sur une machine vierge, un
live cd de base sera imbattable de la mise en configuration un rsync
complete le
live cd ou de la mise a jours urpmi s'acquitte de sa tache ... entre la
8.2 et la 10.0 il y a presque 3 ans et 5 versions ...
on croirait lire un
newbee qui a tente une installe de redhat 5.2 il y a 4 ans et qui
explique que linux c'est pas finis ...
Attaque pas gratuite du tout, de la part de quelqu'un qui a essayé
Mandrake il y a quelques années et a été obligé de corriger un tas de
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^BINGO!!!!!!!!
permissions foireuses pour faire fonctionner ce qu'il voulait, et qui
d'autre part voit encore maintenant ses collègues obligés de se livrer à
toutes sortes de contorsions avec Mandrake.
de quelles sortent ... paske la j'ai le syteme et j'ai tout ce que j'utilise
et vraiment je ne vois pas .
L'experience que j'en ai est qu'il faut d'abord demander quel est le
probleme, plutot que de chercher a faire fonctionner la solutions qu'ils
ont elaborés ... surtout quand il y a plusieurs approches ; par exemple
avec un graveur, certain prefere donner les droits a l'usager d'autre creer
un group et y faire entrer l'usager ... cette solution est plus souple car
elle permet a plusieurs usager d'avoir acces au perif (au lock file pret)
sans etre obliger de taper sur devfs. La premiere approche obligeant
finalement a des contorsions inimaginables, est typiquement la solution
elaboree par un usager standart, et celle que je deconseillerai une fois
que l'on m'aura exposer le soucis, non pas les carence de la resolution.
Et là mandrake peut rien pour toi.
Le jour où les développeurs
bon bin c'est sympas de savoir qu'il existe encore des emplois salariés pour
des guignoles ...
Mandrake seront devenus sérieux, on en reparlera. Ca peut à la rigueur
convenir pour une machine individuelle sur laquelle on a le temps de
paufiner la configuration.
Pour un développement en masse il faudrait être fou furieux pour s'y
risquer.
Ce qui serait irresponsable ce serait de croire que mandrake, redhat ou
suses sont LA solution l'incompétence ...
Mais bon j'ai pas mal travaille sur les systeme solais, et le nombre de
binaire S-uid Root sont impressionnants ; surtout que si on supprime le
bit root, le systeme devient bancale ...
Sauf qu'il faut repasser derrière pour corriger le millier de conneries que les "développeurs Mandrake" ont laissées passer. attaque gratuite ... vis vis de l'installe sur une machine vierge, un
live cd de base sera imbattable de la mise en configuration un rsync complete le live cd ou de la mise a jours urpmi s'acquitte de sa tache ... entre la 8.2 et la 10.0 il y a presque 3 ans et 5 versions ...
on croirait lire un newbee qui a tente une installe de redhat 5.2 il y a 4 ans et qui explique que linux c'est pas finis ...
Attaque pas gratuite du tout, de la part de quelqu'un qui a essayé Mandrake il y a quelques années et a été obligé de corriger un tas de ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^BINGO!!!!!!!!
permissions foireuses pour faire fonctionner ce qu'il voulait, et qui d'autre part voit encore maintenant ses collègues obligés de se livrer à toutes sortes de contorsions avec Mandrake. de quelles sortent ... paske la j'ai le syteme et j'ai tout ce que j'utilise
et vraiment je ne vois pas .
L'experience que j'en ai est qu'il faut d'abord demander quel est le probleme, plutot que de chercher a faire fonctionner la solutions qu'ils ont elaborés ... surtout quand il y a plusieurs approches ; par exemple avec un graveur, certain prefere donner les droits a l'usager d'autre creer un group et y faire entrer l'usager ... cette solution est plus souple car elle permet a plusieurs usager d'avoir acces au perif (au lock file pret) sans etre obliger de taper sur devfs. La premiere approche obligeant finalement a des contorsions inimaginables, est typiquement la solution elaboree par un usager standart, et celle que je deconseillerai une fois que l'on m'aura exposer le soucis, non pas les carence de la resolution. Et là mandrake peut rien pour toi.
Le jour où les développeurs bon bin c'est sympas de savoir qu'il existe encore des emplois salariés pour
des guignoles ...
Mandrake seront devenus sérieux, on en reparlera. Ca peut à la rigueur convenir pour une machine individuelle sur laquelle on a le temps de paufiner la configuration. Pour un développement en masse il faudrait être fou furieux pour s'y risquer.
Ce qui serait irresponsable ce serait de croire que mandrake, redhat ou suses sont LA solution l'incompétence ...
Mais bon j'ai pas mal travaille sur les systeme solais, et le nombre de binaire S-uid Root sont impressionnants ; surtout que si on supprime le bit root, le systeme devient bancale ...
george
Miod Vallat , dans le message <40cecc4a$0$21558$, a écrit :
Tu as tort, et tu le sais.
On a déjà eu cette discussion, tes arguments étaient foireux. La chose que tu n'as pas comprise, à mon avis, est que la longueur en caractères d'une chaîne de caractère n'est pas une donnée pertinente : ce qui compte, c'est la taille qu'elle occupe en octets et la taille qu'elle occupe à l'affichage.
Miod Vallat , dans le message <40cecc4a$0$21558$626a14ce@news.free.fr>,
a écrit :
Tu as tort, et tu le sais.
On a déjà eu cette discussion, tes arguments étaient foireux. La chose
que tu n'as pas comprise, à mon avis, est que la longueur en caractères
d'une chaîne de caractère n'est pas une donnée pertinente : ce qui
compte, c'est la taille qu'elle occupe en octets et la taille qu'elle
occupe à l'affichage.
Miod Vallat , dans le message <40cecc4a$0$21558$, a écrit :
Tu as tort, et tu le sais.
On a déjà eu cette discussion, tes arguments étaient foireux. La chose que tu n'as pas comprise, à mon avis, est que la longueur en caractères d'une chaîne de caractère n'est pas une donnée pertinente : ce qui compte, c'est la taille qu'elle occupe en octets et la taille qu'elle occupe à l'affichage.
Miod Vallat
On a déjà eu cette discussion, tes arguments étaient foireux. La chose
Tu les as trouvés foireux, nuance. De la même façon que je trouve foireux les arguments en faveur d'UTF-8 (mais moi, je sais que je suis du bon côté (-: )
que tu n'as pas comprise, à mon avis, est que la longueur en caractères d'une chaîne de caractère n'est pas une donnée pertinente : ce qui compte, c'est la taille qu'elle occupe en octets et la taille qu'elle occupe à l'affichage.
Et la taille en octets d'une chaîne UTF-8 est bornée, mais pas rapidement calculable, ce qui rend plus que casse-pieds tout traitement travaillant sur des sous-chaînes, comme des recherches d'expressions.
On a déjà eu cette discussion, tes arguments étaient foireux. La chose
Tu les as trouvés foireux, nuance. De la même façon que je trouve
foireux les arguments en faveur d'UTF-8 (mais moi, je sais que je suis
du bon côté (-: )
que tu n'as pas comprise, à mon avis, est que la longueur en caractères
d'une chaîne de caractère n'est pas une donnée pertinente : ce qui
compte, c'est la taille qu'elle occupe en octets et la taille qu'elle
occupe à l'affichage.
Et la taille en octets d'une chaîne UTF-8 est bornée, mais pas
rapidement calculable, ce qui rend plus que casse-pieds tout traitement
travaillant sur des sous-chaînes, comme des recherches d'expressions.
On a déjà eu cette discussion, tes arguments étaient foireux. La chose
Tu les as trouvés foireux, nuance. De la même façon que je trouve foireux les arguments en faveur d'UTF-8 (mais moi, je sais que je suis du bon côté (-: )
que tu n'as pas comprise, à mon avis, est que la longueur en caractères d'une chaîne de caractère n'est pas une donnée pertinente : ce qui compte, c'est la taille qu'elle occupe en octets et la taille qu'elle occupe à l'affichage.
Et la taille en octets d'une chaîne UTF-8 est bornée, mais pas rapidement calculable, ce qui rend plus que casse-pieds tout traitement travaillant sur des sous-chaînes, comme des recherches d'expressions.
Jerome Lambert
Le Tue, 15 Jun 2004 01:46:26 +0200, X.B a écrit :
Sauf qu'il faut repasser derrière pour corriger le millier de conneries que les "développeurs Mandrake" ont laissées passer. attaque gratuite ... vis vis de l'installe sur une machine vierge, un live
cd de base sera imbattable de la mise en configuration un rsync complete le live cd ou de la mise a jours urpmi s'acquitte de sa tache ... entre la 8.2 et la 10.0 il y a presque 3 ans et 5 versions ... on croirait lire un newbee qui a tente une installe de redhat 5.2 il y a 4 ans et qui explique que linux c'est pas finis ...
Je suis plutot d'accord avec Michel (bien que fervent utilisateur de Mandrake)
Entre les répertoires de /home mis par défaut en permission 755 et les assistants qui bousillent les configurations faites à la main, il y a de quoi faire *apres* l'installation
-- Jerome.
Le Tue, 15 Jun 2004 01:46:26 +0200, X.B a écrit :
Sauf qu'il faut repasser derrière pour corriger le millier de conneries
que les "développeurs Mandrake" ont laissées passer.
attaque gratuite ... vis vis de l'installe sur une machine vierge, un live
cd de base sera imbattable de la mise en configuration un rsync complete le
live cd ou de la mise a jours urpmi s'acquitte de sa tache ... entre la
8.2 et la 10.0 il y a presque 3 ans et 5 versions ... on croirait lire un
newbee qui a tente une installe de redhat 5.2 il y a 4 ans et qui explique
que linux c'est pas finis ...
Je suis plutot d'accord avec Michel (bien que fervent utilisateur de
Mandrake)
Entre les répertoires de /home mis par défaut en permission 755 et les
assistants qui bousillent les configurations faites à la main, il y a de
quoi faire *apres* l'installation
Sauf qu'il faut repasser derrière pour corriger le millier de conneries que les "développeurs Mandrake" ont laissées passer. attaque gratuite ... vis vis de l'installe sur une machine vierge, un live
cd de base sera imbattable de la mise en configuration un rsync complete le live cd ou de la mise a jours urpmi s'acquitte de sa tache ... entre la 8.2 et la 10.0 il y a presque 3 ans et 5 versions ... on croirait lire un newbee qui a tente une installe de redhat 5.2 il y a 4 ans et qui explique que linux c'est pas finis ...
Je suis plutot d'accord avec Michel (bien que fervent utilisateur de Mandrake)
Entre les répertoires de /home mis par défaut en permission 755 et les assistants qui bousillent les configurations faites à la main, il y a de quoi faire *apres* l'installation
-- Jerome.
george
Miod Vallat , dans le message <40ced945$0$21571$, a écrit :
Tu les as trouvés foireux, nuance. De la même façon que je trouve foireux les arguments en faveur d'UTF-8 (mais moi, je sais que je suis du bon côté (-: )
Pour ma part, j'ai abondemment réfléchi au problème d'implémentation, et implémenté quelques fois. Je sais donc à peu près de quoi je parle. Ça n'a pas l'air d'être ton cas.
Et la taille en octets d'une chaîne UTF-8 est bornée, mais pas rapidement calculable, ce qui rend plus que casse-pieds tout traitement travaillant sur des sous-chaînes, comme des recherches d'expressions.
Tu dis des bêtises, et sur plusieurs points.
Premier point : la recherche d'expression s'implémente toujours par un parcours de la chaîne, caractère par caractère. Il suffit donc d'une toute petite fonction ou macro pour passer d'un caractère au suivant, ce n'est certainement pas « plus que casse-pieds ».
Deuxième point : le travaille avec des sous-chaînes se fait aussi bien en UTF-8 dès lors qu'on n'est pas assez stupide pour représenter les sous-chaînes par des indexes en caractères.
Troisième point : c'est pour la représentation externe (fichiers, réseau) qu'UTF-8 surpasse complètement UCS-4. Dans ces situations, il est de toutes façons nécessaire de parcourir la chaîne entière ou d'avoir un canal d'information supplémentaire (stat, par exemple). Dès lors, ton objection est complètement caduque. Pour les chaînes stockées en mémoire par une application, une représentation sous forme de tableau d'entiers se justifie tout à fait, mais ce n'est pas ce dont il est question ici.
Miod Vallat , dans le message <40ced945$0$21571$626a14ce@news.free.fr>,
a écrit :
Tu les as trouvés foireux, nuance. De la même façon que je trouve
foireux les arguments en faveur d'UTF-8 (mais moi, je sais que je suis
du bon côté (-: )
Pour ma part, j'ai abondemment réfléchi au problème d'implémentation, et
implémenté quelques fois. Je sais donc à peu près de quoi je parle. Ça
n'a pas l'air d'être ton cas.
Et la taille en octets d'une chaîne UTF-8 est bornée, mais pas
rapidement calculable, ce qui rend plus que casse-pieds tout traitement
travaillant sur des sous-chaînes, comme des recherches d'expressions.
Tu dis des bêtises, et sur plusieurs points.
Premier point : la recherche d'expression s'implémente toujours par un
parcours de la chaîne, caractère par caractère. Il suffit donc d'une
toute petite fonction ou macro pour passer d'un caractère au suivant, ce
n'est certainement pas « plus que casse-pieds ».
Deuxième point : le travaille avec des sous-chaînes se fait aussi bien
en UTF-8 dès lors qu'on n'est pas assez stupide pour représenter les
sous-chaînes par des indexes en caractères.
Troisième point : c'est pour la représentation externe (fichiers,
réseau) qu'UTF-8 surpasse complètement UCS-4. Dans ces situations, il
est de toutes façons nécessaire de parcourir la chaîne entière ou
d'avoir un canal d'information supplémentaire (stat, par exemple). Dès
lors, ton objection est complètement caduque. Pour les chaînes stockées
en mémoire par une application, une représentation sous forme de tableau
d'entiers se justifie tout à fait, mais ce n'est pas ce dont il est
question ici.
Miod Vallat , dans le message <40ced945$0$21571$, a écrit :
Tu les as trouvés foireux, nuance. De la même façon que je trouve foireux les arguments en faveur d'UTF-8 (mais moi, je sais que je suis du bon côté (-: )
Pour ma part, j'ai abondemment réfléchi au problème d'implémentation, et implémenté quelques fois. Je sais donc à peu près de quoi je parle. Ça n'a pas l'air d'être ton cas.
Et la taille en octets d'une chaîne UTF-8 est bornée, mais pas rapidement calculable, ce qui rend plus que casse-pieds tout traitement travaillant sur des sous-chaînes, comme des recherches d'expressions.
Tu dis des bêtises, et sur plusieurs points.
Premier point : la recherche d'expression s'implémente toujours par un parcours de la chaîne, caractère par caractère. Il suffit donc d'une toute petite fonction ou macro pour passer d'un caractère au suivant, ce n'est certainement pas « plus que casse-pieds ».
Deuxième point : le travaille avec des sous-chaînes se fait aussi bien en UTF-8 dès lors qu'on n'est pas assez stupide pour représenter les sous-chaînes par des indexes en caractères.
Troisième point : c'est pour la représentation externe (fichiers, réseau) qu'UTF-8 surpasse complètement UCS-4. Dans ces situations, il est de toutes façons nécessaire de parcourir la chaîne entière ou d'avoir un canal d'information supplémentaire (stat, par exemple). Dès lors, ton objection est complètement caduque. Pour les chaînes stockées en mémoire par une application, une représentation sous forme de tableau d'entiers se justifie tout à fait, mais ce n'est pas ce dont il est question ici.
george
Jerome Lambert , dans le message , a écrit :
Entre les répertoires de /home mis par défaut en permission 755
C'est très bien, les répertoires home en 755.
Jerome Lambert , dans le message
<pan.2004.06.15.11.18.59.842999@swing.aretirer.be>, a écrit :
Entre les répertoires de /home mis par défaut en permission 755
Entre les répertoires de /home mis par défaut en permission 755
C'est très bien, les répertoires home en 755.
X.B
Entre les répertoires de /home mis par défaut en permission 755 et les bon certes ... va falloir leur en toucher un mot ...
assistants qui bousillent les configurations faites à la main, il y a de quoi faire *apres* l'installation la je m'inscris en faux : de linuxconf a yast en passant par m4, la pluparts
des assistant passent par un fichier qui 'recapitule' les donnees enregistree par l'assistant ... et generalement le fichier final (sauf s'il est tres simple) n'est que tres rarement "reversé" ... je voudrais bien voir d'ailleurs un reverse sur un sendmail.conf ... qui te genererait le M4 kivabien.
Entre les répertoires de /home mis par défaut en permission 755 et les
bon certes ... va falloir leur en toucher un mot ...
assistants qui bousillent les configurations faites à la main, il y a de
quoi faire *apres* l'installation
la je m'inscris en faux : de linuxconf a yast en passant par m4, la pluparts
des assistant passent par un fichier qui 'recapitule' les donnees
enregistree par l'assistant ... et generalement le fichier final (sauf s'il
est tres simple) n'est que tres rarement "reversé" ... je voudrais bien
voir d'ailleurs un reverse sur un sendmail.conf ... qui te genererait le M4
kivabien.
Entre les répertoires de /home mis par défaut en permission 755 et les bon certes ... va falloir leur en toucher un mot ...
assistants qui bousillent les configurations faites à la main, il y a de quoi faire *apres* l'installation la je m'inscris en faux : de linuxconf a yast en passant par m4, la pluparts
des assistant passent par un fichier qui 'recapitule' les donnees enregistree par l'assistant ... et generalement le fichier final (sauf s'il est tres simple) n'est que tres rarement "reversé" ... je voudrais bien voir d'ailleurs un reverse sur un sendmail.conf ... qui te genererait le M4 kivabien.
talon
X.B wrote:
Le jour où les développeurs bon bin c'est sympas de savoir qu'il existe encore des emplois salariés pour
des guignoles ...
Tu découvres? Je crois plutôt que c'est le cas général.
Mandrake seront devenus sérieux, on en reparlera. Ca peut à la rigueur convenir pour une machine individuelle sur laquelle on a le temps de paufiner la configuration. Pour un développement en masse il faudrait être fou furieux pour s'y risquer.
Ce qui serait irresponsable ce serait de croire que mandrake, redhat ou suses sont LA solution l'incompétence ...
Il n'est pas question de compètence ou d'incompétence. Pour un développement en masse il faut que "ça marche" sans *aucune* intervention.
Mais bon j'ai pas mal travaille sur les systeme solais, et le nombre de binaire S-uid Root sont impressionnants ; surtout que si on supprime le bit root, le systeme devient bancale ...
Oui, et alors? Tu crois que c'est le fin du fin de la sécurité de supprimer le bit suid root?
--
Michel TALON
X.B <moi@meme.fr> wrote:
Le jour où les développeurs
bon bin c'est sympas de savoir qu'il existe encore des emplois salariés pour
des guignoles ...
Tu découvres? Je crois plutôt que c'est le cas général.
Mandrake seront devenus sérieux, on en reparlera. Ca peut à la rigueur
convenir pour une machine individuelle sur laquelle on a le temps de
paufiner la configuration.
Pour un développement en masse il faudrait être fou furieux pour s'y
risquer.
Ce qui serait irresponsable ce serait de croire que mandrake, redhat ou
suses sont LA solution l'incompétence ...
Il n'est pas question de compètence ou d'incompétence. Pour un
développement en masse il faut que "ça marche" sans *aucune*
intervention.
Mais bon j'ai pas mal travaille sur les systeme solais, et le nombre de
binaire S-uid Root sont impressionnants ; surtout que si on supprime le
bit root, le systeme devient bancale ...
Oui, et alors? Tu crois que c'est le fin du fin de la sécurité de
supprimer le bit suid root?
Le jour où les développeurs bon bin c'est sympas de savoir qu'il existe encore des emplois salariés pour
des guignoles ...
Tu découvres? Je crois plutôt que c'est le cas général.
Mandrake seront devenus sérieux, on en reparlera. Ca peut à la rigueur convenir pour une machine individuelle sur laquelle on a le temps de paufiner la configuration. Pour un développement en masse il faudrait être fou furieux pour s'y risquer.
Ce qui serait irresponsable ce serait de croire que mandrake, redhat ou suses sont LA solution l'incompétence ...
Il n'est pas question de compètence ou d'incompétence. Pour un développement en masse il faut que "ça marche" sans *aucune* intervention.
Mais bon j'ai pas mal travaille sur les systeme solais, et le nombre de binaire S-uid Root sont impressionnants ; surtout que si on supprime le bit root, le systeme devient bancale ...
Oui, et alors? Tu crois que c'est le fin du fin de la sécurité de supprimer le bit suid root?
--
Michel TALON
Thierry Thomas
Mardi 15 juin 2004 à 11:11 GMT, Miod Vallat a écrit :
Et la taille en octets d'une chaîne UTF-8 est bornée, mais pas rapidement calculable, ce qui rend plus que casse-pieds tout traitement travaillant sur des sous-chaînes, comme des recherches d'expressions.
Tu reprendras bien un petit verre de sous-chaînes ? C'est bon pour les recherches d'expressions imagées. -- Th. Thomas.
Mardi 15 juin 2004 à 11:11 GMT, Miod Vallat a écrit :
Et la taille en octets d'une chaîne UTF-8 est bornée, mais pas
rapidement calculable, ce qui rend plus que casse-pieds tout traitement
travaillant sur des sous-chaînes, comme des recherches d'expressions.
Tu reprendras bien un petit verre de sous-chaînes ? C'est bon pour les
recherches d'expressions imagées.
--
Th. Thomas.
Mardi 15 juin 2004 à 11:11 GMT, Miod Vallat a écrit :
Et la taille en octets d'une chaîne UTF-8 est bornée, mais pas rapidement calculable, ce qui rend plus que casse-pieds tout traitement travaillant sur des sous-chaînes, comme des recherches d'expressions.
Tu reprendras bien un petit verre de sous-chaînes ? C'est bon pour les recherches d'expressions imagées. -- Th. Thomas.
