demik a écrit 58 commentaires

La plupart des implémentations de serveurs web et mail aujourd'hui le gèrent déjà. C'est généralement le coup d'une ligne en plus dans la configuration. Si le support de l'IPv6 est opérationnel côté kernel, le plus dur est fait.

Par exemple pour lighttpd, il suffit d'ajouter:
server.use-ipv6 = "enable"

Pour postfix, c'est plutôt :
inet_protocols = ipv4, ipv6

Pour cyrus, me semble pas avoir fait quelque chose de spécial, je crois que c'est une option à la compilation.

Grosso modo, un petit tour dans le manuel de chaque service, et c'est réglé !

Elle vient de poper pour moi à l'instant, par contre je ne reçois aucune annonce de routeur IPv6 sur l'interface qui est reliée à ma freebox (mode bridge)

Hmm, si c'est un 6200, alors c'est un 75 Mhz. Si le proc fait vraiement 180 Mhz, alors c'est un 6400 ou un des derniers 6320 PCI.

Le 6200 a besoin d'un kernel patché car il n'as pas de bus PCI, et n'est pas supporté par la branche principale du kernel (http://nubus-pmac.sourceforge.net/). les 6200 avaient une archi assez mauvaise, donc c'est vraiement trop de boulot pour rien. Si il a des slots PCI dedans (2 normalement, et un slot d'extension modem (CommSlot II), alors c'est un 6320/6400/6500.

BootX est le "loader" de Linux sur ces machines. Vu que les vieux MacOS n'ont pas de mémoire protégée, il marche comme ceci : il réécrit le kernel linux par dessus MacOS, fait jumper au début, et hop c'est partit.

Pour le problème de fichier non exécutable, c'est normal, mais difficilement explicable. En fait, MacOS utilise des fourchettes de données (un truc implémentée dans le FS), pour créer des sections dans un fichier, mais niveau FS. linux ne gérant pas ça comme MacOS, t'as juste la partie données qui arrive, pas la partie ressources, ce qui fait que t'as un exécutable incomplet sur le MacOS et non reconnu.

Là, sans stuffit installé, je vois pas trop de solution. Personnelement, j'ai un 6400 qui fait gate quelquepart, et il tourne plutot bien (850+ d'uptime). En plus le CPU est passif, c'est du bonheur) donc j'ai a ta disposition kernels et leur conf si tu as besoin. (enfin j'ai viré le support ATA chez moi, mais c'est à un coup de make)

Le seul problème que tu rencontreras, c'est BootX. Si t'arrives a copier BootX correctement sur le Mac, c'est gagné.

P.S. : un petit lien sur les fourchettes de données : http://en.wikipedia.org/wiki/Fork_%28filesystem%29

C'est malheureux, mais je vais te rassurer un peu. C'est a peu près inutilisable sur 64 bits également.

Nous sommes trois a avoir réalisé ce patch, le jour de la sortie, et on est arrivés à la même conclusion : le pilote est vraiment mauvais.

