1. Que les données ne sont pas corrompus
2. Que les indexes deviennent faux
3. Que la base refuse de re-démarrer tant qu'il n'y a pas suffisement de place pour reconstruire correctement les indexes (ce qui est logique)
Donc il n'y a pas de perte de données, il suffit de libérer suffisement de place pour repartir.
J'utilise PostgreSQL depuis 1998, j'ai eu chroniquement des problèmes d'espace disque, et je n'ai jamais eu besoin d'aller chercher les données dans mes sauvegardes.
Trouve-t'on quelque part des comparatifs de fonctionnalités de ces différentes bases ?
Difficile de comparer, le processeur fonctionne d'une manière un peu particulière.
Les benchs qui ont été fait lorsque les premiers Crusoe sont sortis ont trouvé les performances décevantes. Transmeta a expliqué cela par le fait que le code x86 doit être traduit en code natif (par le processeur) et donc que les benchs qui faisaient exécuter beaucoup de code peu de fois ne présentait pas une situation d'utilisation ordinaire à cause du coût initial important.
Je pense quand même qu'avec 1 GHz, on doit pouvoir visualiser un DivX, surtout vu la taille de l'écran. Ce n'est donc probablement pas adapté pour faire une ferme de calculs, par contre, je ne vois pas trop d'autres cas où la puissance pourrait être un facteur limitant.
Je ne pense pas que la modération est pitoyable, mais par contre, l'article est hélas bien trop succint:
"Le fameux plugin" m'est complètement inconnu, je ne suis probablement pas le seul, la moindre des choses serait de dire ce qu'il fait.
Il y a un lien sur XMMS, c'est une très bonne idée, mais il faudrait ajouter ce que c'est en quelques mots, par exemple "XMMS (jukebox audio)", je connais plusieurs personnes qui ne doivent pas trop savoir ce que c'est.
L'article ne contient quasiment aucune information, pour savoir ce que fait le plugin, ce qui a changé, que lui vaut sa réputation de "fameux", ce qui fait qu'il mérite une dépèche sur LinuxFR, il faut cliquer sur les liens ou aller lire les commentaires.
Je n'ai rien contre XMMS, ces remarques doivent être généralisés à n'importe quel article. Pour être intéressant, il faut partir du principe que tout le monde ne connait pas les programmes dont on parle et équilibrer les informations que l'on donne et les URLs; ne pas bourrer l'article d'informations qui n'intéressent pas 99% des lecteurs, mais à l'inverse, ne pas mettre une vague phrase et un lien vers le site pour savoir exactement ce qu'il se passe.
Il me semble que Microchip fabrique aussi des micro-controleurs avec la gestion de l'USB, ces processeurs sont généralement vendus à l'unité moins de 12 euros et sont programmables très facilement, sans extraction, sans tension particulière et via un protocole série.
Avec un tel microcontroleur, il doit être possibe pour un particulier de faire un montage, de le programmer avec un port série, et ensuite de l'installer sur un port USB sans avoir à acheter du matériel particulier.
Enfin il me semble qu'Elektor a acheté un vendorID exprès pour que les particuliers puissent jouer avec l'USB sans risquer ce genre de conflit.
Du point de vue de Linux, un thread est un processus ordinaire qui partage son espace mémoire avec d'autres processus du même type.
Linux crée donc un VRAI processus, ce qui est bien plus logique, ça évite beaucoup de ré-écriture, beaucoup de complexité, et ... beaucoup de bugs.
Fork quand à lui, n'est pas si lourd que cela, parce qu'en réalité, pratiquement rien n'est dupliqué, le noyau fonctionne en mode 'copie sur écriture', la mémoire n'est dupliqué que lorsqu'il y a effectivement une écriture (qui fait que les données changent entre le père et le fils), et cette copie ne se fait que sur la page mémoire concernée (4Ko sur i386).
La différence entre un processus et un thread n'est finalement pas vraiment au niveau des performances sous Linux, ça concerne plutôt la possibilité de partager de la mémoire. Avec des processus il faut passer par des mécanismes un peu lourd comme shm ou un socket, avec des threads c'est bien plus simple. En cas de bug, le modèle processus reste bien plus simple à gérer, on ne perturbe qu'un processus, avec les threads, on fait tomber tous les threads.
Enfin Apache doit généralement être root pour pouvoir se binder sur le port 80, avec des processus, tous les serveurs qui répondent aux requêtes ne sont pas root, les exploits n'exposent que l'identité sous laquelle tourne le serveur. Avec les threads, on ne peut pas utiliser ce genre de solution.
Pour le problème de JRE, je le fais fonctionner sous StarOffice avec un JDK 1.3.1. Pour cela, j'ai crée trois ou quatres liens symboliques entre différents répertoires pour que l'arborescence de mon JDK 1.3 ressemble à ce que cherche StarOffice.
Je crois que j'ai été obligé d'attacher strace au programme d'installation et de faire plusieurs tentatives pour voir quels sont les répertoires et les fichiers qu'il tentait d'ouvrir.
Le problème est que http://www.kitetoa.com/(...) est l'un des rares sites de salubrité publique, il pointe du doigt les sites qui n'ont aucun respect pour la vie privé des gens, il dénonce les experts sécurité qui ne connaissent qu'un mot (SSL).
Lorsqu'un français pompe le fichier des clients qui n'est pas protégé, on lui fait un procès plutot que de corriger le problème. Lorsque c'est un roumain (je n'ai rien contre les roumains), il n'y a rien à faire, il va pouvoir exploiter joyeusement les emails voir les n° de CB.
Lorsque je fais des commandes sur internet, je préfère que mon n° de CB ne se ballade pas partout ensuite, croyez vous que l'on puisse se contenter de faire confiance à celui qui à installé (et facturé) le site ? kitetoa montre justement que ce n'est pas le cas.
Moi j'aurai condamné Tati pour "divulgation d'informations personnelles, avec circonstances agravantes (ils ont été prévenus)". Aujourd'hui la loi protège les entreprises qui ne font pas ce qu'il faut pour protéger les informations de leurs clients, ce n'est pas normal.
J'ai essayé freenet il y a quelques mois, l'installation est simple et on peut même ensuite accéder à son 'proxy' avec un simple navigateur Web. De ce coté, il n'y a rien à redire.
Le problème viens du contenu :
Il n'y a aucune organisation, aucune arborescence, il n'est possible de chercher un document que sur son nom, autrement dit, il est extrèmement pénible de rechercher quelque chose si on ne connait pas le nom associé.
Lorsque j'ai fais mon test, il n'y avait pratiquement que des données illégales et/ou piratés: les photos et des films X, des DivX, des mp3 et du WareZ. Bref pas très sympa comme contenu.
Coté programme, c'est en bonne voie, par contre, du coté des utilisateurs, il reste encore tout le travail.
Il y a surtout de gros trous dans les versions précédentes, alors il est conseillé d'upgrader :
« Plusieurs trous de sécurité existent dans les versions antérieures à la 1.2.3 qui permettent à des mails HTML trafiqués:
* d'envoyer des messages semblant provenir de l'utilisateur
* Exécuter n'importe quel code JavaScript »
La mémoire adressable par un processus ne correspond pas à l'adresse réelle physique, donc lorsqu'une instruction essaye de lire ou d'écrire un octet, il faut d'abords convertir l'adresse logique en adresse physique.
Pour cela, le processeur utilile une TLB (Translation Lookaside Buffer, à 2 niveaux sur i386 il me semble) qui donne l'adresse physique.
Généralement les pages font 4 Ko, les 10 premiers bits de l'adresse donne l'offset dans la première table, on trouve l'adresse de la seconde table. Les 10 bits suivants sont aussi utilisés comme offset dans cette seconde table pour obtenir d'adresse de la page physique. Il reste 12 bits (adressage sur 32 bits) qui donnent l'offset sur la page de 4 Ko (4Ko = 2^12).
Les différents paramêtre des TBL changent selon le mode et le processeur utilisé, mais le principe reste là. Les TLB consomment de la mémoire et demande au processeur d'aller lire pas mal d'information en RAM avant de pouvoir faire l'accès mémoire qui nous intéresse.
En utilisant des pages de 4Mo on gagne une plus grande vitesse d'accès aux informations puisqu'on supprime la dernière étape du TLB (offset sur la page de 24 bits, donc une seule table de TLB à consulter), ça fait des informations en moins à aller lire en RAM avant de pouvoir faire l'accès, ça réduit l'occupation mémoire des TLB (mais quand on fait des pages de 4 Mo, en général on gache quand même pas mal d'espace) et ça polue moins le cache du processeur avec du contenu qui n'est pas intéressant du point de vue du programme. Par contre, il faut que le processus ai besoin du bloc de 4Mo ou d'un multiple.
Il y a eu une bonne discussion à ce propos dans la mailing-list (comme tout le monde peut s'en douter). Un résumé du problème et des différents messages échangés est paru dans le "Kernel Cousin Wine #111" du 24 décembre dernier (in english).
Généralement pour contourner ce problème, le produit est présenté comme un 'lot' et il n'est alors plus possible de séparer les différents éléments.
Il y a une différence entre Dell qui vends des ordinateurs et propose un OS dessus, et le supermarché qui vends un lot "Ordinateur multi-média avec son offre de logiciels".
C'est comme aller chez le marchand de voiture et demander a retirer la banquette arrière et le siège passager sous prétexte que c'est de la vente liée.
Je ne sais pas quel est la jurisprudence, mais la distinction entre les deux ne m'a pas l'air très précise.
Clairement, refuser de payer le siège passager de sa voiture est abusif, être forcé de payer microsoft aussi; il reste à trouver un moyen non-ambigüe de trancher entre les deux extrèmes.
> En gros : Y a que Windows pour jouer, Linux ne
> peut etre une plateforme de jeux, il faut
> d'abord faire un jeu Windows puis l'émuler
> sous Wine !
Je n'ai absolument pas dit cela, il y a le 'il faut', et la façon dont ça se passe effectivement. A mon avis au contraire, il vaut mieux faire comme ID, développer sous Linux et ensuite faire un portage Windows.
> Je préfere m'acheter un Soldier of Fortunes
> Linux plutot que d'cheter Windows et
> l'émuler sous Wine ! C'est totalement
> ridicule !
Moi aussi, je préfère que mes euros partent dans le salaire de gens qui travaillent sous Linux plutot que windows, le problème n'est pas là. Il est de savoir si ça tourne bien même lorsque le programme est un peu vieux.
> Faut réfléchir: Linux doit avoir des applis
> natives, commerciales ou non, ou il crevera !
Je te rassure tout de suite, il ne crèvera pas, j'ai tout ce dont j'ai besoin sous Linux et je ne suis pas le seul. Je n'utilise jamais Windows au boulot et chez moi, il ne sert que pour les jeux, environ une fois tous les deux mois.
Je n'ai jamais acheté de jeux sous Linux, rarement sous Windows (je préfère mouler), mais je me pose une question :
Est-ce que ce jeux fonctionnera dans 3 ans ?
J'ai acheté il y a trois ans Half-life version windows, il fonctionne toujours, j'ai également acheté VMWare pour linux, et aujourd'hui, je ne peux plus le faire tourner.
Certe VMWare est très lié au kernel, les changements majeur et parfois mineurs se font dans la douleur pour cela; mais d'une manière, les librairies évolues aussi très vite.
Est-ce que les programmes conçu pour tourner avec les 3Dfx 1 et 2, les programmes en a.out, ceux qui utilisent une vieille libc, une vieille librairie, ont des chances de tourner sur une distribution moderne, ou dans quelques années ? Mon expérience me dit que non. (Il faudrait que j'essaye quelques binaires de ma première slack, il doit y avoir Netscape 1.01N)
J'ai l'impression que les programmes ont plus de chance de tourner dans WINE qu'en linux natif.
En lisant l'article, on se rends compte que ce n'est pas tout à fait cela. Cette technologie est destinée à ré-utiliser un cablage d'entreprise fait pour la voix. Il est clairement dit que cela s'applique à des longueurs jusqu'à 5000 feets.
Si je ne me trompe pas, et si le convertisseur que j'ai trouvé non plus, ça donne 5000 Pieds = 1524 Mètres.
1500 mètres, j'ai bien peur que ce soit un peu court pour les connexions des particuliers.
Il y a une autre bonne nouvelle, les PDA sous Linux deviennent disponibles.
Après des années de concurrence à microsoft dans le domaine du vaporware, il est enfin possible de passer commande de certains appareils.
J'attends toujours avec impatience un ou deux test pour voir comment ça se synchronise et si les fonctionnalitées sont là; mais je pense que l'on va enfin avoir des PDA intéressants.
Il y a peu de chances que les balladeurs autonomes soient fournis avec un codec Ogg en standart ou librement diffusé, au contraire.
Les maisons d'éditions sont paniqués par le mp3 et font tout ce qu'elles peuvent pour imposer un système empèchant la copie des oeuvres.
Tous les balladeurs seront conçus pour permettre (avec passport) d'acheter de la musique en ligne, dans un format bien propriétaire pour empècher la copie, ceci aura deux conséquences :
* Aucun balladeur ne sera vendu sans ce codec parce qu'il semblera naturel à tout le monde, et de ce fait indispensable.
* La licence de ce codec interdit bien évidement l'implémentation sur la meme machine d'un codec permettant de contourner les droits des oeuvres.
Si monsieur Sony (qui joue des deux cotés puisqu'il publie aussi de la musique) ou monsieur Panasonic décide de fabriquer un nouveau balladeur, il NE PEUX PAS faire une croix sur le codec officiel, parce que de ce fait, son matériel deviendra incompatible avec quasiment tous les sites de musique.
De toute façon, tout le monde le sait bien, les grandes boites d'édition de "musique" ont décidé que la production d'oeuvre libre de droit n'existait pas.
La musique est devenu un monde encore bien plus répugnant que le logiciel.
Je confirme également que l'éducation nat. fait tourner ses serveurs sous Linux. C'est le cadre imposé pour les développements des serveurs internet en particulier.
Par contre, du coté des élèves, c'est encore très Windows. Dans les filières techniques, les profs reçoivent un budget matériel (mais ils ne doivent acheter que chez certains commerçants qui gonflent la facture) et aucune formation pour s'en sortir ensuite. Ils passent donc des week-ends à essayer d'installer du 2000 ou du XP sans avoir les compétences.
Dans les deux cas, il y a de gros problèmes de formation des installateurs/développeurs/administrateurs, et hélas, windows reste une solution qui fait moins peur aux débutants.
La solution proposé est un mécanisme qui permet de se rendre compte lorsque les logs ont été trafiqués.
Ça ne règle pas le problème de l'effacement des logs. Une fois que les lignes ont disparu, il est toujours impossible de savoir ce qu'il s'est produit.
On n'a pas encore fait mieux que l'universitaire (j'ai oublié son nom) traquant Pengo (le pirate allemand) avec une batterie d'imprimantes matricielles ;-)
Il n'y a quasiment jamais un seul processus actif.
Je n'ai peut-être pas utilisé le bon vocabulaire, par processus actif, j'entends un processus en mode 'Runnable', un processus qui n'est pas bloqué par un appel système et succeptible de consommer du CPU.
Sur mon poste de travail par exemple, je pense que dans 99,9% des cas, le scheduleur, faute de concurrent, réaffecte le même processus au processeur.
Pour ce qui est de la sauvegarde, il semblerait que le processeur peut gérer ces sauvegardes presque tout seul
Le 386 et les processeurs compatibles sont effectivement conçus pour cela, ils font tout le boulot si on accepte le cadre de fonctionnement proposé par intel. Je pense que c'est pour cela que Linus à dit que Linux n'était pas portable (du temps des Linux 0.x); il s'est beaucoup appuyé au début sur tous les mécanismes automatiques d'Intel.
Pour la TLB, au pire elle s'invalide toute seule.
Je ne comprends pas cette remarque. Elle est déclarée invalide lorsqu'on modifie le registre qui pointe sur la page des tables, ce n'est pas 'tout seul'.
[^] # Re: indexes corrompus ?
Posté par Sébastien Koechlin . En réponse à la dépêche Sortie du SGBD Firebird en version 1.0 finale. Évalué à 5.
Que dit la doc dans le cas de saturation :
1. Que les données ne sont pas corrompus
2. Que les indexes deviennent faux
3. Que la base refuse de re-démarrer tant qu'il n'y a pas suffisement de place pour reconstruire correctement les indexes (ce qui est logique)
Donc il n'y a pas de perte de données, il suffit de libérer suffisement de place pour repartir.
[^] # Re: indexes corrompus ?
Posté par Sébastien Koechlin . En réponse à la dépêche Sortie du SGBD Firebird en version 1.0 finale. Évalué à 8.
Trouve-t'on quelque part des comparatifs de fonctionnalités de ces différentes bases ?
[^] # Re: je voudrais savoir...
Posté par Sébastien Koechlin . En réponse à la dépêche Un ultra portable sous Linux. Évalué à 10.
Les benchs qui ont été fait lorsque les premiers Crusoe sont sortis ont trouvé les performances décevantes. Transmeta a expliqué cela par le fait que le code x86 doit être traduit en code natif (par le processeur) et donc que les benchs qui faisaient exécuter beaucoup de code peu de fois ne présentait pas une situation d'utilisation ordinaire à cause du coût initial important.
Je pense quand même qu'avec 1 GHz, on doit pouvoir visualiser un DivX, surtout vu la taille de l'écran. Ce n'est donc probablement pas adapté pour faire une ferme de calculs, par contre, je ne vois pas trop d'autres cas où la puissance pourrait être un facteur limitant.
[^] # Re: Modération pitoyable
Posté par Sébastien Koechlin . En réponse à la dépêche LE plugin ultime pour XMMS !. Évalué à 10.
Je n'ai rien contre XMMS, ces remarques doivent être généralisés à n'importe quel article. Pour être intéressant, il faut partir du principe que tout le monde ne connait pas les programmes dont on parle et équilibrer les informations que l'on donne et les URLs; ne pas bourrer l'article d'informations qui n'intéressent pas 99% des lecteurs, mais à l'inverse, ne pas mettre une vague phrase et un lien vers le site pour savoir exactement ce qu'il se passe.
[^] # Re: Afficheur USB
Posté par Sébastien Koechlin . En réponse à la dépêche Afficheur LCD sous Linux. Évalué à 7.
Avec un tel microcontroleur, il doit être possibe pour un particulier de faire un montage, de le programmer avec un port série, et ensuite de l'installer sur un port USB sans avoir à acheter du matériel particulier.
Enfin il me semble qu'Elektor a acheté un vendorID exprès pour que les particuliers puissent jouer avec l'USB sans risquer ce genre de conflit.
[^] # Re: Statistiques...
Posté par Sébastien Koechlin . En réponse à la dépêche Apache 2.0 disponible pour tous. Évalué à 10.
Linux crée donc un VRAI processus, ce qui est bien plus logique, ça évite beaucoup de ré-écriture, beaucoup de complexité, et ... beaucoup de bugs.
Fork quand à lui, n'est pas si lourd que cela, parce qu'en réalité, pratiquement rien n'est dupliqué, le noyau fonctionne en mode 'copie sur écriture', la mémoire n'est dupliqué que lorsqu'il y a effectivement une écriture (qui fait que les données changent entre le père et le fils), et cette copie ne se fait que sur la page mémoire concernée (4Ko sur i386).
La différence entre un processus et un thread n'est finalement pas vraiment au niveau des performances sous Linux, ça concerne plutôt la possibilité de partager de la mémoire. Avec des processus il faut passer par des mécanismes un peu lourd comme shm ou un socket, avec des threads c'est bien plus simple. En cas de bug, le modèle processus reste bien plus simple à gérer, on ne perturbe qu'un processus, avec les threads, on fait tomber tous les threads.
Enfin Apache doit généralement être root pour pouvoir se binder sur le port 80, avec des processus, tous les serveurs qui répondent aux requêtes ne sont pas root, les exploits n'exposent que l'identité sous laquelle tourne le serveur. Avec les threads, on ne peut pas utiliser ce genre de solution.
[^] # Re: Astuce
Posté par Sébastien Koechlin . En réponse à la dépêche OpenOffice.org641d. Évalué à 0.
Je crois que j'ai été obligé d'attacher strace au programme d'installation et de faire plusieurs tentatives pour voir quels sont les répertoires et les fichiers qu'il tentait d'ouvrir.
[^] # Re: GPG/PGP
Posté par Sébastien Koechlin . En réponse à la dépêche Le cryptonomicon. Évalué à 7.
L'auteur ne donne même pas la version de Finux ou la distribution utilisé par le héro. ;-)
[^] # Re: C'est logique...
Posté par Sébastien Koechlin . En réponse à la dépêche kitetoa condamné. Évalué à 10.
Lorsqu'un français pompe le fichier des clients qui n'est pas protégé, on lui fait un procès plutot que de corriger le problème. Lorsque c'est un roumain (je n'ai rien contre les roumains), il n'y a rien à faire, il va pouvoir exploiter joyeusement les emails voir les n° de CB.
Lorsque je fais des commandes sur internet, je préfère que mon n° de CB ne se ballade pas partout ensuite, croyez vous que l'on puisse se contenter de faire confiance à celui qui à installé (et facturé) le site ? kitetoa montre justement que ce n'est pas le cas.
Moi j'aurai condamné Tati pour "divulgation d'informations personnelles, avec circonstances agravantes (ils ont été prévenus)". Aujourd'hui la loi protège les entreprises qui ne font pas ce qu'il faut pour protéger les informations de leurs clients, ce n'est pas normal.
# Un beau projet.... inutilisé
Posté par Sébastien Koechlin . En réponse à la dépêche Freenet, une toile alternative. Évalué à 10.
Le problème viens du contenu :
- Il n'y a aucune organisation, aucune arborescence, il n'est possible de chercher un document que sur son nom, autrement dit, il est extrèmement pénible de rechercher quelque chose si on ne connait pas le nom associé.
- Lorsque j'ai fais mon test, il n'y avait pratiquement que des données illégales et/ou piratés: les photos et des films X, des DivX, des mp3 et du WareZ. Bref pas très sympa comme contenu.
Coté programme, c'est en bonne voie, par contre, du coté des utilisateurs, il reste encore tout le travail.# Alerte de sécurité sur les version précédentes.
Posté par Sébastien Koechlin . En réponse à la dépêche Nouvelle version de SquirrelMail. Évalué à 3.
« Plusieurs trous de sécurité existent dans les versions antérieures à la 1.2.3 qui permettent à des mails HTML trafiqués:
* d'envoyer des messages semblant provenir de l'utilisateur
* Exécuter n'importe quel code JavaScript »
Voir http://www.securityfocus.com/archive/1/252259(...)
[^] # Re: Des pages de 4Mb ?
Posté par Sébastien Koechlin . En réponse à la dépêche quand AMD retrouve Intel .... Évalué à 10.
Pour cela, le processeur utilile une TLB (Translation Lookaside Buffer, à 2 niveaux sur i386 il me semble) qui donne l'adresse physique.
Généralement les pages font 4 Ko, les 10 premiers bits de l'adresse donne l'offset dans la première table, on trouve l'adresse de la seconde table. Les 10 bits suivants sont aussi utilisés comme offset dans cette seconde table pour obtenir d'adresse de la page physique. Il reste 12 bits (adressage sur 32 bits) qui donnent l'offset sur la page de 4 Ko (4Ko = 2^12).
Les différents paramêtre des TBL changent selon le mode et le processeur utilisé, mais le principe reste là. Les TLB consomment de la mémoire et demande au processeur d'aller lire pas mal d'information en RAM avant de pouvoir faire l'accès mémoire qui nous intéresse.
En utilisant des pages de 4Mo on gagne une plus grande vitesse d'accès aux informations puisqu'on supprime la dernière étape du TLB (offset sur la page de 24 bits, donc une seule table de TLB à consulter), ça fait des informations en moins à aller lire en RAM avant de pouvoir faire l'accès, ça réduit l'occupation mémoire des TLB (mais quand on fait des pages de 4 Mo, en général on gache quand même pas mal d'espace) et ça polue moins le cache du processeur avec du contenu qui n'est pas intéressant du point de vue du programme. Par contre, il faut que le processus ai besoin du bloc de 4Mo ou d'un multiple.
# Très bon résumé de la situation
Posté par Sébastien Koechlin . En réponse à la dépêche Wine : changement de licence ?. Évalué à 10.
Voici en prime un lien direct vers le chapitre :
http://kt.zork.net/wine/wn20011224_111.html#1(...)
[^] # Re: Petite question
Posté par Sébastien Koechlin . En réponse à la dépêche Vente liée et Microsoft. Évalué à 10.
Il y a une différence entre Dell qui vends des ordinateurs et propose un OS dessus, et le supermarché qui vends un lot "Ordinateur multi-média avec son offre de logiciels".
C'est comme aller chez le marchand de voiture et demander a retirer la banquette arrière et le siège passager sous prétexte que c'est de la vente liée.
Je ne sais pas quel est la jurisprudence, mais la distinction entre les deux ne m'a pas l'air très précise.
Clairement, refuser de payer le siège passager de sa voiture est abusif, être forcé de payer microsoft aussi; il reste à trouver un moyen non-ambigüe de trancher entre les deux extrèmes.
[^] # Re: Pas d'accord du tout !
Posté par Sébastien Koechlin . En réponse à la dépêche Linux Game Publishing annonce Majesty + son extension Pack sous Linux !. Évalué à 9.
> peut etre une plateforme de jeux, il faut
> d'abord faire un jeu Windows puis l'émuler
> sous Wine !
Je n'ai absolument pas dit cela, il y a le 'il faut', et la façon dont ça se passe effectivement. A mon avis au contraire, il vaut mieux faire comme ID, développer sous Linux et ensuite faire un portage Windows.
> Je préfere m'acheter un Soldier of Fortunes
> Linux plutot que d'cheter Windows et
> l'émuler sous Wine ! C'est totalement
> ridicule !
Moi aussi, je préfère que mes euros partent dans le salaire de gens qui travaillent sous Linux plutot que windows, le problème n'est pas là. Il est de savoir si ça tourne bien même lorsque le programme est un peu vieux.
> Faut réfléchir: Linux doit avoir des applis
> natives, commerciales ou non, ou il crevera !
Je te rassure tout de suite, il ne crèvera pas, j'ai tout ce dont j'ai besoin sous Linux et je ne suis pas le seul. Je n'utilise jamais Windows au boulot et chez moi, il ne sert que pour les jeux, environ une fois tous les deux mois.
# Linux & les jeux
Posté par Sébastien Koechlin . En réponse à la dépêche Linux Game Publishing annonce Majesty + son extension Pack sous Linux !. Évalué à 9.
Est-ce que ce jeux fonctionnera dans 3 ans ?
J'ai acheté il y a trois ans Half-life version windows, il fonctionne toujours, j'ai également acheté VMWare pour linux, et aujourd'hui, je ne peux plus le faire tourner.
Certe VMWare est très lié au kernel, les changements majeur et parfois mineurs se font dans la douleur pour cela; mais d'une manière, les librairies évolues aussi très vite.
Est-ce que les programmes conçu pour tourner avec les 3Dfx 1 et 2, les programmes en a.out, ceux qui utilisent une vieille libc, une vieille librairie, ont des chances de tourner sur une distribution moderne, ou dans quelques années ? Mon expérience me dit que non. (Il faudrait que j'essaye quelques binaires de ma première slack, il doit y avoir Netscape 1.01N)
J'ai l'impression que les programmes ont plus de chance de tourner dans WINE qu'en linux natif.
# Longue distance ?
Posté par Sébastien Koechlin . En réponse à la dépêche Ethernet sur longue distance. Évalué à 10.
Si je ne me trompe pas, et si le convertisseur que j'ai trouvé non plus, ça donne 5000 Pieds = 1524 Mètres.
1500 mètres, j'ai bien peur que ce soit un peu court pour les connexions des particuliers.
[^] # Re: Excellent
Posté par Sébastien Koechlin . En réponse à la dépêche Synchroniser son PocketPC avec Linux. Évalué à 5.
Après des années de concurrence à microsoft dans le domaine du vaporware, il est enfin possible de passer commande de certains appareils.
J'attends toujours avec impatience un ou deux test pour voir comment ça se synchronise et si les fonctionnalitées sont là; mais je pense que l'on va enfin avoir des PDA intéressants.
[^] # Balladeurs OggVorbis
Posté par Sébastien Koechlin . En réponse à la dépêche La BBC test la diffusion des ses radios en OggVorbis. Évalué à 10.
Les maisons d'éditions sont paniqués par le mp3 et font tout ce qu'elles peuvent pour imposer un système empèchant la copie des oeuvres.
Tous les balladeurs seront conçus pour permettre (avec passport) d'acheter de la musique en ligne, dans un format bien propriétaire pour empècher la copie, ceci aura deux conséquences :
* Aucun balladeur ne sera vendu sans ce codec parce qu'il semblera naturel à tout le monde, et de ce fait indispensable.
* La licence de ce codec interdit bien évidement l'implémentation sur la meme machine d'un codec permettant de contourner les droits des oeuvres.
Si monsieur Sony (qui joue des deux cotés puisqu'il publie aussi de la musique) ou monsieur Panasonic décide de fabriquer un nouveau balladeur, il NE PEUX PAS faire une croix sur le codec officiel, parce que de ce fait, son matériel deviendra incompatible avec quasiment tous les sites de musique.
De toute façon, tout le monde le sait bien, les grandes boites d'édition de "musique" ont décidé que la production d'oeuvre libre de droit n'existait pas.
La musique est devenu un monde encore bien plus répugnant que le logiciel.
[^] # Re: Excellent
Posté par Sébastien Koechlin . En réponse à la dépêche Projet GL Quake 1. Évalué à 3.
http://digita.mame.net/P714.JPG(...)
http://digita.mame.net/closeup.htm(...)
http://www.digitalcameras.com/reviews/digitaOS/appsScripts.asp(...)
Mais je ne sais pas si c'est accéléré OpenGL ?-)
[^] # Re: "McAfee s'inquiète" ?
Posté par Sébastien Koechlin . En réponse à la dépêche Virus Policier. Évalué à 10.
'fgrep' détectera Magic Lantern
http://www.gnu.org/software/grep/grep.html(...)
;-)
[^] # Re: Linux et Ministère
Posté par Sébastien Koechlin . En réponse à la dépêche Les Gouvernements choisissent Linux. Évalué à 10.
Par contre, du coté des élèves, c'est encore très Windows. Dans les filières techniques, les profs reçoivent un budget matériel (mais ils ne doivent acheter que chez certains commerçants qui gonflent la facture) et aucune formation pour s'en sortir ensuite. Ils passent donc des week-ends à essayer d'installer du 2000 ou du XP sans avoir les compétences.
Dans les deux cas, il y a de gros problèmes de formation des installateurs/développeurs/administrateurs, et hélas, windows reste une solution qui fait moins peur aux débutants.
# L'article est très technique
Posté par Sébastien Koechlin . En réponse à la dépêche Vous fiez-vous à vos logs système ?. Évalué à 10.
Ça ne règle pas le problème de l'effacement des logs. Une fois que les lignes ont disparu, il est toujours impossible de savoir ce qu'il s'est produit.
On n'a pas encore fait mieux que l'universitaire (j'ai oublié son nom) traquant Pengo (le pirate allemand) avec une batterie d'imprimantes matricielles ;-)
[^] # Re: Et le problème du bruit ???
Posté par Sébastien Koechlin . En réponse à la dépêche Sortie du HS LinuxMag "Installer son serveur web à la maison". Évalué à 5.
Je n'ai rien testé, j'hésite à me lancer dans l'upgrade de mon serveur (qui est en AT et non pas en ATX).
http://www.ldlc.fr/dossiers/pc_silencieux/index.html(...)
[^] # Re: Un seul processus actif ?
Posté par Sébastien Koechlin . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 3.
Je n'ai peut-être pas utilisé le bon vocabulaire, par processus actif, j'entends un processus en mode 'Runnable', un processus qui n'est pas bloqué par un appel système et succeptible de consommer du CPU.
Sur mon poste de travail par exemple, je pense que dans 99,9% des cas, le scheduleur, faute de concurrent, réaffecte le même processus au processeur.
Pour ce qui est de la sauvegarde, il semblerait que le processeur peut gérer ces sauvegardes presque tout seul
Le 386 et les processeurs compatibles sont effectivement conçus pour cela, ils font tout le boulot si on accepte le cadre de fonctionnement proposé par intel. Je pense que c'est pour cela que Linus à dit que Linux n'était pas portable (du temps des Linux 0.x); il s'est beaucoup appuyé au début sur tous les mécanismes automatiques d'Intel.
Pour la TLB, au pire elle s'invalide toute seule.
Je ne comprends pas cette remarque. Elle est déclarée invalide lorsqu'on modifie le registre qui pointe sur la page des tables, ce n'est pas 'tout seul'.