Larry Cow a écrit 5011 commentaires

D'après ma récente expérience perso:

C'est compatible usb-mass-storage ?

De manière générale, et à moins d'aller chercher un modèle particulièrement tordu, oui. Le (futur) tien a l'air OK.

On peut monter à chaud sans risque pour le dur ?

Brancher ou débrancher le disque sur un PC déjà démarré, sans problème. Par contre, pour le débrancher il faut toujours démonter avant (logique) ou l'avoir monté avec l'option sync (pas bon pour les perfs).

Les taux de transferts sont-ils résonables ?

A condition que l'USB2 fonctionne chez toi, oui, complètement. Sur mon portable (dont le disque interne n'est pas non plus une bête de concours, il est vrai), je ne fais aucune différence de ce point de vue entre IDE et USB.

Maintenant, j'ai eu de grosses emmerdes avec le driver EHCI (nécessaire pour l'USB2) sur un noyau 2.6.9, donc je me méfierais. Mais bon, au pire tu retombes sur de l'USB1, donc avec des transferts plus lents, mais tu reste capable d'accéder à tes données.

Ensuite, une école orientée Linux, ça m'étonnerait que ça existe (tout comme une école orientée vers n'importe quel système, d'ailleurs).

Et Supinfo, ils sont pas un tout petit peu orientés, peut-être?

Rox Filer, gentoo, xfe parmi beaucoup d'autres dont j'ai perdu le nom

Pour manipuler des fichiers, ça suffit très largement, en effet. Je crains seulement que les utilisateurs d'aujourd'hui attendent un peu plus que de simplement manipuler des fichiers.

Abiword ouvre plusieurs documents sans planter, sinon siag office ou appliware, et au pire OpenOffice qui n'est pas bien plus lourd que le Office 2000 que tu prends pour référence (fait démarrer Office 2000 sur une vieille bouse qu'on rigole ^_^)

C'est vrai, mais un simple Office 97 s'en sortira infiniment mieux, coté rapidité qu'un OpenOffice. Hélas.

En fait, c'est à tel point qu'il serait peut-être judicieux de lancer une branche "light" d'OpenOffice. Faudrait que je regarde ça, un jour.

explorateur de fichier : midnight commander (trouves plus léger héhéhé).

Euh, bash?

Au niveau ergonomie, je déteste explorer, c'est une question de goûts.

C'est ton droit (c'est le mien aussi), mais ce n'est pas un argument. On compare Linux et Windows, ici. Sous-entendu "pour tout le monde". Pas Linux et Windows pour l'usage que _tu_ en as. Sinon, forcément, tout le monde trouve que sa solution est la plus adaptée.

suite bureautique: ...euuuuh vim ? ^^ je suppose que si c'est pas un cliquodrome c'est impossible de taper une lettre ? (pour le reste des fonctionalité d'une suite bureautque, je ne sais pas, mais on doit pouvoir trouver un truc)

Sur le fond je suis d'accord avec toi, sur la forme tu ne _peux_ pas imposer aux gens ta (notre) vision. Les gens ont besoin de mettre du texte en gras à la moindre occasion, c'est probablement déplorable, mais c'est comme ça. Tu ne peux pas demander au pékin lambda de devenir typographe pour taper "à la machine".

Office 2000 sur windows 98 c'est ca ? ca se lance au moins sur une machine avec 16 Mo de ram ? si mes souvenirs sont bons, il refuse carrément de s'installer (tapez moi si je dit une connerie). Essaie d'ouvrir un document écrit avec office 2003 qu'on rigole ;)

Microsoft Office 97, sans problème. Même MS Office 2000, sur 64 Mo de mémoire vive, ça se passe encore assez bien. Et tu fais tourner ça de manière utilisable sur un PIII-600, d'expérience. Un OOo récent marche aussi, bien sûr, mais il met largement plus longtemps à se lancer, à sauvegarder ses documents, etc. Seul véritable atout d'OOo pour le pékin, dans ce cas-là: l'export PDF. Une fois son document créé, il peut le ressortir autant de fois qu'il veut sans avoir à lancer une (lourde) suite bureautique.