En pratique, si j'arrive a charger les modules, il se passe l'une des étapes si dessous (c'est une vraie roulette russe).
- plein de symboles indéfinis, il faut charger les modules dans un certain ordre, mais même avec le bon ordre, parfois ça pète (erreur au chargement, si on décharge ça KP)
- un beau kernel panic
- la machine freeze
- ça passe

Le coté amusant, c'est que d'un reboot sur l'autre, on a pas le même comportement.

si ça se charge :
- le son via alsa est craqué comme un vieux vinyle sale
- le son "boucle" un certain temps quand on l'arrête
- pas de SPDIF, pas de gestion des entrées auxiliaires (rack 5"1/4 en façade ou module externe)
- son 2.0 maximum (pas de 4.0 / 5.1 / 7.1 etc...)
- pas de 24 bits crystaliser, pas de CMMS-3D, pas d'EAX, pas d'accélération matérielle.
- le son via l'émulation OSS est correct, minus le bouclage comme indiquer ci dessus
- certains mixers ne marchent pas (je pense au graves / aigus, etc...)

en gros on se retrouve avec une SoundBlaster 16 ISA, et avec un son plus sale.

Bon après je suis assez mauvais en développement kernel, mais le code des pilotes est comment dire... mauvais. quelques extraits de tête des problèmes du pilote, j'en passe, et sûrement pas des meilleures. Si vous avez 15 minutes a perdre, chargez le pilote et regardez dedans, ça vaut le détour.

- le tar a ses fichiers datés de 2009
- l'installateur ne peut même pas se lancer sur aucune architecture, il ne fait même pas un uname correctement
- le tar contient un autre tar, qui ne possède pas les bons droits (ex, scripts shells et dossiers sans +x, configure en 234, etc...)
- le pilote n'as pas été compilé au delà du 2.6.15, et personne n'a bossé dessus depuis mai / juin (d'après ce que j'ai compris des sources)
- ils utilisent des types deprected du noyau (c'est marqué en gros en haut dans les .h)
- il manque a certains fichiers jusqu'à 4 includes pour compiler
- certains pointeurs mémoires sont castés dans des int ou équivalents
- #if 0, #define truc \n #ifdef truc, etc, typique d'un code alpha
- une grosse partie du code est du copié / collé des sources du pilote windows (il y a des références a des cartes audigy, des sound blaster live, des structures et des types windows redéfinis, etc).
- si je comprends bien le code, le driver était a la base un pilote oss, puis une sorte de wraper alsa a été rajouté par dessus.
- il y a des outils redhat (chkconfig) en dur dans les scripts d'installation et de configuration.

pour celle là j'ai un doute :
- Le pilote semble utiliser des sous fonctions de l'allocateur mémoire (SLAB), c'est pour ça qu'il ne peut fonctionner pas avec un SLUB. (un module a le droit de faire ça ?)

Bref, tu vois, distribution 32 bits ou pas, cela ne change pas grand chose. Le bon côté de ces pilotes, c'est qu'au moins, maintenant les gens du projet alsa ont quelque chose a regarder pour fournir un pilote de base (enfin je l'espère)

Je termine avec une citation d'Oliver McFadden (un bon programmeur qui fait du reverse sur les cartes ATI) : "I was expecting a relatively small kernel module, not a bloated userspace driver." (source : http://olivermcfadden.livejournal.com/9984.html)

Je me répond a moi même, mais c'est pour la bonne cause

Il est indiqué dans la FAQ du pilote qu'il est impossible de compiler avec gcc 4, ce qui est dommage.

Celà fait plus de 10 heures que je tripatouille dans les sources pour arriver a faire marcher le bazard, et finalement, j'ai réussi, j'ai du son. Je possède une X-Fi Platinium. Le LSPCI correspond a ceci :

05:02.0 Multimedia audio controller: Creative Labs SB X-Fi
Subsystem: Creative Labs X-Fi Platinum
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 23
Region 0: I/O ports at bc00 [size=32]
Region 1: Memory at fe800000 (64-bit, non-prefetchable) [size=2M]
Region 3: Memory at f8000000 (64-bit, non-prefetchable) [size=64M]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000

Ils ont utilisé pas mal de structures deprecated dans le code du pilote, + quelques trucs qui n'étaient pas a jour. (les macros INIT_WORK qui prenais plus le même nombre de paramètres, où j'ai du tricher un peu). L'installateur est assez mal fichu, et j'ai arreté de l'utiliser.

j'ai fait quelques patchs, même si la license ne le permet pas apparament, mais bon ils ont pas du trop tester leur truc, c'est sur.

Ils sont ici : http://blackbox.lostwave.net/x-fi/

j'ai fait un petit readme.txt qui explique vite fait comment procéder (sans utiliser l'installateur). Si le patch loupe sur le Makefile.info, regardez le .diff, c'est pas très compliqué, il y a juste les flags de gcc à changer, -DKBUILD_MODNAME=\"x-fi\" a rajouter aux CFLAGS, et le kpatchlevel a passer de 0 à 6.

Bonne chance

j'ai du son en 2.0, les mixers marchent. LE S/PDIF ne marche pas encore visiblement, mais c'est déjà cool.

Par contre un /dev/x-fi est apparu, me demande a quoi il sert, je vais investiguer.

J'ai une X-Fi, et j'attendais ces pilotes depuis longtemps. A première vue, l'installateur est assez moisi (un simple test sur uname même pas fait correctement), et les pilotes ne compilent pas (problème de headers).

Je regarde si j'arrive a tripatouiller dans le code, pour que ça marche.

(Debian 64 sid)

Si quelqu'un y arrive, serait sympa d'expliquer comment :)

Petite précision, pour le "bi-PPC 603 (à peu près l'équivalent d'un 486)", c'est pas tout a fait vrai.

Le PPC 603 était l'entrée de gamme de la seconde génération de PowerPC (le premier était la 601, y a pas eu de 602).
Il s'approchait plus du Pentium MMX / Pentium Pro en terme de performances que du 486.

C'est déjà le cas (voir macbidouille par exemple, ou des sites us type xlr8yourmac.com). Pour l'histoire, ma soeur possède cette machine, et chez elle ça marche, donc ne généralisons pas, en plus il y a une histoire de sous révisions. Donc ce n'est pas tout le monde, mais une partie non négligeable.

Sinon, pour ton problème, debian ppc tourne parfaitement dessus, (pour la carte son je ne suis pas sur), d'ailleurs Linux lui même utilise un G5, donc ça doit forcément tourner, ne désespère pas. Il faut penser aussi à regarder du coté de la branche kernel benh, il y a souvent des patchs qui marchent bien

Je répond pour le message en dessous aussi.

Le nom de l'entreprise est "Librepc", et elle sera située avenue de l'urss. (Finalisation du contrat pour le local, installation en aout et ouverture magasin en septembre).

Pour le salaire, vu que l'entreprise démarre, ne sera pas très important au début, mais il y aura des parties sur le bénéfice de l'entreprise en primes. A voir lors de l'entretient (pas l'autorisation de divulguer le chiffre ici)

