Disons rien à envier côté force de développement... et donc aboutissement du projet.
Je n'ai dû voir OS/2 tourner qu'une seule fois, et s'il avait bonne réputation sur sa fin (entre autre une très bonne stabilité vs le Win95 de l'époque), ce n'était pas le cas des premières versions livrées.
Ils devaient quand même se taper toute une couche de compatibilité pour les applis DOS puis les applis Windows 3.x... pas sûr que ça ait été génial pour améliorer le côté technique.
Où on voit encore que se battre dans la cour de Microsoft, c'est dur, très dur. Et plus encore pour du source fermé réalisé initialement en collaboration avec Microsoft (ce qui semble une des raisons du non-open-sourcing d'OS/2 d'après la page de Wikipedia).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
comment cela se passait pour résoudre les problèmes qu'on peut voir lorsqu'on fait du multithread ?
Il n'y avait rien de plus que des choses connues: mutex, sémaphores ; et en plus haut niveau: mémoire partagée, files de messages, ports de communication.
Tout ça se retrouve maintenant dans les APIs de n'importe quel OS digne de ce nom. Mais... BeOS c'était à l'époque [*] où MacOS ne connaissait pas la mémoire protégée ni le multithreading préemptif, Windows était une surcouche de DOS, Linux était un Unix en développement avec une couche XFree pas toujours légère sur de petites config.
BeOS c'était une façon intelligente et légère d'utiliser ces différents mécanismes (entre/dans les applications, avec les différents serveurs).
[*] Sauf erreur, la machine qui était vendue par Be Inc., c'était à l'origine un Bi-PPC603e à 166MHz... moi je tournais sur un PowerMac 7300 à 180MHz avec 80Mo de RAM, et c'était plus réactif qu'un PIV à moult gigagertz et plus de 1Go de RAM de maintenant.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Son design a été prévu dès le début pour supporter le multithreading de façon très intensive, en prévoyant que (rapidement) on utiliserais des machines multiprocesseurs.
Ce qui en fait (en faisait) un système très réactif - tu n'étais *jamais* bloqué dans l'interface à cause d'une opération en cours (un clic pour dérouler un menu lançait un nouveau thread chargé d'afficher et contrôler ce menu, chaque application avait un thread correspondant dans le système graphique...). Même sur des machines moyennes, tu pouvais sans problème jouer plusieurs films/musiques en même temps, tu sentais que les ressources de la machine étaient exploitées au maximum (j'ai souvent du mal à sentir ça sous Windows ou Linux).
Côté file-system, le BeFS et l'utilisation importante des attributs associés aux fichiers - et ce dès le début, intégré à l'OS - était vraiment génial pour faire des recherches, ou pour simplement visualiser des fichiers et leurs caractéristiques associées sans avoir à ouvrir une appli tiers.
Côté graphique, il y avait aussi le système des répliquants (des composants graphiques pouvant avoir une indépendance par rapport à leur fenêtre d'origine).
Et bien sûr, l'API objet de BeOS, vraiment sympa.
Vraiment dommage que ça n'ait pas pû être open-sourcé lorsque Be Inc. a fermé.
qu'ai-je à gagner à utiliser Haïku plutôt que Linux ?
Malheureusement, actuellement, aucun AMA (enfin, si, avec un QEmu, tu peux l'installer et voir par toi-même ce qu'il en est).
On retombe dans le problème de l'avancée du projet, dans le problème de support de matériels très divers (déjà qu'avec Linux c'est pas toujours gagné), des applis disponibles (il y avait une bonne communauté autour de BeOS, et des applications commençaient à arriver).
C'est dommage, j'ai récemment balancé tout le matériel de cette époque (CDs, livres) que j'avais sur BeOS...
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
From Daniel Drake
Subject [PATCH resend] via82cxxx: Add VIA VT8237A southbridge ID
Date Fri, 11 Aug 2006 20:33:46 +0100 (BST)
11 août... c'est assez frais, pas sûr qu'odin connaisse.
Et une réponse d'A.Cox:
Subject Re: [PATCH resend] via82cxxx: Add VIA VT8237A southbridge ID
From Alan Cox <>
Date Fri, 11 Aug 2006 21:10:49 +0100
...
Already in -mm.
Je sens que je vais être bon pour charger une version de développement du kernel et me retaper la phase de compil... j'espère que je ne serais pas trop loin des configs noyau de Mandriva.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
tu ne semble pas debutant ou tu es tres debrouillard ;-)
Ben, ça fait quelques années que je linuxise.
en effet, ou ce situe le fichier initrd que le noyau doit charger ?
sur le disque dur que tu cherches justement à activer.
C'est bien là mon problème... j'ai regardé rapidement, il semble que le VT8237A soit assez récent, une évolution du VT8237... et je ne suis pas sûr qu'il soit spécifié dans les sources (j'ai vu passer un patch au noyau qui semblait ajouter la version 'A' à un driver). Il me faudrais donc patcher, et recompiler...
Faut juste que je retrouve l'info sur le patch, de quelle versiondu noyau ils partaient... et de quelle version je dispose sur la Mdv 2007 odin... éventuellement que je récupère un noyau plus récent et que je le recompile (s'il inclus un meilleur support de mon chipset).
Je voulais essayer d'éviter d'avoir à patcher/installer et recompiler (bref, je voulais tester ma toute nouvelle carte mère & Co... sous Linux). Mais ça risque d'être plus long que prévu...
il te faut donc partir de cette idée et calculer ton propre noyau en ayant ajouté le support pour ton disque dur.
Il me semble que l'image fabriquée par initrd sert à ça: intégrer les pilotes nécessaires au boot dans une image chargée au démarrage par le bootloader, qui permet ensuite d'accéder complètement au disque - sans avoir à compiler en statique le support dans le noyau (j'ai déjà fait ça pour un serveur sous debian, pour supporter une carte SCSI mega-raid). Mais si le pilote ne connais pas qu'il peut gérer le chipset à cause du 'A'... va falloir se résoudre au minimum à patcher.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Même avec son écriture différée et autres artifices (qui au passage m'a emmerdé je ne sais combien de fois lors d'une écriture sur clé USB)
Même problème sous Windows, qui a aussi des systèmes de cache: il faut s'assurer que le cache est bien vidé avant de déconnecter la clée.
Sous Windows il y a "retirer le périphérique en toute tranquilité/sécurité"
Sous KDE, il y a qq chose d'équivalent (et ça doit sûrement se trouver sous Gnome) qui permet de démonter un volume amovible avant de le déconnecter.
Parce que - expérience personnelle - ça m'est arrivé de faire sous Windows une copie de nombreux fichiers d'un HD vers une clé USB, d'attendre que la fenêtre de copie soit refermée, puis de retirer la clé immédiatement. Hé ben j'ai foiré -et bien foiré- la table d'allocation FAT de la clé.
Depuis je passe systématiquement par les outils de démontage "en toute sécurité".
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
J'ai installé une sarge avec un kernel 2.6 sur une machine Nec qui avait un contrôleur dans ce genre. Le seul gros problème que j'ai eu a été le changement des noms des modules entre la version de la 2.6 installée et une mise à jour plus résence...
Au final, j'ai trouvé la solution en modifiant /etc/mkinitrd/modules, et en y mettant:
megaraid_mm
megaraid_mbox
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Mandriva est une société qui doit vivre, et pour cela avoir une activité commerciale - ça n'a rien à voir avec le fait d'être un fervent supporter du libre ou non, ça a à voir avec des bêtes problèmes de finances, de salaires, de compte d'exploitation....
Ils fournissent une version 'pure' sans logiciel propriétaire, et leurs développeurs passent une partie de leur temps à contribuer à certains logiciels libres.
Et pour les personnes qui paient, ils fournissent en plus des logiciels propriétaires closed-source, et permettent même d'en acheter certains (qui sont payants).
Si l'utilisation légale des outils d'écoute passe par des modules DRMs propriétaires, Mandriva essaira de les fournir à ses clients qui en ont besoin.
Typiquement, quelle est la proportions de .mpeg qui ne passent pas sous Linux si tu n'a pas installé les wrappers pour les codecs issus du monde Win32 ?
Après, le problème du support ou non des DRMs se pose à Mandriva comme aux autres distributions commerciales qui voudront aller sur le poste bureautique/personnel.
Mais aucune de ces sociétés n'a le moyen de régler ce problème à son niveau - c'est un problème politique - sauf à se tirer une balle dans le pied... en ne fournissant pas ce dont leurs clients ont besoin.
Ben oui, ils ne vivent malheureusement pas dans un monde idéal rempli de saine concurrence et de gens honnêtes, et ils ne vivent pas que d'air et d'eau fraiche (et encore, l'eau ça coûte).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Je ne suis pas un expert de la ligne de commande, mais il me semble que find a des options pour les parcours d'arborescence, et permet de lancer des commandes tierces...
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[zap texte sur les bienfaits de la standardisation /]
La standardisation/normalisation a des effets bénéfiques: les développements sont facilités, moins coûteux.
Mais elle a un revers dangeureux: la fragilité.
On en voit les effets avec les virus qui exploitent les failles dans les logiciels. Si tout le monde tournait avec les mêmes logiciels sur le même OS sur la même plateforme hardware, ça serait catastrophique.
Donc introduire de la diversité à ces différents niveaux est, non pas simplement une bonne chose, mais une nécessité.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Ils pourraient au moins permettre de lister les bugs déjà répertoriés afin de ne pas faire de doublons, et éventuellement d'enrichir les rapports existants avec des infos complémentaires.
Du code open-source avec des closedhidden bug, ça fait bizarre.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
La pluspart des applications [*] ne savent qu'accéder qu'aux fichier locaux. Et il ne faut pas oublier que Thunderbird est une application multi-plateforme.
[*] Sauf celles qui utilisent certaines fonctionnalités de KDE (et y'a peut-etre qq chose d'équivalent sous Gnome).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Perso je suis au club, donc je ne me pose pas de question, mais est-ce que les drivers propriétaires sont bien dispo à partir de la version download ???
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Sur un petit serveur à la maison (C3/800MHz, 512Mo de RAM, 200Go de disque, connexion ADSL), sous Debian.
J'ai un fetchmail qui récupère tous les 1/4 d'heure les emails sur les différents comptes que j'ai (Free, Wanadoo, LaPoste, GMail...), et qui les rapatries sur le serveur.
En local, je travaille avec Postfix, et stockage au format Maildir.
Pour le filtrage j'utilise maildrop, avec toute une série de règles pour les gens connus, les listes de diffusion,... et tout à la fin un passage par SpamAssassin et un routage vers une boite Spam si nécessaire.
Enfin, j'ai dovecot qui me fourni un accès IMAP à mes emails.
+ un backup (presque régulier) via snapy.
L'avantage que j'y ai trouvé c'est que tous mes emails se retrouvent en un seul endroit, les règles de tri et de filtrage anti-spam s'appliquent quelle que soit l'outil que j'utilise pour y accéder, le stockage Maildir me semble moins fragile, et c'est backupé de temps en temps.
Et en plus, comme j'ai un domaine, je peux créer et détruire facilement des alias au besoin (mais j'ai plutôt tendance à utiliser mon adresse email publique, qui est de toute façon largement diffusée et spammée, et de me reposer sur l'anti-spam).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Ben on va prendre au hasard Windows hein, combien de fois on a casse l'API des drivers depuis Windows 2000 pour raison de securite ? Pourtant les failles ont ete corrigees, comme quoi c'est faisable.
Mauvais exemple... une grande partie des failles Windows proviens de son architecture, et pour la changer... il faudrais modifier l'API... donc casser la compatibilité.
Non, mais on fait des interfaces decentes en y passant un peu de temps, l'exemple de Windows prouve que c'est possible vu qu'on y arrive.
Non, on embauche beaucoup de développeurs pour essayer d'un côté de faire évoluer le bouzin, et de l'autre d'écrire des couches de compatibilité qui masquent les évolutions. Ca demande énormément de moyens, Microsoft les a... et pourtant c'est encore lourd et ça fait des projets ingérables donc du retard.
Je suis d'accord que des APIs plus stables seraient plus agréables pour les développeurs (moins à revenir sur le code) et dans cette optique pour les utilisateurs (des drivers proprios qui continuent à tourner). Par contre, je comprend les arguments des développeurs du noyau qui cherchent à l'améliorer et qui de temps à autre ont besoin de modifier certaines façons de faire.
Par exemple, passer d'un gros lock vers des locks plus atomiques, ça change la façon dont le noyau travaille, et je ne suis pas sûr que ça se fasse facilement sans ajuster aussi les drivers.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Python est à la mode en effet. Maintenant, faut-il suivre la mode ou rester sur des langages qui répondent aux besoins et ont fait leurs preuves ?
Heu, Python a fait ses preuves depuis déjà quelques années.
Après, le choix d'un langage, c'est quand même très personnel et une question... d'habitudes et de goûts (bon, pour un soft dans une boite c'est généralement imposé, et de temps en temps on tombe sur des problèmatique pour lesquelles il y a des langages dédiés).
M'enfin, troller sur Truc c'est mieux que Machin... l'important c'est que ce script LCL soit disponible, et mieux en libre pour pouvoir le corriger, l'améliorer et le rediffuser.
Si certains préfèreraient avoir le script dans un autre langage, "y'a qu'a" regarder comment il marche et l'adapter.
Sinon (continuation de troll):
J'avoue que l'indentation obligatoire de python me sort par les trous de nez : si cela éclairci le code, l'impossibilité de définir un code autrement rend la réutilisation de code pénible.
Et moi c'est un des critères qui me fait apprécier Python (c'est donc bien en partie une question de goûts), à l'utilisation je ne trouve pas ça du tout pénible (comme tu dis, ça éclairci le code, ça le rend lisible... et ça c'est très très appréciable).
Et vu comment mon voisin de bureau s'est arraché les cheveux à cause de la façon dont python gère certains signaux...
Ca, pour moi c'est pas un critère. Dans tous les développements tu trouveras un moment où tu galèreras sur un point, à cause du langage ou à cause d'une librairie. Vaut mieux regarder les possibilités d'expression du langage, de structuration, de ré-utilisation du code, les librairies disponibles pour ne pas avoir à tout recoder, etc...
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
Je ne sais pas où est la couche native dans les librairies graphiques de mono, mais pour Python, c'est généralement du C ou C++ et juste une couche de binding vers Python.
Ce qui fait qu'il n'y a plus que la logique de haut niveau qui passe par la machine virtuelle (bon, c'est sûr qu'un lourd calcul dans cette couche... et ça s'écroule - mais bonne nouvelle, il y a aussi des bindings vers des librairies de calcul en natif genre traitement d'image & Co).
De plus, pour Java (et je pense C# - faut voir ce qui en est pour Mono), il y a la possibilité de compilation à la volée (ie. le byte code est compilé en natif lors du premier appel, après c'est direct). Ca améliore nettement les perfs.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: question
Posté par lolop (site web personnel) . En réponse à la dépêche Haïku fête ses 5 ans. Évalué à 3.
Je n'ai dû voir OS/2 tourner qu'une seule fois, et s'il avait bonne réputation sur sa fin (entre autre une très bonne stabilité vs le Win95 de l'époque), ce n'était pas le cas des premières versions livrées.
http://fr.wikipedia.org/wiki/OS/2
Ils devaient quand même se taper toute une couche de compatibilité pour les applis DOS puis les applis Windows 3.x... pas sûr que ça ait été génial pour améliorer le côté technique.
Où on voit encore que se battre dans la cour de Microsoft, c'est dur, très dur. Et plus encore pour du source fermé réalisé initialement en collaboration avec Microsoft (ce qui semble une des raisons du non-open-sourcing d'OS/2 d'après la page de Wikipedia).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Sur la BeBox
Posté par lolop (site web personnel) . En réponse à la dépêche Haïku fête ses 5 ans. Évalué à 2.
Et en plus, elle avait un vrai look: http://www.bebox.nu/images.php?s=images/ppcbebox
Ah, c'était 133MHz, pas 166. Et c'était en 1995... il y a 11 ans.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: question
Posté par lolop (site web personnel) . En réponse à la dépêche Haïku fête ses 5 ans. Évalué à 9.
Il n'y avait rien de plus que des choses connues: mutex, sémaphores ; et en plus haut niveau: mémoire partagée, files de messages, ports de communication.
Tout ça se retrouve maintenant dans les APIs de n'importe quel OS digne de ce nom. Mais... BeOS c'était à l'époque [*] où MacOS ne connaissait pas la mémoire protégée ni le multithreading préemptif, Windows était une surcouche de DOS, Linux était un Unix en développement avec une couche XFree pas toujours légère sur de petites config.
BeOS c'était une façon intelligente et légère d'utiliser ces différents mécanismes (entre/dans les applications, avec les différents serveurs).
Voir le BeBook... http://www.beunited.org/bebook/index.html
Et plus spécifiquement:
http://www.beunited.org/bebook/The%20Kernel%20Kit/index.html
[*] Sauf erreur, la machine qui était vendue par Be Inc., c'était à l'origine un Bi-PPC603e à 166MHz... moi je tournais sur un PowerMac 7300 à 180MHz avec 80Mo de RAM, et c'était plus réactif qu'un PIV à moult gigagertz et plus de 1Go de RAM de maintenant.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: question
Posté par lolop (site web personnel) . En réponse à la dépêche Haïku fête ses 5 ans. Évalué à 10.
Son design a été prévu dès le début pour supporter le multithreading de façon très intensive, en prévoyant que (rapidement) on utiliserais des machines multiprocesseurs.
Ce qui en fait (en faisait) un système très réactif - tu n'étais *jamais* bloqué dans l'interface à cause d'une opération en cours (un clic pour dérouler un menu lançait un nouveau thread chargé d'afficher et contrôler ce menu, chaque application avait un thread correspondant dans le système graphique...). Même sur des machines moyennes, tu pouvais sans problème jouer plusieurs films/musiques en même temps, tu sentais que les ressources de la machine étaient exploitées au maximum (j'ai souvent du mal à sentir ça sous Windows ou Linux).
Côté file-system, le BeFS et l'utilisation importante des attributs associés aux fichiers - et ce dès le début, intégré à l'OS - était vraiment génial pour faire des recherches, ou pour simplement visualiser des fichiers et leurs caractéristiques associées sans avoir à ouvrir une appli tiers.
Côté graphique, il y avait aussi le système des répliquants (des composants graphiques pouvant avoir une indépendance par rapport à leur fenêtre d'origine).
Et bien sûr, l'API objet de BeOS, vraiment sympa.
Vraiment dommage que ça n'ait pas pû être open-sourcé lorsque Be Inc. a fermé.
Malheureusement, actuellement, aucun AMA (enfin, si, avec un QEmu, tu peux l'installer et voir par toi-même ce qu'il en est).
On retombe dans le problème de l'avancée du projet, dans le problème de support de matériels très divers (déjà qu'avec Linux c'est pas toujours gagné), des applis disponibles (il y avait une bonne communauté autour de BeOS, et des applications commençaient à arriver).
C'est dommage, j'ai récemment balancé tout le matériel de cette époque (CDs, livres) que j'avais sur BeOS...
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Ca en cause aussi ici...
Posté par lolop (site web personnel) . En réponse au message Probleme de boot PT880/VT8237A. Évalué à 2.
http://forums.viaarena.com/messageview.aspx?catid=28&thr(...)
[et pour ceux qui auraient des problèmes de vitesse, DMA, et tout ça, un des liens donné dans les discussions est http://www.viaarena.com/default.aspx?PageID=22&DSCat=39&(...) ]
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: ben c'est pas mal...
Posté par lolop (site web personnel) . En réponse au message Probleme de boot PT880/VT8237A. Évalué à 2.
http://lkml.org/lkml/2006/8/11/196
11 août... c'est assez frais, pas sûr qu'odin connaisse.
Et une réponse d'A.Cox:
Je sens que je vais être bon pour charger une version de développement du kernel et me retaper la phase de compil... j'espère que je ne serais pas trop loin des configs noyau de Mandriva.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: ben c'est pas mal...
Posté par lolop (site web personnel) . En réponse au message Probleme de boot PT880/VT8237A. Évalué à 2.
Ben, ça fait quelques années que je linuxise.
C'est bien là mon problème... j'ai regardé rapidement, il semble que le VT8237A soit assez récent, une évolution du VT8237... et je ne suis pas sûr qu'il soit spécifié dans les sources (j'ai vu passer un patch au noyau qui semblait ajouter la version 'A' à un driver). Il me faudrais donc patcher, et recompiler...
Faut juste que je retrouve l'info sur le patch, de quelle versiondu noyau ils partaient... et de quelle version je dispose sur la Mdv 2007 odin... éventuellement que je récupère un noyau plus récent et que je le recompile (s'il inclus un meilleur support de mon chipset).
Je voulais essayer d'éviter d'avoir à patcher/installer et recompiler (bref, je voulais tester ma toute nouvelle carte mère & Co... sous Linux). Mais ça risque d'être plus long que prévu...
Il me semble que l'image fabriquée par initrd sert à ça: intégrer les pilotes nécessaires au boot dans une image chargée au démarrage par le bootloader, qui permet ensuite d'accéder complètement au disque - sans avoir à compiler en statique le support dans le noyau (j'ai déjà fait ça pour un serveur sous debian, pour supporter une carte SCSI mega-raid). Mais si le pilote ne connais pas qu'il peut gérer le chipset à cause du 'A'... va falloir se résoudre au minimum à patcher.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Ah ouais quand même...
Posté par lolop (site web personnel) . En réponse au journal DLFP is dying. Évalué à 9.
Ca, on s'en fout, ça pourrait être du ouebe 1.0, tant que la navigation est correcte, c'est le contenu qui prime.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: ^-^
Posté par lolop (site web personnel) . En réponse à la dépêche ShaKe, un défragmenteur pour GNU/Linux. Évalué à 5.
Même problème sous Windows, qui a aussi des systèmes de cache: il faut s'assurer que le cache est bien vidé avant de déconnecter la clée.
Sous Windows il y a "retirer le périphérique en toute tranquilité/sécurité"
Sous KDE, il y a qq chose d'équivalent (et ça doit sûrement se trouver sous Gnome) qui permet de démonter un volume amovible avant de le déconnecter.
Parce que - expérience personnelle - ça m'est arrivé de faire sous Windows une copie de nombreux fichiers d'un HD vers une clé USB, d'attendre que la fenêtre de copie soit refermée, puis de retirer la clé immédiatement. Hé ben j'ai foiré -et bien foiré- la table d'allocation FAT de la clé.
Depuis je passe systématiquement par les outils de démontage "en toute sécurité".
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Comment vont réagir les consomateurs ?
Posté par lolop (site web personnel) . En réponse au journal PCI Express et informatique "de confiance". Évalué à 10.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Abandon du 2.4 ?
Posté par lolop (site web personnel) . En réponse à la dépêche L'installeur de Debian Etch est disponible en version beta 3. Évalué à 1.
J'ai installé une sarge avec un kernel 2.6 sur une machine Nec qui avait un contrôleur dans ce genre. Le seul gros problème que j'ai eu a été le changement des noms des modules entre la version de la 2.6 installée et une mise à jour plus résence...
Au final, j'ai trouvé la solution en modifiant /etc/mkinitrd/modules, et en y mettant:
megaraid_mm
megaraid_mbox
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# snapy
Posté par lolop (site web personnel) . En réponse au message Backup du serveur web. Évalué à 1.
http://www.flibuste.net/libre/snapy/
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Réaliste
Posté par lolop (site web personnel) . En réponse au journal Le Bon, la Brute et le Truand.. Évalué à 4.
Ils fournissent une version 'pure' sans logiciel propriétaire, et leurs développeurs passent une partie de leur temps à contribuer à certains logiciels libres.
Et pour les personnes qui paient, ils fournissent en plus des logiciels propriétaires closed-source, et permettent même d'en acheter certains (qui sont payants).
Si l'utilisation légale des outils d'écoute passe par des modules DRMs propriétaires, Mandriva essaira de les fournir à ses clients qui en ont besoin.
Typiquement, quelle est la proportions de .mpeg qui ne passent pas sous Linux si tu n'a pas installé les wrappers pour les codecs issus du monde Win32 ?
Après, le problème du support ou non des DRMs se pose à Mandriva comme aux autres distributions commerciales qui voudront aller sur le poste bureautique/personnel.
Mais aucune de ces sociétés n'a le moyen de régler ce problème à son niveau - c'est un problème politique - sauf à se tirer une balle dans le pied... en ne fournissant pas ce dont leurs clients ont besoin.
Ben oui, ils ne vivent malheureusement pas dans un monde idéal rempli de saine concurrence et de gens honnêtes, et ils ne vivent pas que d'air et d'eau fraiche (et encore, l'eau ça coûte).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Avec find ?
Posté par lolop (site web personnel) . En réponse au message chercher un mot dans un fichier. Évalué à 1.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: C'est triste.
Posté par lolop (site web personnel) . En réponse au journal Au revoir PowerPC. Évalué à 2.
La standardisation/normalisation a des effets bénéfiques: les développements sont facilités, moins coûteux.
Mais elle a un revers dangeureux: la fragilité.
On en voit les effets avec les virus qui exploitent les failles dans les logiciels. Si tout le monde tournait avec les mêmes logiciels sur le même OS sur la même plateforme hardware, ça serait catastrophique.
Donc introduire de la diversité à ces différents niveaux est, non pas simplement une bonne chose, mais une nécessité.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Apple et son "bugreporter" fermé...
Posté par lolop (site web personnel) . En réponse au journal Apple réouvre en grand le code !. Évalué à 4.
Ils pourraient au moins permettre de lister les bugs déjà répertoriés afin de ne pas faire de doublons, et éventuellement d'enrichir les rapports existants avec des infos complémentaires.
Du code open-source avec des closedhidden bug, ça fait bizarre.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Et la démocratie ?
Posté par lolop (site web personnel) . En réponse à la dépêche Le Ministre de la Culture aux internautes. Évalué à 1.
[bon, elle était très facile]
Ceci dit, le garde des sceaux ne rend pas la justice.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Une feature request peut-être...
Posté par lolop (site web personnel) . En réponse au message confirmation de BUG pour Thunderbird. Évalué à 2.
La pluspart des applications [*] ne savent qu'accéder qu'aux fichier locaux. Et il ne faut pas oublier que Thunderbird est une application multi-plateforme.
[*] Sauf celles qui utilisent certaines fonctionnalités de KDE (et y'a peut-etre qq chose d'équivalent sous Gnome).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: salut :)
Posté par lolop (site web personnel) . En réponse au message Débutant cherche à installer son driver graphique. Évalué à 1.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# fetchmail + maildrop + maildir + IMAP
Posté par lolop (site web personnel) . En réponse au journal Comment gérez vous, vos abonnements aux listes de diffusions ?. Évalué à 3.
J'ai un fetchmail qui récupère tous les 1/4 d'heure les emails sur les différents comptes que j'ai (Free, Wanadoo, LaPoste, GMail...), et qui les rapatries sur le serveur.
En local, je travaille avec Postfix, et stockage au format Maildir.
Pour le filtrage j'utilise maildrop, avec toute une série de règles pour les gens connus, les listes de diffusion,... et tout à la fin un passage par SpamAssassin et un routage vers une boite Spam si nécessaire.
Enfin, j'ai dovecot qui me fourni un accès IMAP à mes emails.
+ un backup (presque régulier) via snapy.
L'avantage que j'y ai trouvé c'est que tous mes emails se retrouvent en un seul endroit, les règles de tri et de filtrage anti-spam s'appliquent quelle que soit l'outil que j'utilise pour y accéder, le stockage Maildir me semble moins fragile, et c'est backupé de temps en temps.
Et en plus, comme j'ai un domaine, je peux créer et détruire facilement des alias au besoin (mais j'ai plutôt tendance à utiliser mon adresse email publique, qui est de toute façon largement diffusée et spammée, et de me reposer sur l'anti-spam).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Euh...
Posté par lolop (site web personnel) . En réponse au journal Les drivers : c'est bien là le réel problème. Évalué à 3.
Mauvais exemple... une grande partie des failles Windows proviens de son architecture, et pour la changer... il faudrais modifier l'API... donc casser la compatibilité.
Non, on embauche beaucoup de développeurs pour essayer d'un côté de faire évoluer le bouzin, et de l'autre d'écrire des couches de compatibilité qui masquent les évolutions. Ca demande énormément de moyens, Microsoft les a... et pourtant c'est encore lourd et ça fait des projets ingérables donc du retard.
Je suis d'accord que des APIs plus stables seraient plus agréables pour les développeurs (moins à revenir sur le code) et dans cette optique pour les utilisateurs (des drivers proprios qui continuent à tourner). Par contre, je comprend les arguments des développeurs du noyau qui cherchent à l'améliorer et qui de temps à autre ont besoin de modifier certaines façons de faire.
Par exemple, passer d'un gros lock vers des locks plus atomiques, ça change la façon dont le noyau travaille, et je ne suis pas sûr que ça se fasse facilement sans ajuster aussi les drivers.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Encore un essai...
Posté par lolop (site web personnel) . En réponse au message Bug impression OOo sous Linux et pas sous WinXP :(. Évalué à 1.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Alternative au perl
Posté par lolop (site web personnel) . En réponse au journal Script LCL. Évalué à 2.
Heu, Python a fait ses preuves depuis déjà quelques années.
Après, le choix d'un langage, c'est quand même très personnel et une question... d'habitudes et de goûts (bon, pour un soft dans une boite c'est généralement imposé, et de temps en temps on tombe sur des problèmatique pour lesquelles il y a des langages dédiés).
M'enfin, troller sur Truc c'est mieux que Machin... l'important c'est que ce script LCL soit disponible, et mieux en libre pour pouvoir le corriger, l'améliorer et le rediffuser.
Si certains préfèreraient avoir le script dans un autre langage, "y'a qu'a" regarder comment il marche et l'adapter.
Sinon (continuation de troll):
Et moi c'est un des critères qui me fait apprécier Python (c'est donc bien en partie une question de goûts), à l'utilisation je ne trouve pas ça du tout pénible (comme tu dis, ça éclairci le code, ça le rend lisible... et ça c'est très très appréciable).
Ca, pour moi c'est pas un critère. Dans tous les développements tu trouveras un moment où tu galèreras sur un point, à cause du langage ou à cause d'une librairie. Vaut mieux regarder les possibilités d'expression du langage, de structuration, de ré-utilisation du code, les librairies disponibles pour ne pas avoir à tout recoder, etc...
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Encore un essai...
Posté par lolop (site web personnel) . En réponse au message Bug impression OOo sous Linux et pas sous WinXP :(. Évalué à 1.
Histoire de préciser si le problème viens d'OpenOffice et du fichier d'impression généré ou bien du rendu par ghostscript lors de l'impression.
[ je pensais le faire ce matin... mais mon vieux PC à la maison a (encore) un problème matériel ]
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Le passage Mono dans le document
Posté par lolop (site web personnel) . En réponse au journal Mono et Gnome. Évalué à 2.
Ce qui fait qu'il n'y a plus que la logique de haut niveau qui passe par la machine virtuelle (bon, c'est sûr qu'un lourd calcul dans cette couche... et ça s'écroule - mais bonne nouvelle, il y a aussi des bindings vers des librairies de calcul en natif genre traitement d'image & Co).
De plus, pour Java (et je pense C# - faut voir ce qui en est pour Mono), il y a la possibilité de compilation à la volée (ie. le byte code est compilé en natif lors du premier appel, après c'est direct). Ca améliore nettement les perfs.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN