ragoutoutou a écrit 1515 commentaires

On moinsse mais ne répond pas à la question.

Ben oui, mais bon, c'est le jeu sur linuxfr...

Enfin, soit perso je trouve que ça mérite moinssage parceque tu insistes sur un point qui s'avère être complètement bidon, gratuit et non fondé... Cette carte mère n'est pas vendue avec linuxbios et ne le sera sans doutes jamais.

Je moinsserais volontiers aussi les modérateurs pour avoir laissé passer une news de première page aussi bidon...

Pas pareil... les intégrateurs doivent avoir accès au code source pour adapter C.E. au hardware embarqué et donc ils DOIVENT pouvoir recompiler tout vu que les architectures peuvent être très variées, alors qe XP est destiné aux x86. Dans le premier cas, l'ouverture du code est une condition sine qua non à l'existence même du business car elle fait partie de l'offre, alors que XP, c'est pour des raisons légales et politiques.

Est-ce que ça pourrait être un problème plutôt au niveau de grub? Genre un problème d'identification de disque? tu as essayé de démarrer depuis le cli de grub?

Et au niveau APIC? Si le kernel est compilé avec support apic, essaye de charger le kernel avec "noapic" en paramètre, pour voir...

Quand je disais ancien, je me référais au jeu d'instruction qui est équivalent à celui d'un k6-2 si ma mémoire est bonne...

ok, tu as donc i386 comme variant... important...
Tu as essayé avec i586 aussi?

Et au niveau des paramètres du kernel?

Le Geode LX est assez ancien, il est possible que les paramètres de compilation utilisés pour les distributions récentes posent problème (par exemple sollicitant des extensions/instructions cpu non désirables).

Dans BuildRoot, tu as quels paramètres de compilation?

Pas bravo pour la dépêche...

En la lisant, je me dis "super, une carte mère vendue avec un linuxbios"

En regardant de plus près les diverses infos disponibles sur le web je vois que cette carte mère est déjà vendue sans LinuxBios depuis presque un an.

Vu l'impossibilité de trouver une source sérieuse concernant une éventuelle attitude de Gigabyte par rapport à LinuxBios, je pense que la vérité est "LinuxBios supporte la M57SLI-S4", et non "Gigabyte va vendre la M57SLI-S4 avec LinuxBios"

Bref, une dépêche parlant un peu plus du boulot fourni par Yinghai Lu (AMD) qui a implémenté le support du MCP55 et un peu moins de choses non vérifiables aurait été souhaitable.

non, la 3.0.24 (décidément, c'est dommage qu'on ne puisse pas corriger un message après coup sur ce forum)

En fait, je date un peu...

La version 3.0.23c de samba, sortie le 5 février, corrige le problème...

L'accès à des répertoires partagés d'une machine sous vista depuis un client samba est impossible à l'heure actuelle. Microsoft, ayant changé le protocole (et vraisemblablement avec des chipotages pour être incompatible avec samba).

Il faut donc attendre un peu qu'une nouvelle version de Samba sorte, les auteurs étant au courant depuis un bout de temps ça ne devrait pas trop trainer...

Si oui, avez vous une solution, sachant que de plus en plus d'utilisateurs auront vista, bref si on veut prouver que linux est intéressant, il ne faut pas bloquer sur ce genre de choses (même si je suis quasi sûr que MS a encore fait une modif pour limiter l'intéropérabilité).

Je dirais surtout que c'est la preuve que vista est inintéressant dans un environnement où l'interopérabilité est cruciale... Une bonne raison pour les entreprises ayant un réseau mixte Windows/Linux pour ne pas passer au nouvel OS de Microsoft.

J'ai oublié de preciser que si je reaffiche le contenu du textarea (enregistré dans ma BD) dans un autre textarea les sauts de lignes, ect sont pris en compte....

Je suppose donc que ton problème concerne donc l'affichage du champ dans une page html...

Pour info, les retours à la ligne que tu obtiens en appuyant sur enter dans un textarea sont des retours de type texte et pas de type html, ils ne sont donc pas interprétés comme des retours à la ligne lorsqu'ils sont affichés dans une page web... un retour à la ligne en xhtml est symbolisé par

non, mais une erreur peut être généré en cas de violation de contrainte d'unicité... et puis les clefs composites, ça existe...

Filtrer l'output, c'est pas nécessaire dans la mesure où tu es le seul utilisateur de la machine... donc à part si ça t'amuse follement, je laisserais tomber cette partie là...

Ensuite, la partie de filtrage sur l'input est franchement lourde, rigide, moche... il serait plus simple et plus logique d'utiliser smart-drop (permet de faire des drops, reset, des reject, ... basés sur des limites) et statefull-accept...