Et, tout à fait accessoirement, le pékin lambda n'a pas forcément besoin d'ouvrir des documents créés avec Office 2003. Généralement, il a besoin d'ouvrir des documents créés par lui

bon, en dehors du fait qu'un navigateur n'est pas une ampoule, elinks se lance assez rapidement tu trouves pas ?

Et il peut aller consulter ses mails hotmail, le monsieur avec ça? Consulter ses comptes en ligne? Commander sur Amazon?

Je suis bien d'accord avec toi que, pour aller lire linuxfr ou chercher de la doc, (e)links suffit amplement. Seulement, ce ne sont pas des occupations qui passionent le pékin.

Bon et saches que sous linux, par exemple pour me monter une passerelle, je peux me passer d'interface graphique, et là ça devient incontestable, linux est beaucoup moins gourmand. Donc ton seul cas d'exception...

En même temps, la supériorité de linux sur les postes serveurs, y'a guère que les consultants MS qui en doutent. Sur le poste client, même si ça reste une alternative séduisante et utilisable dans bien des cas, c'est encore très très loin de dépasser les OS Microsofts. Fut-ce en matière de coût.

Et la majeure partie de tes arguments n'est pas en faveur de l'informatique libre, mais de l'informatique geek. Et autant on peut réussir à faire passer l'esprit du libre, je doute fort que l'esprit geek soit applicable à tout le monde :)

Comme dit le monsieur du haut, prendre Gnome au lieu de KDE (ou l'inverse, ne soyons pas sectaires) "pour la légereté", c'est comme hésiter entre bazooka et lance-flamme pour tuer un insecte.

La première chose que je te conseillerais, quite à utiliser une environnement, c'est de privilégier les applications issues de cet environnement: au moins, comme cela, tu éviteras de charger à la fois les bibliothèques Gnome et les bibliothèques KDE (ce qui se passe lorsque tu utilises KOffice sous Gnome, typiquement). Dans ton cas, KDE semble donc plutôt plus conseillé (à moins que le couple abiword/gnumeric suffise à tes besoins bureautiques, auquel cas exit KOffice). Dans ce cas, je te conseillerais également de regarder du côté de prelink.

Sinon, effectivement, les window managers "tous simples" ont du charme aussi, faut pas les oublier :)

Idéalement, vaut mieux pas attendre qu'il sente ;)

(mais tu sors quand même :p )

On disait un peu pareil du cluster de google, à ses débuts. Sauf que les quantités n'étaient pas les mêmes, mais c'était tout aussi impressionant.

a) Normalement tu choisis une copine qui a des goûts et une façon de vivre plutôt compatible avec la tienne.

Ca, c'est quand tu es jeune et fougueux et plein d'illusions. Passé un certain temps, tu ne choisis plus les filles que sur un seul critère: le fait qu'elles soient (ou non) consentantes.

:)

Sauf erreur de ma part, le "nom compliqué du dossier utilisateur" est plus une feature qu'un bug. C'est présent dans tous les dérivés de Mozilla, et ça permet d'empêcher qu'un script malicieux puisse aller modifier le contenu du profil autrement que par les fonctions "autorisées".

De mémoire, "TD" (tournedroit) prenait des degrés en argument. Donc à priori, tu remplaces le 1000 par un joli 360, sinon c'est gâcher (tu dessines presque trois cercles superposés).

L'archéoptéryx c'était du flan? Gosh...

Pour le moment, seul LBA1 est supporté, ou bien?

Et puis les sources, j'ai donné l'url du projet sourceforge dans le journal, de là tu devrais pouvoir trouver le CVS...

Si tu n'as toujours pas compris qu'un langage ne pouvait être le meilleur que pour un (ou plusieurs, certes) domaine donné... si tu n'as toujours pas compris ce qui dérange certaines personnes dans le C++... c'est peut-être que tu n'en as pas fait suffisament.

C++ est un bon langage pour certaines choses. Pour de la simulation, par exemple.

