reno a écrit 3881 commentaires

> le FS [reiserfs3] reste cohérent après s'être auto-réparé

Oui, enfin ça dépend quand même de ce qu'on appelle 'cohérent': j'ai eu mon /etc/passwd auquel s'est ajouté plein de binaire avec reiserfs3..

Bug du FS? Du disque dur? Difficile a savoir..

Ca plus une perte de partition toujours avec reiserfs3..

Bref, pas convaincu, ok c'est juste mon cas, mais j'aurais quand tendance à penser que le mode 'ordered' de ext3 protège mieux les données..

XFS étant célebre aussi pour ces pertes de données (parait que c'est corrigé, mais pas forcément mis a jour partout) et maintenu par SGI (une société sous le chapter 11), personnellement il me semble que ext3 ou JFS, c'est plus sage..

> ZFS sera de plus intégré dans le futur Mac OS.

C'est officiel maintenant ou toujours juste une rumeur?

Personellement, ce que j'ai eu comme probleme avec reiserfs3, c'est la fiabilité.
J'ai eu une fois une corruption de fs avec reiserfs3 et j'ai eu alors la désagréable surprise de découvrir que la récupération de donnée par fsck ne fonctionnait pas pour reiserfs3..
--> partition perdue.

Depuis je pense que ext3fs, c'est bienTM: son fsck fonctionne bien lui, en cas de gros problème..

Bin oui, mais pour BeOS toutes les applications ont du être codés pour fonctionner sur BeOS..

Je ne dits pas qu'il y a un probleme fondamental, jusqu'il faut modifier *toutes* les applications autrement tu te retrouves avec un système ou l'attribut type est rempli 10% du temps, ce qui augmente la complexité sans vrai gain..

Personellement si je pouvais avoir une feature de BeOS sur Linux, ce serait la réactivité: en utilisant une thread dédié a la gestion de la fenetres, les interfaces étaient bien plus réactives, ce qui était très agréable a utiliser.

Mais comme, la encore, cela nécéssite de modifier *toutes* les applications pour que ce soit un réel progrès, ce qui n'est pas près d'arriver..

>fini la détection de type parfois foireuse

Bôf, uniquement si
1) la base de données contient le type de donnée recherché
2) le remplissage de cette information est faite: donc si *tous* les programmes étaient modifiés pour rajouter cette information..

Et il faut faire attention au coté sécurité de la chose: que se passe t'il si un attaquant déclare un exécutable comme une image?

Ton poste est franchement tiré par les cheveux: Linux a deux sens:
-Linux le kernel en lui-même
-ou tout systeme d'exploitation basé sur un kernel Linux.

En général, il n'y a aucune confusion entre ces deux termes.

Donc dire "Linux, c'est extrêmement vaste, et ça ne veut absolument rien dire", c'est n'importe quoi.

Je ne me souviens plus du nom du dev Linux, mais pour le responsable de reiser4, c'est Hans Reiser, très réputé pour sa diplomatie ;-)

Il avait déja eu du mal a mettre le premier reiserfs dans le kernel bien ce soit le premier fs journalisé pour Linux, en grande partie a cause de sa grande gu.... .

Maintenant la concurrence est plus rude, mais Hans n'a pas changé donc reiser fs 4 dans Linux AMHA ce n'est pas pour demain.

Bon juste pour l'anecdote, reiserfs est un des seuls système de fichier a m'avoir perdu une partition (les outils de récupération n'ont pas fonctionné), et je reste un peu sceptique de l'interet de journaliser uniquement les métadonnées: quand on se retrouve avec le /etc/passwd qui contient du binaire, ça fait mal (aussi avec reiserfs) --> je pense qu'ext3 en journalisation donnée+métadonnée, c'est *bien*(TM).

Dans le même genre, j'ai un collègue qui a une clef USB qui siffle.
Cela a un avantage malgrès que le bruit soit désagréable: on ne risque pas d'oublier la clef USB branchée dans un PC!

Je préfère Ruby, mais à mon avis Ruby plait bien aux programmeurs "blanchis sous le manteau" qui ont connus les affres du shell, du Perl (beurk)..

Pour les débutants, j'aurais tendance quand même a penser que Python serait un peu plus simple.

Le coté important pour des enfants est à mon avis de fournir une librairie permettant un feedback visuel immédiat comme le BASIC le permettait: je me souviens encore de mon premier programme: dessiner une maison a coup de lignes et de rectangles.

Ok, merci (+1)

>Un des gros points forts de Xara etant son moteur de rendu qui n'est pas (encore) libre.

Euh, tu es sur? Il me semblait qu'ils l'avaient fait:
http://www.kdedevelopers.org/node/1872 par exemple..

Euh, si tu relies mon post, tu verras que je l'avais marqué..

Ton analyse n'est pas fausse, mais je dirais incomplete: pour optimiser réellement le temps de démarrage, il faut optimiser toutes les pièces..
Par exemple, je crois me souvenir qu'une optimisation récente "du kernel" a été de remplacer hotplug par udev et que cela a apporté un gain important.

Pour le démarrage KDE et OOo avaient fournis des patches a glibc pour amméliorer le temps de démarrage mais ils n'ont pas été pris donc ils travaillent sur d'autre contournements.

Pour le démarrage d'X si je me souviens bien un des problèmes est la double initialisation de la carte vidéo: une fois par le kernel, puis par X..

>mon mauvais anglais est bien plus proche de l'américain que de l'anglais. Je pense la grande majorité d'entre nous, ici sur dflp, est dans le même cas.

Euh, ce qu'on apprends à l'école c'est surtout l'Anglais, pas l'américain il me semble..
Certes sur le web la proportion est inversé, mais ce que tu apprends au départ reste..

Si tu veux aller par la Windows est le meilleur car tout le matériel est supporté.

BeOS supportait moins de matériels que Linux certes, mais c'était quand même un OS 'multi-configuration': pas figé à un matériel spécifique..
Et comme Linux aujourd'hui, il fallait faire attention quand on achetait son matériel..

La vitesse de démarrage n'est certes pas le seul critère de comparaison, mais BeOS était un OS assez comparable à Linux du point de vue desktop: protection mémoire, multi-threading, SMP, hardware supporté relativement vaste etc..

Et les applications (assez peu nombreuses malheureusement) étaient bien plus réactives que sous Linux (meilleure utilisation du multi-threading je pense), ce qui est *très* agrèable a utiliser..

Maintenant BeOS est mort, reste Linux qui s'amélliore lentement mais surement..
Sur certains points Linux était déja en avance à l'époque (multi-utilisateurs, export d'écrans) sur d'autres: vitesse de boot, réactivité des applications, Linux reste en retard (malgrès les CPU actuel biens plus puissants) mais les disques dur avec flash incorporé devraient s'occuper de la vitesse de boot et les processeur multi-core fourniront une légère ammélioration coté réactivité et on peut l'espèré inciteront peut-etre dans le future à une meilleure utilisation du multi-threading dans le codage des applications..

Moi, c'est le contraire: FireFox m'énerve car des fonctionnalités importantes comme se reconnecter aux sites suite a un crash sont délégués à des plugins et franchement s'amuser à jouer avec des plugins, bof!

Opera ne relegue pas la reprise sur erreur a un plugin lui, ce que je trouve bien plus raisonnable.

>Ma machine principale a en ce moment 3 disques de 160, 160 et 80Go, c'est plus long à tester et à monter que le seul disque de 800 Mo que l'on avait à l'époque.

Mmm, ce que teste le kernel c'est les filesystem pas les disques dans leur intégralité et puis il pourrait/devrait le faire en parallèle (j'ignore si le kernel le fait a l'heure actuel).

>Les périphériques USB, les cartes TV et des tas d'autres accessoires sont apparus depuis l'heure de gloire de BeOS.

Les periphériques USB oui, les cartes TV non, par contre elle n'était probablement pas supporté par BeOS à l'époque.

Ceci dit, si tu boote depuis un disque, l'énumération des périphériques USB n'est pas "critique": tu peux la faire tard dans le processus de boot, maintenant je ne sais pas si ça aide..

Pour démarrer le kernel a besoin seulement d'une partie du matériel, donc à priori le reboot ne devrait pas arriver trop souvent.
Aussi pour éviter le reboot il est possible de d'avoir deux entrées dans le bootloader: une par défaut qui réutilise la configuration existante, une autre qui fait le full discover.

Ceci dit avant d'en arriver la, il y a, a mon avis, *plein* d'optimisation à faire: BeOS sur un Celeron 333(128Mo de RAM) mettait 14s pour aller jusqu'à un bureau (fonctionnel pas comme celui de Windows qui triche).

Sous Linux, les 14s représentent en équivalent: le boot du kernel + le démarrage de KDE ou Gnome en auto-login.. Et BeOS le fournissait sans qu'on ait à trifouiller le kernel ou autre.