Je ne sais pas ce que ça vaudra comme commentaire, mais il te faudrait une vraie carte son audio, avec sortie spdif. De toutes manière, c'est risible d'utiliser un vrai ampli home cinéma avec la qualité d'une carte son integrée... Tu me sembles vouloir de la qualité, vu que tu utilises du FLAC.

Je possède sur mon mac (oui bon), une carte M-Audio Delta 2496 [1]
Elle est supportée par Alsa c'est sur [2], par contre je ne sais pas au niveau du spdif, mais ça devrais fonctionner en théorie. Je possaidais aussi sur mon PC une Audigy 2 ZS [3], elle avait une sortie numérique qui semblait fonctionner sous Linux, mais elle est au format Jack, donc il fallait un adaptateur.

Voilà, en espérant que ça t'aide, les deux cartes se trouvent en dessous des 100 euros :) .La première est une carte pro entrée de gamme, la seconde une carte grand public haut de gamme. Pour avoir testé les deux, elle se valent, un avantage a la m-audio pour la connectique, et l'audigy pour le port firewire

[1]http://www.m-audio.fr/products/fr_fr/Audiophile2496-main.html
[2]http://www.alsa-project.org/alsa-doc/doc-php/template.php?company=Midiman%2FMAudio&card=Delta+Audiophile+2496.&chip=ICE1712+%28Envy24%29&module=ice1712
[3]http://fr.europe.creative.com/products/product.asp?category=1&subcategory=204&product=4915

ben, et le mars, alors ?

Actuellement, pour avoir lu la moitié du thread, ça a dérivé sur "La sécurité est subjective", et "Qu'est ce qui peut être considéré comme important pour la sécurité" =)

Ok, je comprends maintenant, je croyais que la personne utilisait le SAV public. Je suis d'accord avec toi, sauf sur ta dernière phrase. Le je m'en foutisme n'est pas spécifié par le monopole tout juste ébranlé de FT, mais par la politique de la société actuelle.

C'est presque partout pareil, nous sommes dans une société de consommation ou il faut vendre a tout pris (même de la merde), et le support après, on s'en bas un peu (trop). On fait un minimum, on suit le monopole (pas de support Linux, OS X très mauvais), dès que c'est un peu spécifique, la faute incombe à l'utilisateur.

Pour faire un //, cela me rappelle plusieurs problèmes avec ma voiture actuelle, il y a quelques années (coffre qui s'ouvre en roulant, cardan qui casse après 35 000 km, étrier qui reste bloqué, etc...). La réponse de plusieurs garages de la marque (j'en ai essayé plusieurs), étant du style "Mais vous faites quoi avec votre voiture", avec pour certains un très visible "j'en ai marre de voir ta poubelle, casse toi", en fond de pensée.

Pourquoi ? Ben de leur point de vue, je suis un client à ennuis, et je suppose que pour les fournisseurs d'accès c'est la même chose. On fournit le strict minimum, en espérant que ces clients là partent chez les concurents, comme ça on sera tranquiles, car après tout, les clients mécontents sont une minorité. Et puis vous comprenez mon cher monsieur, former des opérateurs à un bon niveau de technique, c'est cher, c'est moins rentable ! Profit, profit profit, quand tu nous tiens...

Je ne sais pas comment comprendre la chose, d'une part la conseillère France Telecom est une analphabète (je fais aussi pas mal de fautes, mais là bon, voilà...), ne ponctue pas ses phrases, etc...

Elle devrait aussi savoir qu'il faut indiquer les numéros de clients. De plus, il me semble qu'une agence France Telecom ne doit pas utiliser le service client, et qu'ils ont des numéros en interne pour ce genre de problèmes (je me souviens qu'une personne avait appelé sur un numéro privé devant moi et le problème était résolu en 30 secondes).

Bien que la réponse de la hotline semble robotique, ce n'est pas pire que ce que j'ai vu chez Free, et ce n'est pas la faute de la hotline cette fois ci je pense...