C++ est un langage quelconque, voire médiocre, pour d'autres choses, comme le développement de GUIs. Typiquement, les meilleurs APIs graphiques basées sur du C++ ajoutent toutes une bidouille à leur sauce pour dépasser les limites du langage. Genre QT avec le moc. Sans parler de cette vision si particulière (d'autres diraient "psycho-rigide") de l'objet.

C++ est un (très) mauvais langages pour d'autres tâches, et la programmation système en fait partie.

Oui, enfin l'intérêt d'utiliser une version "bidouillée" (je sais pas comment le portage win a été fait, mais faut pas s'attendre à quelque-chose de fondamentalement mieux) plus une couche d'abstraction complexe (wine) au lieu de la version originale associée à une couche d'abstraction plus simple (dosemu)...

Enfin si ca marche avec wine, c'est déjà ça ;)

Sinon, la version software normale marche pas trop mal normalement, reste pas mal de bug dans les collisions des projectiles qui rends le jeu infinissable (on bloque à un point precis de l'aventure).

Waw, ça a pas mal bougé depuis ma dernière tentative. Il faut absolument que je réessaye.

Toutes mes félicitations pour ton excellent travail, ma nostalgie te remercie :)

De mémoire, LBA1 est sous DOS (LBA2 je suis moins certain). Donc à priori, Dosbox ou Dosemu, plutôt. Mais j'ai le vague souvenir que c'était pas terrible...

Dans l'article de Yahoo News:

WASHINGTON – Une affaire aux États-Unis fera sûrement jurisprudence sur la façon dont doit être appliqué le DMCA (Digital Millenium Copyright Act), la très sévère loi américaine sur le copyright à l'ère du numérique.

Il me semblait justement que, à la différence du système judiciaire français, la notion de jurisprudence était totalement inconnue du système étatsunien? J'ai raté un épisode, ou bien?

Le truc c'est que, comme toujours, ca dépend de l'utilisation du système d'exploitation. Sur un OS résolument dédié à une utilisation "desktop" (BeOS), avoir la gestion avancée du mélanges des canaux directement dans l'OS est essentiel.

Sur un OS qui, comme Linux, est encore largement utilisé dans l'embarqué et serveurs, ajouter ce genre de fonctionnalité directement dans l'OS est un peu limite. Passer par un outil en userland, parfaitement desactivable et non-intrusif pour le noyau, est tout à fait justifié. Et ca tombe bien, c'est justement ce que fait esd (mal, il est vrai, mais ce truc est complètement passé d'age).

C'est un rootkit, quoi. Présenter ça comme un virus, c'est à la limite de la malhonneteté intellectuelle.

Je ne suis pas une informaticien a la base, et j'avoue parfois avoir du mal a bien différentier un file systeme d'une base de donnée, surtout quand je lis que beaucoup des idées de reiserFS 4 sont venue suite a l'etude des BD...

D'ou mon idée candide d'utiliser directement une BD a la place du FS...

Un FS et une BD reposent sur le même principe, c'est vrai. De la même manière qu'un microphone repose sur le même principe qu'un écouteur. Et effectivement on peut faire faire le travail d'un FS à une BD (ce que tu proposes) ou l'inverse (mais ça fournit une BD largement moins riche que ce qui existe aujourd'hui).

