Au niveau des améliorations apportées, vous trouverez :
- grâce au backport de la bibliothèque ctdb de la branche 4.0, Samba 3.2 est désormais capable de fournir une solution de serveurs de fichiers clusterisés ;
- Samba intègre désormais la prise en charge de configuration de type registre, ceci afin de permettre le paramétrage de manière plus simple qu'en parcourant et en modifiant un fichier de configuration ;
- Samba est désormais parfaitement compatible avec Windows Vista SP1 et Windows Server 2008 ;
- La gestion des partages chiffrés en se basant sur l'API GSSAPI ; cette innovation est d'ailleurs disponible uniquement grâce à Samba qui a fait le choix de proposer une extension du protocole CIFS ;
- Optimisations de l'empreinte mémoire via l'utilisation de la bibliothèque talloc ;
- Compatibilité IPv6 complète suite à la réécriture d'une partie du code dans cette optique.
Aller plus loin
- samba.org (19 clics)
- Annonce de la publication sous GPLv3 (3 clics)
- CTDB (5 clics)
- Talloc (5 clics)
# Compatibilité Vista, toussa
Posté par santos . Évalué à 7.
[^] # Re: Compatibilité Vista, toussa
Posté par ragoutoutou . Évalué à 7.
[^] # Re: Compatibilité Vista, toussa
Posté par GnunuX (site web personnel) . Évalué à 3.
Euh tu veux dire compatibilité !
[^] # Re: Compatibilité Vista, toussa
Posté par ragoutoutou . Évalué à 5.
[^] # Re: Compatibilité Vista, toussa
Posté par GnunuX (site web personnel) . Évalué à 9.
> étudié et créé volontairement pour supporter un dialecte, on peut parler d'interopérabilité
> non?
Samba parle le dialecte "Netbios", "SMB" et "CIFS" depuis la création du projet. Ce qui est nouveau c'est qu'il n'était pas compatible à un système donnée et une version spécifique. On parle de compatibilité.
Intéropérabilité = tout le monde parle le même langage
Compatibilité = on modifie le comportement pour parler a un système/logiciel spécifique et uniquement pour lui (il ne s'agit pas de modification de protocole ouvert ou standard).
Pour prendre un autre exemple :
html = interopérabilité des navigateurs (tous le monde code le même format ouvert)
mshtml = compatibilité des navigateurs (les navigateurs adaptent leur moteur de rendu pour proposer un rendu spécifique à un moteur de rendu concurrent spécifique).
Après tu peux ne pas voir la différence, mais je peux rien y faire.
[^] # Re: Compatibilité Vista, toussa
Posté par Julien Gilbert . Évalué à 10.
Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
[^] # Re: Compatibilité Vista, toussa
Posté par ragoutoutou . Évalué à 3.
"The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units".
A mon humble avis, eux non-plus n'ont rien compris...
[^] # Re: Compatibilité Vista, toussa
Posté par ragoutoutou . Évalué à 2.
http://fr.wikipedia.org/wiki/Interop%C3%A9rabilit%C3%A9
Il convient de distinguer « interopérabilité » et « compatibilité ». Pour être simple, on peut dire qu'il y a compatibilité quand deux produits ou systèmes peuvent fonctionner ensemble et interopérabilité quand on sait pourquoi et comment ils peuvent fonctionner ensemble. Autrement dit, on ne peut parler d'interopérabilité d'un produit ou d'un système que si on en connaît intégralement toutes ses interfaces.
dans la mesure où il s'agit d'une avancée dans la connaissance des interfaces...
Mais bon, libre à toi de continuer ton débat improductif.
[^] # Re: Compatibilité Vista, toussa
Posté par GnunuX (site web personnel) . Évalué à 3.
L’ interopérabilité est la capacité que possède un produit ou un système dont les interfaces sont intégralement connues à fonctionner avec d'autres produits ou systèmes existants ou futurs.
Sinon, cela voudrait dire que word et son .doc est un exemple d'interopérabilité.
[^] # Re: Compatibilité Vista, toussa
Posté par croux . Évalué à 2.
Je dirais plutôt que:
Intéropérabilité = tout le monde se comprend (par l'intermédiaire de traducteurs s'il le faut)
Car il ne faut pas se leurrer, l'intéropérabilité n'est pas nécessairement libre et gratuite...
[^] # Re: Compatibilité Vista, toussa
Posté par GnunuX (site web personnel) . Évalué à 2.
Plus qu'un long discours, voici ce qu'il dit sur l'interopérabilité : http://formats-ouverts.org/blog/2006/12/15/1040-une-page-htm(...)
Pour moi, samba<->windows xxx correspond plus au schéma 2 (le standard de fait dans les formats ou les protocoles) que au schéma 3 (l'interopérabilité des formats ou des protocoles).
Après il faut savoir ce qu'on entend par interopérabilité. Est-ce que passé des heures a comprendre le fonctionnement d'un protocole, a faire du reverse engineering, de l'analyse de trame, ... permet de "rendre compatible un logiciel a un autre" ou de leinteropérabilité ? Personnellement je pense pense que c'est uniquement pour le rendre "compatible".
[^] # Re: Compatibilité Vista, toussa
Posté par benoar . Évalué à 2.
Ca veut dire quoi cette phrase ?
[^] # Re: Compatibilité Vista, toussa
Posté par ragoutoutou . Évalué à 1.
[^] # Re: Compatibilité Vista, toussa
Posté par tipic . Évalué à 1.
A tel point qu'il n'est pas difficile de l'interdire en entreprise, pas plus que de migrer vers autre chose...pardon : Linux bien sûr.
Les coûts en monnaie trébuchante et sonnante aussi bien, et surtout , les coûts en jours-homme étant largement en faveur d'un système GNU/Linux.
Et pour les grincheux, il n'y a pas photo même en comptant la formation.
# Registre de configuration : plus simple ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Un registre de configuration, c'est plus simple qu'un fichier... C'est objectif, cet avis ?
[^] # Re: Registre de configuration : plus simple ?
Posté par Julien MOROT (site web personnel) . Évalué à 7.
Si tu cherches un pouillème de doc en plus, tu en auras sur l'annonce faite sur la mailing list samba : http://lists.samba.org/archive/samba/2008-July/141777.html
# Partage de fichier "portable"
Posté par Spack . Évalué à 3.
Cependant, Windows faisant la sourde oreille à tout protocole ne lui appartenant pas, la seul solution viable pour partager des fichiers entre plusieurs systèmes reste Samba...
Cela n'est-il pas un avantage pour Microsoft qui voit sont protocole (fermé) utilisé un peu partout ?
Cela dit un grand merci au projet Samba qui est vraiment utile dans ma vie de les jours mais dommage qu'il ne s'agisse pas d'un protocole un peu plus ouvert :(
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 0.
[^] # Re: Partage de fichier "portable"
Posté par Snarky . Évalué à 7.
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: Partage de fichier "portable"
Posté par Spack . Évalué à 8.
Bon d'accord c'est possible de le faire avec VFS pour FTP mais je trouve que FTP n'est pas vraiment prévu pour cet usage...
[^] # Re: Partage de fichier "portable"
Posté par Buf (Mastodon) . Évalué à 8.
[^] # Re: Partage de fichier "portable"
Posté par Larry Cow . Évalué à 5.
Ou à utiliser dans une de ses variantes SSLisées pour tout ce qui n'est pas anonyme. C'est correctement géré par suffisamment de clients et de serveurs libres pour que l'on s'en prive.
[^] # Re: Partage de fichier "portable"
Posté par Dring . Évalué à -3.
[^] # Re: Partage de fichier "portable"
Posté par Buf (Mastodon) . Évalué à 2.
Bref, à part quand la compatibilité avec quelque chose d'existant est primordiale, FTP ne devrait plus être utilisé. Quand il s'agit de mettre des fichiers à disposition de tout le monde, HTTP fait parfaitement l'affaire, et quand l'envoie de fichiers est nécessaire, SFTP est nettement meilleur.
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Partage de fichier "portable"
Posté par Buf (Mastodon) . Évalué à 2.
[^] # Re: Partage de fichier "portable"
Posté par Larry Cow . Évalué à 2.
[^] # Re: Partage de fichier "portable"
Posté par Buf (Mastodon) . Évalué à 4.
On a tout ce qu'il faut pour : transfert en binaire brut (pas d'encodage qui augmenterait le volume de données), et possibilité d'arrêt/reprise du téléchargement.
En plus de ça, c'est un protocole qui passe sans soucis tous les NAT/firewalls (au contraire du FTP, même anonyme)
[^] # Re: Partage de fichier "portable"
Posté par ragoutoutou . Évalué à -2.
Maintenant, encore une fois, les protocoles web ne sont pas des remplacements pour des protocoles "entreprise" et le ftp n'a pas grand chose à faire dans cette discussion... La contrepartie unix du cifs, c'est le nfs, pas le ftp.
[^] # Re: Partage de fichier "portable"
Posté par Buf (Mastodon) . Évalué à 2.
[^] # Re: Partage de fichier "portable"
Posté par ragoutoutou . Évalué à 0.
[^] # Re: Partage de fichier "portable"
Posté par Larry Cow . Évalué à 2.
Tout dépend de l'usage de CIFS dont il est la contrepartie. Il y a bien des entreprises où l'on utilise le partage réseau comme un FTP à peine amélioré (juste intégré à explorer, en fait).
Le genre "stockage d'archives", par exemple.
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Voila là chose qu'il faut que tu retiennes à tout prix pour ton cours de réseau : «TCP c'est fiable, si je veux du fiable, j'utilise TCP». Tu pourras fièrement l'énoncer à ton prof de réseau qui te congratulera d'une petite tape bienveillante sur la tête.
[^] # Re: Partage de fichier "portable"
Posté par ragoutoutou . Évalué à 3.
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 1.
Aller hop bisou!
[^] # Re: Partage de fichier "portable"
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
ça, il ne faudra pas lui dire trop fort, à ton prof de réseau.
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: Partage de fichier "portable"
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Par exemple, NFS peut tourner sur du UDP, je ne retrouve pas précisément, mais je suis 99% sur qu'il y a un méchanisme de checksum comparable à celui de TCP, et « man nfs » par le méchanisme de ré-émisson de requetes NFS quand elles sont perdues.
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Puisque tu as l'air de connaître un peu le sujet, est que tu serais me dire si au niveau performance cela est équivalent ? Bien sûr c'est fortement dépendant de comment on code la gestion...
Moi ce que j'avais retenu c'est que UDP est plutôt à utilisé dans les cas où on s'en fou de perdre des paquets, par exemple pour le streaming audio/video : si un paquet c'est égaré, tant pis, on continue sans l'important étant de permettre un rendu temps réel aussi fluide que possible.
En tout cas merci pour ton rappel. :)
[^] # Re: Partage de fichier "portable"
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Je connais pas particulièrement ;-).
Niveau performance, oui, ça dépends comment tu gère les pertes de paquets. Pour NFS, j'ai souvenir d'avoir lu dans le man que TCP était plutôt plus rapide vu que la ré-émisson en cas de perte se faisait au niveau paquet alors qu'en UDP c'était au niveau requete, mais j'ai un man différent sous la main qui ne parle pas de ça, et qui dit qu'UDP est le défaut, il doit y avoir une raison !
Sinon, un protocole non-fiable peut aussi être utilisé dans les cas où tu sais traiter les paquets dans le désordre : un paquet perdu ne t'empêche pas de continuer à traiter ce qui arrive au fur et à mesure et attendant la ré-émission.
[^] # Re: Partage de fichier "portable"
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
C'est d'ailleurs la raison d'être d'UDP Lite, si je me souviens bien. Il permet de restreindre cette somme de contrôle au début du paquet, sur une longueur arbitraire, notamment aux seuls en-têtes.
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 4.
Bien sûr qu'au niveau confidentialité ce n'est pas ça, mais tu peux utiliser sftp si tu veux du chiffrement.
Il serait bon aussi de prendre ma remarque dans son contexte : e répondais à la phrase «la seul solution viable pour partager des fichiers entre plusieurs systèmes reste Samba» qui me semble erroné, pour le partage de fichier multi-plateforme, ftp fait très bien l'affaire, exemples :
ftp://download.tuxfamily.org/cls/
ftp://ftp.gnu.org/
ftp://ftp.free.fr/
ftp//ftp.etc.org/
Je n'ai rien dit de samba que je n'ai jamais utilisé car je n'en ai jamais eu l'utilité, mais samba fait plus que le partage de fichier pour le peu que j'en sais (partage d'imprimantes par exemple).
[^] # Re: Partage de fichier "portable"
Posté par Buf (Mastodon) . Évalué à 5.
Mon reproche est spécifiquement dirigé contre FTP. Le problème est qu'il a besoin de 2 connexions, et la deuxième pose des tas de problèmes. Dans le cas où elle est créée dans le sens serveur => client (FTP actif), ça ne passe pas le NAT (ou alors avec réécriture des paquets sur le routeur), dans le sens client => serveur (FTP passif), ça pose problème au niveau du serveur si on veut mettre un firewall un peu restrictif. Bref, FTP est un mauvais protocole, pas parce qu'il a été conçu au siècle passé, mais parce qu'il s'adapte mal aux contraintes des réseaux actuels, et c'est pour cette raison qu'il faudrait éviter de l'utiliser.
Quand il s'agit de mettre des fichiers à disposition de tout le monde (FTP anonyme), on peut parfaitement utiliser HTTP.
SFTP est très bien, mais à part le nom et la fonction, ce protocole n'a strictement rien à voir avec FTP, il est basé sur SSH et n'utilise qu'une seule connexion, ce qui fait qu'il n'a pas les défaut que je cite au dessus.
[^] # Re: Partage de fichier "portable"
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Le problème est que c'est le NAT qui est mauvais pas FTP.
Le NAT n'apporte aucune sécurité, que des emmerdements. Le réseau internet a été conçu pour faire du point à point entre tous les membres du réseau.
Le NAT ne fait que retarder IPv6. Sans NAT, on aurait déjà IPv6.
Le FTP est un protocole en clair. Certe, le fait d'utiliser un double port est merdique (d'un point de vu d'aujourd'hui) mais n'importe quel firewall aujourd'hui sais suivre un connexion FTP.
Bref, je te trouve trop sévère vis à vis du FTP qui a rempli et qui remplit encore une tâche utile.
Par contre, je ne comprends pas comment on peut faire les protocoles suivants qui sont bien moins anciens et qui sont 100 fois plus merdique que le FTP :
- H323, ok c'est pas tout jeune et ca dérive des téléphonistes mais bonjours les ports. Va trouver un firewall qui filtre correctement une multi-session sur un pont + gatekeepers sur H323. Il n'y en a pas tant que cela qui marche vraiment.
- SIP, le concurrent du H323 qui vient des informaticiens. Une daube inconcevable de la part d'informaticien. C'est pas croyable que des gars ai pu pondre un truc pareil.
Bref, il y a de vieux protocole qui ont été conçu pour un internet sans NAT (et il ne devrait pas y avoir de NAT) qui ne sont pas si compliqué que cela et il y a des protocoles jeunes qui sont nés avec le NAT et qui n'aurait pas du voir le jour...
Laissons le FTP mourrir tranquillement comme gopher. Respect le FTP.
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 7.
[^] # Re: Partage de fichier "portable"
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Partage de fichier "portable"
Posté par BAud (site web personnel) . Évalué à 3.
Sinon tu en trouveras d'autres sur http://asso.univ-lyon2.fr/alaes/resnet36.htm (ah les pages web de 1996... nostalgie :D).
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Sinon pour liste de serveurs gopher : gopher://gopher.floodgap.com/1/world
À noter que tu peux utiliser firefox pour naviguer (c'est même ce qu'ils recommandent : gopher://gopher.floodgap.com/0/gopher/wbgopher )
[^] # Re: Partage de fichier "portable"
Posté par Batchyx . Évalué à 3.
FTP ne peut pas supporter l'IPV6, vu qu'il encapsule une IPv4 dans son protocole.
Et c'est pas trop le NAT qui empêche les connexions FTP, c'est plutôt les firewall (pour une bonne raison).
[^] # Re: Partage de fichier "portable"
Posté par Étienne . Évalué à 3.
http://www.ietf.org/rfc/rfc2428.txt
[^] # Re: Partage de fichier "portable"
Posté par Batchyx . Évalué à 1.
Et quels clients supportent cette extension ? pas le /usr/bin/ftp de chez moi en tout cas
[^] # Re: Partage de fichier "portable"
Posté par Larry Cow . Évalué à 1.
[^] # Re: Partage de fichier "portable"
Posté par Batchyx . Évalué à 3.
[^] # Re: Partage de fichier "portable"
Posté par Professeur Méphisto . Évalué à 6.
Ça c'est nimportenawak ;-)
[^] # Re: Partage de fichier "portable"
Posté par ragoutoutou . Évalué à 1.
Dans le monde moderne, on a des protocoles un peu mieux comme le nfs4 avec les extensions kerberos, le cifs, voir même sftp et les autres dérivés de ssh, ...
[^] # Re: Partage de fichier "portable"
Posté par psychoslave__ (site web personnel) . Évalué à 1.
C'est pas parcequ'un protocole est ancien qu'il est mauvais. Au contraire il y a de bonnes chances qu'il soit robuste et efficace dans le cadre des utilisations pour lesquelles il à été conçu.
[^] # Re: Partage de fichier "portable"
Posté par ragoutoutou . Évalué à 5.
On peut faire de bonnes soupes dans une vieille marmite tant que celle-ci n'est pas percée par la corrosion.
[^] # Re: Partage de fichier "portable"
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Pour me connecter à distance sur ma machine, ssh et sftp sont mes amis.
ftp est aussi bien pratique pour télécharger un paquet ou une image iso sur un serveur public. il est inutile de crypter la communication dans ce cas.
[^] # Re: Partage de fichier "portable"
Posté par ragoutoutou . Évalué à 2.
Sinon, pour un lan, le NFS c'est pas mal non-plus... nfs:// ... ça marche aussi...
[^] # Re: Partage de fichier "portable"
Posté par Xavier Teyssier (site web personnel) . Évalué à 4.
En même temps, si tu utilises Konqueror, fish est ton ami.
fish://login@machine/ton/chemin/ est commode et performant.
[^] # Re: Partage de fichier "portable"
Posté par benja . Évalué à 3.
[^] # Re: Partage de fichier "portable"
Posté par M . Évalué à 5.
Donc telnet n'est peut etre pas adapter au réseaux publique, mais s'il est limité au réseau privé il peut etre tres pratique...
C'est pareil avec FTP...
[^] # Re: Partage de fichier "portable"
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Partage de fichier "portable"
Posté par Ellendhel (site web personnel) . Évalué à 2.
[^] # Re: Partage de fichier "portable"
Posté par Sarcastic . Évalué à 5.
D'ailleurs, dans ce dernier cas, ça permet de faire des cartes qui ne dépendent (presque) pas de l'OS (En fait, suffit de prendre, par exemple, un chipset ethernet bien supporté, pour faire l'interface avec la machine hôte) avec les drivers et quelques outils intégrés (Donc un développement plus facile, sur un système unique et connu, pas besoin de faire de tests sur X plateformes, et tout et tout).
Donc, Telnet, c'est quand même vachement bien dans certains cas.
Et faut pas oublier que s'il y a un telnet dans Windows, ben, il y manque quand même SSH par défaut.
[^] # Re: Partage de fichier "portable"
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
non
[^] # Re: Partage de fichier "portable"
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Tiens tiens, on retourne à un sigle qui ne contient plus « common »,serait-ce un hasard ?
[^] # Re: Partage de fichier "portable"
Posté par Benoit . Évalué à 1.
Il y a quand même SFU (client/serveur NFS/NIS sous Windows : http://www.microsoft.com/france/windows/sfu/default.mspx) qui ne marche pas si mal.
AppleShare/AppleTalk sont disponible sous Linux.
Voilà ma contribution à 2 balles.
[^] # Re: Partage de fichier "portable"
Posté par Raphaël G. (site web personnel) . Évalué à 3.
# Chez les pros
Posté par Philippe M (site web personnel) . Évalué à 8.
Il ne faut surtout pas que le projet s'arrête et je pense que ceux qui critiques l'acharnement des dev à vouloir faire communiquer Windows, autres avec Linux en réseau ne connaissent pas toute les contraintes en environnement pro. La plus facile à comprendre est l'utilisation au niveau utilisateur de logiciel qui fonctionne uniquement en environnement Windows... Oui il y a Qemu, Wine, VirtualBox... Mais je vous rappel que nous avons des utilisateurs qui ne veulent pas (et c'est normal) ce prendre la tête avec un montage informatique complexe et incompréhensible.
Born to Kill EndUser !
[^] # Re: Chez les pros
Posté par jms . Évalué à 5.
Par ailleurs, suite à cette dépêche, j'ai testé Samba 4 (alpha 4).
Et bien... c'est vraiment prometteur ! On met en place un domaine encore plus rapidement (à mon goût) qu'avec un Windows 2003 !
Plus besoin de s'embêter avec un OpenLDAP (mais si on veut, on peut à priori), une serveur LDAP est déjà intégré.
Et quelle "joie" (oui, faut pas déconner non plus hein) quand le XP s'intègre du premier coup dans le domaine !
Bref, un excellent boulot !
Voiçi le howto que j'ai suivi pour ce test (sur une Etch): http://wiki.samba.org/index.php/Samba4/HOWTO
[^] # Re: Chez les pros
Posté par Philippe M (site web personnel) . Évalué à 2.
Born to Kill EndUser !
# Samba,NFS,securite
Posté par GNUtoo . Évalué à 0.
sinon je trouve NFSv3 plus rapide que samba(sur un réseau gigabit ethernet),j'ai essaye NFSv4 mais il ne permettait pas de faire un chown(donc midnight commander ralle a chaque fois)
sinon est il possible de chiffrer les mots de passe transmis par le réseau avec NFSv4 sans gssapi/kerberos? car si le serveur kerberos est compromis...toutes les clees prives sont compromises
en gros quelle est la solution idéale,c'est a dire un réseau rapide et sécurise pour machines GNU/Linux uniquement(pour communiquer avec crimosoft windows il y'a toujours samba)
[^] # Re: Samba,NFS,securite
Posté par olivn . Évalué à 3.
CIFS est très bavard et extrêmement sensible à la latence.
[^] # Re: Samba,NFS,securite
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Je ne sais pas, mais ça rejoint un problème que j'ai eu. Mettre en place un système de fichiers partagé entre deux machines GNU/Linux en environnement non maîtrisé (donc chiffrement indispensable, au moins des mots de passe), et bien, NFSv4, avec kerberos, quelle usine à gaz… j'ai essayé, mais pas réussi. Donc Samba. :-)
[^] # Re: Samba,NFS,securite
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
NFSv4 a été conçu pour être transportés sur internet. Donc il n'y a pas de soucis à ouvrir un serveur NFSv4 sur un firewall (si l'implémentation est correcte, bein sur).
# Petit détail de français
Posté par Decool Merire . Évalué à 2.
(La faute revient à ces opérateurs téléphoniques, fiers de vous annoncer "suite à votre dernier appel, il vous reste x euros de crédit"... Ainsi, c'est passé dans le langage courant.)
[^] # Re: Petit détail de français
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: Petit détail de français
Posté par NicoToub . Évalué à 3.
J'ai trouvé ça, mais je ne sais pas ce que ça vaut : http://www.depeche.soquij.qc.ca/linguistique/ling20020121.ph(...)
--- citation ---
Chronique linguistique
Impropriétés : «Suite à»
L'expression «suite à» constitue une abréviation fautive des locutions suivantes, que l'on devrait toujours utiliser au long:
1) Comme suite à ou pour faire suite à; ces locutions signifient à un correspondant que l'on reprend une question traitée précédemment, oralement ou par écrit, mais non nécessairement que l'on répond à sa lettre, ce qui s'exprime mieux par la locution en réponse à, tout simplement.
2) À la suite de, qui comporte l'idée de conséquence. À la suite de ses efforts soutenus, il a pu achever son travail à la date promise.
3) Par suite de, qui signifie elle aussi «en conséquence de».
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.