-=[ silmaril ]=- a écrit 1472 commentaires

>Ce que je veux faire c'est simplement avoir la possibilité d'envoyer des mails depuis un site hébergé en local sur ce serveur.

C'est pas compliqué pourtant :
aptitude install postfix
et c'est tout Il n'y a aucune autre modification a faire pour installer postfix en relay local.

A part eventuellement rajouter un
relayhost=smtp.tonprovider.com
si besoin.

La conf debian par défaut est largement suffisante pour ton besoin enoncé.

1/ lire la doc sur le HTTP
2/ relire la doc apache
3/ re-relire la doc sur mod_rewrite

je t'aide un coup: QUERY_STRING

Tu a calculé la bande passante des sockets locales ?

De toute façon ce truc "obsolete" te permet plus de chose et plus facilement que les système "plus près du matériel" donc ce serait stupide de s'en séparer. Surtout que les terminaux X et l'affichage
déporté d'applications, n'en déplaise a certains c'est toujours très utilisé.

Ensuite quand on voit les perfs que sont capables de tirer enlightenment sur le système 2D, ou les jeux natif 3D je ne vois pas de raison de changer.

Les plus gros soucis de perfs et de resources des applications X11 sont plus souvent lié à l'utilisation de N couches de toolkits et autres abstractions qu'au dispositif X11 en lui même

Yes ! Copaing !

Vive xterm et fluxbox !

/me comprend pas bien ce que tu veut
tu met une ip fixe a une interface configurée via dhcp .... quel interêt ..

si tu veut vraiment pouvoir utiliser indiferement tes deux interfaces regarde du coté des bridges (brctl)

rien d'étonnant à cela, la gestion des comparaison de chaines de find, ls, sort, et autre est la même, celle de la libc.

peu de chance qu'un outil marche si un autre ne marche pas ..

Quand à ton problème, je pense qu'il est déjà réglé:
http://osdir.com/ml/linux.debian.internationalization.genera(...) :
>e.g. we can now sort
> according to our braindead French collation rules, as specified in
> ISO 14651 ;)

so => aptitude install belocs-locales.*

1/ Attention le HIGHMEM64 permet en effet au kernel de gérer
les 64go de RAM, par contre les soft eux n'auront accès qu'a 2Go ou moins.

2/ oui, si ta fedora ne propose pas de noyau en 64G par défault il te
faudra le recompiler manuellement a chaque fois, je ne vois pas bien
comment il pourrait en être autrement.

3/ maintenant le 64b n'est pas qque chose de définitif. Tu peut booter un kernel 64 avec un système 32bits.
Certains trucs n'aiment pas (genre strace/gdb) et encore ça dépend de la version du kernel.
Et même tu trouve maintenant sur les dernières debian 64 (donc ça doit exister ailleurs) des paquets contenant les libs 32b les plus utiles (plus besoin de chroot dans la majorité des cas). Et en dernière instance il reste la possibilité d'avoir un chroot contenant un deuxième système 32 bits complet.

Après oui, le 64 marche bien. Marchera t'il pour toi, dans tes conditions avec ta distribution et tes softs c'est une autre question..
De ce que tu donne je ne vois que wine qui pourrait poser des soucis,
tout le reste est packagé 64 depuis longtemps maintenant, mais wine aucune idée. Les soft windows étant 32 il te faudra un wine 32 sans aucun doute. après faut voir ta distribution, ce qu'elle annonce etc..

Tu a dût faire des masses de recherches effectivement, tout est expliqué à tord et a travers sur le net mais bon.

Site de ref. sur asterisk: http://www.voip-info.org/
Livre de ref. sur asterisk: http://www.alexburke.ca/asterisk-tfot.pdf

Site français pas mauvais: http://www.asterisk-france.net/
Forum: http://www.asterisk-france.net/community/

Et un exemple de ce que tu cherche:
adaptateur ATA reseau:
http://www.opcom.fr/product_info.php?manufacturers_id=7&(...)
carte multilines analogiques:
8 ports: http://www.opcom.fr/product_info.php?manufacturers_id=7&(...)
24 ports: http://www.opcom.fr/product_info.php?manufacturers_id=7&(...) (necessite patch 19" et cable de liaison)