En fait, FS et BD visent le même problème, stocker des données, mais en mettant l'accent sur différents aspects de ce problème. Dans un FS, ce qui importe c'est d'avoir un accès rapide, les fonctionnalités de recherche/classement sont optionelles. On a donc une structure "relativement" simple et uniforme pour tout les fichiers, et un nombre restreint et figé (sauf dans le cas des EAs, dont je parlais plus haut) de "champs" (les attributs, ceux que ls te montre).
Dans une BD, les performances sont moins primordiales, mais en échange on désire pouvoir utiliser une algèbre sophistiquée (généralement l'algèbre "relationelle") pour faire des manipulations avancées (recherche, sélection de sous-ensembles, fusion de deux données différentes, etc.).

La différence de design entre les deux tient principalement à un consensus différent en matière d'équilibre fonctionnalités/performances. Certains projets visent à introduire de nouveaux consensus intermédiaires, comme les attributs étendus ou les systèmes d'indexation de fichiers.

Cependant, il faut bien garder à l'esprit que les premiers essais de filesystem de BeOS étaient de véritables SGBD, mais ont été abandonnés pour cause de performances déplorables (au bénéfice du système actuel, avec un FS "classique" amélioré).

J'espère pas avoir dit trop de conneries :)

Un peu comme ce que faisait BeOS avec ses requêtes dynamiques en fait (que l'on pourrait qualifier d'équivalent des "vues" des SGBDR pour les systèmes de fichier).

En parlant de ça...

Il y a quelques temps, des gens (d'une ML gnustep) se posaient la question de l'utilisation des attributs étendus dans les systèmes actuels. C'est vrai que l'usage qu'en faisait BeOS était séduisant: il stockait le type MIME du fichier, l'application préférée, l'icone (en plusieurs résolutions si besoin) et diverses métadonnées liées au type du fichier (tags ID3, ...).

Seulement, si on veut transposer toutes ces jolies choses dans un système actuel, on se heurte à un problème "balot": BeOS était mono-utilisateur. Ca peut paraître stupide, mais si on applique strictement la même chose que BeOS au niveau du stockage des métadonnées dans les EAs, on fait n'importe quoi: typiquement, on peut vouloir ouvrir un fichier donné prioritairement avec une application différente de celle préférée par le propriétaire du fichier.

En gros, on peut ranger les attributs en deux catégories: ceux intrisèques au contenu du fichier (type MIME, tags ID3) qui peuvent rester en attributs étendus, et ceux qui sont liés à une vision que l'utilisateur a du fichier (application préférée, icone) qui - dans un système multi-utilisateur - ont tout intérêt à être regroupés dans une structure à part, propre à l'utilisateur.

C'est dommage, je trouvais ça mignon de stocker l'icone directement dans le fichier :)

Et quand le CVS est cassé, tu attends quelque jour et ça remarche :)

GCC n'est pas qu'un compilateur C, mais une suite de compilation "générique" qui sait également bouffer du C++, du Java, du Fortran, ...

Et puis aussi, des choses comme ça:

TCC implements many features of the new C standard: ISO C99. Currently missing items are: complex and imaginary numbers and variable length arrays.

Et enfin le fait que, si TCC est léger et compile vite, il n'est pas garanti du tout que le code produit soit plus efficace que celui écrit par GCC.

TCC est une très jolie démonstration du savoir-faire du monsieur (même si QEmu et FFMpeg sont plutôt plus significatifs, à mon avis), ainsi qu'un outil de plus dans la malette de l'utilisateur de logiciel libre. Un outil qui peut s'avérer utile dans certains cas, peu fréquents certes, mais qui mérite tout de même d'exister.

Sans aller jusque-là, on pourrait imaginer un système qui déplace l'indexation des fichiers vers une base de données (ce que propose WinFS et consorts, si je ne m'abuse), les fichiers restant sur le disque.

Une petite couche logicielle (remplaçant les appels systèmes open, opendir, stat et lstat, par exemple) pourrait se charger de l'execution et de la presentation (sous forme de répertoire) des recherches dans la base. Une fois le "bon" fichier trouvé, la base nous donne son path et permet aux outils standards de s'en sortir. L'intérêt étant qu'on peut aisément demander à la couche logicielle en question de ne lancer ce genre d'"usine à gaz" que pour certains répertoires.

Reste que l'idéal serait quand même un FS spécifique, mounté là ou il faut.

Il y a eu, à un moment, une tentative de clone: The Penguin Machine [1]. Malheureusement, il est mort et enterré aujourd'hui.

Cela dit, il y aurait peut-être moyen de faire quelque-chose avec les moyens actuels ... à base de pygame et d'ODE, par exemple. :)

[1] http://tpm.seul.org/(...)