>N.B. : bloquer les pings n'est pas recommandé car il est contraire au >RFC. Mais si votre souhait est de rester le plus invisible quand vous >êtes connectés, alors bloquer le ping est une bonne méthode.

C'est pas forcément vrai (sauf idiotie de ma part) :
- Quand une machine est allumée, bloquer le ping renvera un timeout
- Si la machine n'est pas la, on aura un host unreachable, host is down, No route to host... etc

A partir du moment ou il y a un timeout, il y a 99 % de chances que vous êtes là donc ca ne ne rend invisible :)

Par contre, on peut mettre une règle qui limite le nombre de réponses par secondes vour éviter le flood, de tête c'est un truc du genre :

iptables -I INPUT -p icmp --icmp-type echo-request -m limit --limit 5/s -j ACCEPT

A adapter a votre configuration, bien sûr :)

Oui, elle fonctionne. J'ai une DC10(old) (celles d'avant les plus), qui fonctionne parfaitement avec les pilotes de série du 2.6.
Pour la old, seule l'acquisition marche, mais pas la sortie (chipset pas supporté pour l'encodage, un truc du genre), par contre pour la +, les deux fonctionnent normalement.
Il faut cependant passer un paramètre au module suivant le type de ta carte, comme indiqué ici :
http://mjpeg.sourceforge.net/driver-zoran/documentation.php

pour moi, ça donne "modprobe zoran card=0". J'utilise xawtv pour voir les entrées vidéo, mais je n'ai pas essayé de faire de l'acquisition, enfin normalement ça doit marcher, bonne chance :)

Merci à tous, les programmes vnc2swf ou wink semblent répondre pas mal à mes besoins !
Par contre pour le coup d'xvidcap, je connaissais, mais ça ne correspond pas à mes besoins pour une bonne raison : je pense que nous n'aurontpas les moyens techniques ou financiers pour héberger un serveur contenant des formations en avi ou mpeg, pour cause de débit (le contenu de la formation devra être aussi accessible d'internet via login/mdp)

Merci de l'astuce, je ne connaissais pas, mais je retombe sur les mêmes problèmes qu'avec latex, c'est difficile de faire un truc "bouge l'image machin.png de x1,y1 à x2,y2, (par exemple un curseur, ou une boite d'information qu'on rajoute par dessus le screenshot, etc...)"

Latex, c'est bien, on va utiliser pour les documents uniquement statiques, ou les versions imprimables, Par contre, pour les formations sur ordinateur, je cherche quelque chose de plus "multimedia" que latex :)

apt-get install acpid fait ça tout seul et bien plus encore

Ca va tout passer d'un coup

pour faire la transition, c'est facile :

apt-get update && apt-get dist-upgrade
(ça va charger beaucoup de trucs)
on répond a quelques questions
(ça gratte sec)
(reboot si on est parano)
(terminé)

Et mon m68k qui tourne depuis 1994...

Objectivement, même si je sais que la sarge serai la dernière stable pour mon m68k, si ça peut aider à releaser un peu plus vite, c'est pas plus mal (j'ai un serveur mail de prod en testing). Par contre, c'est ce qui à l'époque m'avait choisir debian, le nombre d'architectures supportées en // (actuellement, j'utilise 4 architectures en stable/testing/unstable : i386, m68k, ppc et amd64)

Je sais aussi que pas mal de "geeks" utilisent des debian sur des vieilles machines, car celles dernières consomment moins et/ou pour des restrictions budgétaires, ou tout simplement pour le fun (ça ne me dérange pas qu'ils mette 10-12 heures à compiler son noyeau). Etre pragmatique, c'est bien, mais il y aura toujours un minimum de casse !

Maintenant, si ça me dérange trop, ce sera NetBSD pour les non supportés, dommage...

Ton idée de mouvement naturel me rappelle un peu la loi de Darwin, et une certaine tendance de l'informatique actuelle (on à des machines puissantes, alors on code comme des gruiks, et on ne supporte plus les vieilles) --> Les plus puissants mangenat les plus faibles.

Forcément, ça coute, mais même si je serai un peu décu, je remercierai debian d'avoir supporté mon petit m68k aussi longtemps (peu l'ont fait)

Non, tous ne s'y sont pas mis.

J'ai du quitter mon logement 4 mois après l'ouverture de la ligne et un forfait xtense fidélité chez Wanadoo, Je n'ai rien eu à payer !

Pour les DCC vocaux et vidéo, il y a un client sur Mac qui fait ça depuis belle lurette : ircle [1] (shareware). Il s'appuyair sur les compresseurs / décompresseurs QuickTime

[1] http://www.ircle.com(...)

J'y suis aussi, j'allais le proposer, tu va le mettre sur stang ? (si le réseau est pas encore pété...)