C'est de l'historique, l'objectif était de protéger les utilisateurs
des vilains virus/keylogger qui existait à l'époque (sachant qu'il y a
peu de chance qu'ils existent encore ...) qui réagissaient mal au
ctrl-alt-suppr (ie ils le repassaient au bios et donc => reboot

notez que maintenant les keylogger ne marchent plus, mais il est
devenu très facile de récupérer le password en clair d'une session
ouverte .... cherchez l'erreur !

xargs n'a plus aucun interêt face aux derniers find,
l'utilisation de '+' à la place de ';' copie le fonctionnement de xargs
si besoin, et l'option -delete supprime meme le besoin de fork
d'un /bin/rm

à les "nouvelles technos" super à la mode, que si tu l'a pas
t'est mort ...

Cette histoire sur DWTF resume assez bien les choses:
http://thedailywtf.com/Articles/The-Upgrade-Treadmill.aspx

>... sauf que la deuxième commande n'arrive jamais évidemment, je viens de scier la branche sur laquelle je suis assis.

ah ?
tu a vu ça ou ?

je fait ça depuis 3 ans sans soucis (même si je préfère activer un telnet a coté, juste au cas ou, pendant l'opération.
le ssh stop, arrête le démon ssh, mais ne tue pas les connections
actives, donc pas de souscis tant que tu ne te déconnecte pas

autre possibilitées avec un find récent:

1/ execution par lot, comme xargs:
find repertoire_de_base -name "*.toto" -exec rm \{\} \+

2/ fonction dédie:
find repertoire_de_base -name "*.toto" -delete

Mieux encore:

1/ find bla -exec /bin/rm {} \+
le + à la place du ; modifie le fonctionnement de exec et le rend similaire à xargs

2/ find bla -delete
bon la c'est un peu specialisé par contre :)

Dis-toi que s'ils piquent c'est qu'ils sont pas encore mort :)

>et le 851 pour la téléphonie (avec un bail dhcp particulier et un h.323
>apparemment non standard).

De la a supposer que les flux téléphonie des livebox normales sont sur le vpi/vci 8/51 il n'y a qu'un pas.

attention toutefois, de meme que free (enfin rani) à été très clair sur l'usage de freebox modifiées sur son réseau, il est pas dit que FT apprécie beaucoup que l'on se balade sur leur reseau VoIP ...

Même si j'utilise enormement la CLI, s'il y a bien un moment ou je sors
une interface graphique c'est bien pour naviguer dans l'annuaire LDAP

Mais bon j'utilise GQ pour cela et a postériori je me dit que c'est n'est pas forcement à ce type de frontend que tu faisait reference....

c'est pas qu'ils repcercutent mal, ce qui impliquerait une/des erreurs,
mais bien une volantée de ne pas donner les mêmes serveurs pour
le relay de mail des utilisateurs et la reception de mail depuis internet.

J'avoue que je vois pas trop l'intérêt de l'opération, mais bon
tu as essayé simplement de rajouter un filtre dans adblock /
adblock plus ?

d'abord il a dit qu'il était sous gnome hein
et ensuite il a bien précisé qu'il voulait le faire de temps en temps et
non de façon permanente

Tu fait une policy spéciale dans le NS25 qui match le trafic FTP et tu
active l'option counting dans les options avancées de la policy.

Hum un ramdisk de 100Mo sur une machine avec 32Mo et pour
en plus mettre de swap dessus .... je crois pas non.

Quand à l'utilisation de ndb pour faire du swap:
>Current state: It currently works. Network block device seems to be
>pretty stable. It was originaly thought that it is impossible to swap
>over TCP. This turned out not to be true, though the patch required
>to make it safe has not been forward-ported to any reasonably
>recent kernel.

A priori c'est pas rentré en mainline.

Ah si pour la question "quel est le charset des donnees", ma solution
fut: hexdump -C sur le fichier .MYD (en MyISAM).
J'ai analysé la sortie pour trouver une chaine avec accents que je connaissait et c'est la que j'ai vu qu'un accents prenait 4 octets au niveau stockage.

J'ai eu des problèmes similaires au tiens (enfin je pense):

une base déclarée en UTF8 contenant des données UTF-8 qui avaient
étés traités en tant que données latin1 et donc reconverties (en clair un "é" prenait 4 octets dans la DB).
Avec un cgi en perl qui traitait si connectait à la base en latin1 mais qui affichait dans des pages UTF8 ça passait, par contre dès que tu
voulait nettoyer le bordel ///

ma 'solution' à été d'utiliser mysqldump + iconv pour obtenir des
données +/- correctes et de nettoyer a la main les bouts de codes restants.

l'effort nécessaire à faire des produits qui fonctionnent correctement est sans doute radicalement inférieur à l'effort nécessaire à l'implémentation d'une telle usine à gaz permettant la reinitialisation de la CG.

C'est là que tu te trompe amha. Tout est lié: comme le marché est dirigé par les coûts et les perfs si les gros vendeurs de cartes puis d'OS ont décidé de faire comme ça c'est bien parce que économiquement c'est le plus rentable.

Il est beaucoup (et de loin) plus facile de concevoir des palliatifs logiciels à un matériel défaillant que fiabiliser le matériel.
Les coûts d'ingénierie sur les puces, et les coûts de fabrications sont de loins supérieurs au cout d'une équipe de r&d logicielle.