Un conseil aussi, à part si ton rêve est d'être totalement invisible, laisse l'icmp, c'est toujours intéressant pour la découverte de mtu...

J'ai peur qu'avec du routage ce soit un peu rigide alors que je veux pouvoir changer d'interface réseau qd je le souhaite.

Tu essayes de faire quoi à la fin?

Pour quelle raison aurais-tu besoin de changer d'interface???

T'as deux connections internet et tu essayes de faire du load balancing dessus?

ça semble être un problème de routage...

Normalement, si tes routes sont correctement définies, ton player utilisera l'interface adaptée pour contacter le serveur en question...

Il faudrait que tu expliques un peu ton étrange situation.

on peut lui reprocher de raconter des conneries, pour ne pas dire des mensonges dans ses "explications"... c'est bien plus un problème d'emprise sur le marché, de défense d'un monopole, qu'un problème de sécurité... mais bon, c'est comme partout, on défend tout et n'importe quoi au nom de la sécurité...

les DRM peuvent pas être faits autrement.

Certes, les DRM sont par définition de la sécurité par l'obscurité, mais l'approche d'Apple atteint des sommets de n'importe quoi...

Microsoft a son système DRM accessible aux différents constructeurs de lecteurs portables et ce système DRM c'est pourtant fait moins malmener par des hacks que celui d'Apple...

le prétexte d'Apple est donc un faux prétexte vu que les autres acteurs du marché s'en sortent mieux.

En partie, il cite que plus l'algorithme est connu de monde, plus il sera facile de le contourner.

c'est une approche sécurité par l'obscurité assez idiote... rétrograde...

ça pourrait se traduire par "on est médiocres et on ne veut pas que ça se voit trop, on risquerait de retrouver nos algorithmes dans le bêtisier de la cryptographie 2007... "

A force de rester en club fermé, le drm d'Apple finira par disparaitre au profit des drm de billou...

Il s'agit d'une mesure d'auto protection de la part de Steve Jobs... Apple est en ligne de mire de l'U.E. pour son système DRM qu'il ne veut même pas licencier à d'autres constructeurs de balladeurs, alors plutôt que de licencier son système DRM à la concurrence, il renvoie l'U.E. face aux majors en disant "Les drm, c'est pas moi, c'est eux, en plus c'est des entreprises européennes, démerdez-vous avec eux", ce qui n'est pas totalement faux, mais ne répond pas à la question posée qui est "pourquoi apple n'ouvre t'il pas ses drm aux concurrents".

Bref, faut pas croire que Steve Jobs soit du côté anti-drm, il est plutôt dans une optique où, pour éviter d'être obligé à céder à la pression de l'U.E., il cherche à s'abriter derrière les majors et cherche à garder le beau rôle... bref, juste une man½uvre politicienne, une esquive.

et ca permettait de faire repartir le disque pour qques années.

ça dépend du type de défectuosité... Pour les secteurs "naturellement défectueux", ça peut aller (il suffit de réallouer ceux-ci sur des secteurs de réserve) , par contre si les secteurs lâchent pour une raison mécanique, ça ne sert pas à grand chose, d'autres claqueront vite après... par exemple, cette manip était inutile face à la sinistre série 60GXP ...

La masse des développeurs du libre n'a probablement pas encore atteint une masse critique qui lui permette de prendre tranquillement en charge la plupart des gros projets.

Ben, disons que les développeurs du libre s'intéressent en priorité aux projets libres... ce que xara n'est pas encore ...

Qui sait, une opération comme celle faite pour libérer bender serait peut-être nécessaire...

d'abord, met ton int en "non signé", c'est pas la peine de perdre la moitié de la capacité pour stocker des nombres négatifs qui n'ont pas de sens dans le cas d'un compteur auto incrémenté...

ensuite, tu devrais avoir une erreur et un refus d'insérer de nouvelles données si tu remplis ton compteur.

enfin, est-ce bien pertinent d'utiliser un compteur auto incrémenté dans ton modèle? N'y a t'il pas une clef primaire plus adaptée (p-ex timestamp)?

plutôt que vmware, Qemu... gratuit ET libre...

http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

normalement, les champs auto incrémentés vont jusqu'à la limite de la capacité de représentation du champ...

Sur cette page (http://popcon.debian.org/) , tu peux voir la popularité l'architecture ARM chez Debian. (Le graphique bleu qui monte et passe rapidement en troisième position)
Cette communauté NSLU2 y est pour beaucoup.

ouch... quel vilain graphique... ça fait peur tellement ça présente mal...

Sinon, c'est vrai que le NSLU2 est une très bonne option pour tout ce qui est serveur à faible puissance (par contre gare à la pelote de câbles derrière)