On es loin du compte à l'heure actuelle sur des machines bien plus puissantes..
Si les dev de BeOS l'ont fait, ce n'est pas la magie, c'est reproductible, mais bon souvent les utilisateurs Linux sont d'une mauvaise foi rare: "pas besoin d'arreter un PC sous Linux", ben voyons! Mon ordinateur n'est pas très bruyant mais mon appart est tout petit et j'aime dormir la nuit..

Ce que je trouve écoeurant c'est que c'est *pire* que slashdot..
En browsant a +3 /. on a plein d'informations interressantes:
http://linux.slashdot.org/article.pl?sid=06/06/01/1226240

On apprend que:
-Easyubuntu pour telecharger des packages supplementaires est mieux que Automatix.
-L'impression sous 6.06 a peut être des problèmes.

>Après, le toolkit graphique, que ce soit QT, GTK, Wine... peut importe.

Sauf que Wine essaye de cloner les fonctionnalités de Windows, c'est quand même très différent d'un toolkit normal.
Entre autre, il leur faut reproduire même les bugs de l'original pour être fidèle!

> Et bien si office etait gratuit, pourrais tu encore te permettre de dire qu'elle est pourri ?

Dans un jugement, le rapport qualité/prix intervient..

> Si oui la suite OpenOffice l'est encore plus.

Possible, je n'utilise pas OOo.

>Paradoxalement toutes les suites de ce genre seraient aussi pourries les unes que les autres mais n'ayant pas mieux tout le monde s'en servirait !

Pourquoi toutes? Le monde ne se résume pas à MSOffice et OOo:
personellement le traitement de texte que j'ai préféré est FrameMaker et je connais peu de personne qui préfére Word à FrameMaker (sauf les experts Words qui apprennent FrameMaker en deuxième), n'empèche que presque personne utilise FrameMaker: trop cher et maintenant le monopole .doc est bien établi..

>Finallement, on retient :
>- Il faut toujours choisir l'algorithme le moins naïf, si ce n'est pas couteux pour la conception du programme (shell sort contre bubble sort par ex pour 2 tri sans appels de piles)

*NON*, il faut choisir l'algorithme le plus simple, le plus maintenable en mettant une interface bien propre.
Mesurer les temps d'executions.
Si ce n'est pas suffisant: optimiser la ou c'est nécéssaire.

Le choix du language est plus difficile au niveau performance car si tu prends un langage lent genre Ruby, il y a aussi le risque du probleme des "milles coupures": pas un point chaud à optimiser (ça c'est pas trop compliqué) mais être lent partout et la, il n'y a plus qu'à réécrire.
Mais surtout il faut trouver un language accepté par ton chef donc D, Scala, Ruby, Limbo et autre Erlang, ce n'est pas gagné..

>> Et jusqu'à preuve du contraire, citer un future
>> échec^W^W^Wproduit Microsoft comme référence
>> sur linuxfr est du plus profond mauvais goût...

Note que singularity est un projet de recherche "pur", ils n'ont même pas encore essayé de vraiment voire le coté compatibilité avec les logiciels existant..
Comment un projet de recherche pourrait être un échec commercial?

>Ce genre de remarque me fais souvent plus pitié que sourir...

Assez d'accord avec ta réponse brouillon, mais pour ce qui est de leurs produits la on n'a pas le même point de vue: leur produit number 1 MSOffice, bien que leur rapportant des sommes indécentes est *pourri*: quand je vois le nombre de documents corrompu, l'interface pénible, etc.
Et la ils n'ont même pas l'excuse des driver.

Pour C#, certes c'est un effort interressant de chez MS, surtout la future v3 d'accord, mais a la base c'est quand même un clone de Java donc pas de quoi non plus s'extasier..

Ce qui est "capital", c'est qu'il y ait enfin des produits fiables en informatique, mais c'est autant (plus AMHA) un probleme de mode de travail que d'outils..

>Dynamo qui est une machine virtuelle proche des processeurs alpha

Non, des PA-RISC si je me souviens bien.
Et pour ce qui est du gain de performances, je me suis toujours demandé s'il serait si bon si on comparait avec du code optimisé "par profil" (on execute une fois le code qui génère un profil d'execution puis on recompile le code de nouveau en exploitant le profil pour amméliorer les perf).

Tu as tronqué mon commentaire, je disais supporte le multi-CPU en 'mode natif', c'est à dire sans différence entre mono et multi-CPU.

Je comprends bien qu'avant en utilisant des interfaces differentes on pouvait utiliser aussi plusieurs CPU.