Je repense à un truc de fish qui le fait roxer encore plus : c'est qu'il n'est pas limité au lan. Dans mes souvenirs c'était très difficile de partager de manière sécurisée ses données locales avec les postes distants, depuis windows.
Alors que depuis linux t'a rien à faire (sauf éventuellement rediriger un port), juste fish://IP depuis n'importe où.
Et j'en profite pour clarifier
"Linux" (KDE et Samba plutôt), quoi que t'en dise, s'en sortent bien mieux.
je voulais dire par là que GNU/Linux gère bien mieux SMB que windows ne gère fish, ou même ftp.
Alors en effet, il y a eu des progrès effectués en ce sens, mais le partage de fichiers n'est pas encore quelque chose d'aisé sur le réseau local, ou alors j'ai manqué quelque chose. :-)
Oui.
Ça s'appelle fish. Y'a pas besoin de configurer quoi que ce soit, juste d'avoir ssh d'installé. Et c'est très sécurisé.
Bon, ça c'est pour entre deux linux (cas de ton journal). Après, quand t'a un windows dans la partie, le moyen le plus propre c'est de configurer un partage automatique des répertoires home (ou du slash, si tu veut faire comme sous windows).
Suivant tes goûts, ça peut se faire en éditant trois lignes de codes ou en clicouillant quatre fois la où il faut (dans samba de kcontrol, tu choisi "nouveau partage" et tu demande à partager les répertoires maisons). Je doute que tu ait bien cherché pour manquer ça !
Remarque que ça pourrait être fait par défaut, mais c'est pas anodin d'un point de vue sécurité, et en fait ça en sert que quand tu est gêné par la présence d'un windows donc...
Dans mes souvenirs les outils de mandrake sont encore plus simples.
Le coup du mot de passe root, c'est débile, car du coup, pour qu'un utilisateur puisse partager un dossier de son home, tu dois lui filer le mot de passe d'administration (ou configurer sudo).
C'est un choix de la distribution, pour faire sentir que partager des donnée par samba n'est pas anodin. Ça peut se désactiver dans l'onglet qui va bien de kcontrol .
Mais de toutes manières le problème vient de windows : il ne sait pas accéder de manières transparentes aux partages par fish/ftp. "Linux" (KDE et Samba plutôt), quoi que t'en dise, s'en sortent bien mieux.
Pour tes problèmes de nomages évoqués en 2) c'est encore une fois windows qui fait mal son job, lan:// n'a aucune difficulté à présenter une vue hiérarchique des services d'un réseau.
Linux est indépendant de GCC dans le sens où n'importe quel compilateur C est censé pouvoir compiler Linux.
Non, uniquement gcc. C'est écrit noir sur blanc dans le README à la racine des sources.
Et à d'autres endroits qu'il ne liront pas les rapports de bugs fait avec d'autres compilateurs.
Alors bon, en pratique ça marche avec d'autres, mais c'est pas plus un objectif que le support des pilotes binaires.
Linux à débuté indépendemment du projet GNU et n'est pas un projet GNU.
Je ne pense pas que Linus aurait inventé la GPL. Il était déjà pas bien chaud pour ouvrir son code à la base... (cf sa bio)
C'est un fan de la FSF qui lui a ouvert les yeux.
De plus les développeurs Linux ont mis dans leurs prérequis GCC>2.95.3 et GNU Make>3.79.1.
Sur d'autres compilateurs/make les rapports de bugs sont ignorés.
C'est quand même une reconnaissance officielle.
ça me semble un peut fastidieu de devoir attacher des tags à un peu tout
Pour éviter d'avoir à tagger, le système de KDE (tenor) utiliseras les liens entre les documents pour les classer.
Par exemple au lieu de chercher les photos avec le mot clef "vacances" et "nièce" tu chercheras les photos que tante Mireille t'a envoyée en Août. Ça évite d'avoir à faire des annotations sur les photos (même s'il existe des outils efficaces pour en faire).
Et pour les documents textes (ou équivalents), il suffit d'indexer le contenu (prévu aussi).
Ça dépends, on peut avoir besoin de tel ou tel logiciel qui ne seraient pas dans la distrib en version stable (apc, eaccelerator, openoffice2.0), où de certaines fonctionalités (mpm, selinux...).
Tout à fait, mais il n'est pas necessaire d'utiliser une distro source pour cela, je le fais régulièrement sur des distro binaire.
Youpi. Donc tu installe en vrac et tu fait les mises à jours à la main. À moi que tu n'ait ton propre dépot ? Il reste que tu doit surveiller les paquets.
Et je doute très fortement que tu ait mis en place selinux sur une debian en moins d'un mois de travail intensif. Des choses, parmis tant d'autres, qui ne sont pas necessaires avec des distributions sources (et qui ne sont que des exemples).
À d'autres ! J'utilise des distros sources depuis mes débuts, à peu près à la même époque que toi.
Mes début ? Basé sur quoi ? Mon inscription Linuxfr ? C'est une mauvaise base, ma première installation de Linux, certes très laborieuse, date de 1998.
Admettons. Il reste que j'utilise des distros sources depuis assez longtemps pour que l'attrait de la nouveauté ai fini de jouer.
Un type qui upgrade sa glibc et/ou casse tout son arbre de dépendance (ce qui se passe à l'heure actuelle sous debian si tu installe kde 3.5) perds beaucoup plus de temps qu'un gars qui lance un "emerge kde-meta" avant d'aller se coucher.
Et ça prendra plus de temps que quelqu'un restant en 3.4 (ou 3.3)... Mais certe, Debian n'est pas une distribution pour avoir la toute dernière version d'un soft "dans la minute". Mais ça, c'est de l'amusement, rien d'autre.
Non, je voulais pouvoir utiliser Konqueror pour aller sur Gmail et les filtres KMail par imap, plus la webcam.
Pareil pour selinux, ssp, Jabber2 sur amd64... ce sont des choses qui nécessitent de compiler et qui sont utiles.
D'ailleurs il ne s'agit souvent pas de minutes mais d'années avec debian stable, et de 6 mois en testing. Et ceci à cause du lien fort qui existe entre les versions des packages utilisateurs et du coeur du système, sur toutes les distributions binaires.
Les miennes se portent bien, depuis quelques années déjà.
Parceque tu en prend soins :-)
Je ne vois pas ce que tu veut dire. Sur mon serveur je ne fait plus que les mises à jour réglementaires.
Sous gentoo, virer les dépendances à gnome me prend 16 secondes, montre en main (je viens de faire le test, il inclut la phase de login).
En comptant la recompilation ?
Non, je ne compte que le temps d'interaction avec la machine que l'opération me coute. Et ce temps est très court sous gentoo.
Le reste ne corresponds pas à un compromis que j'aurais à faire. Que ma machine compile ou se repose, c'est son problème: elle marche et ça me suffit.
Ce qui *est* impossible.
Il y a des centaines de contributeurs sur les + de 10 ans d'existence. Il faut obtenir l'accord de *tous* ces contributeurs.
Je ne pense pas, pour trois raisons :
Y'a d'hors et déjà une boite qui fait des FS en propriétaire sous Linux (paragon software, assez connue normalement) : http://www.ntfs-linux.com/ . Et ATI qui fait des drivers.
Pas que je trouve ça bien (à priori, ce que fait paragon est illégal). Mais si ils sont dans la légalité alors on peut facilement supposer qu'un de ces composants serait légal s'il était GPL3.
Autre méthode : utiliser une double licence GPLv3/GPLv2 pour ne changer que le minimum. C'est d'autant plus faisable que des pans entier du noyeau sont sous licence GPL, "version 2 ou supérieure" (la couche IP par exemple).
L'idée c'est que pour ajouter des composants GPLv3, on n'a besoin que de convertir les interfaces et le coeur du noyau, quitte à récrire les parties correspondants aux gens qui sont morts (à priori peut nombreux).
Donc pas besoin de changer la licence des drivers (qui doivent représenter l'essentiel du code), des FS existants, peut être même des fonctions d'initialisations... Ça fait tout de suite moins herculéen. Surtout si tu compte que le coeur noyau doit être écrit par une poignée de personnes dont un bon nombre doit être encore actif.
Si (comme tu le dit) un gars aurait eu besoin de quelques années pour convertir tout le noyau, alors une dizaine de gars motivés devraient pouvoir en convertir le coeur en un an.
Et enfin, au pire, une autre possibilité serait de faire comme nVidia ou ndiswraper : une couche d'abstraction qui permettrait de produire des pilotes/filesystems portables, et la publier sous GPLv3 sur des systèmes BSD.
Ensuite intégrer sa version GPLv2 dans le noyau officiel. Dès lors les composants GPLv3 intégrés au noyau peuvent utiliser la version GPLv2 sans en dériver.
The Free Software Foundation may present drafts of LGPL along with drafts of GPL subsequent to the first discussion draft of GPLv3. Such drafts would also be subject to public comment and issue resolution.
Sinon l'idée d'une plus grande compatibilité est excellente, ça permetras d'unir plus de projets derrière cette licence et d'en réduire le nombre. Notement, si Linux passe en GPL3 (ce qui s'annonce difficile), on peut espérer récupérer du code de Solaris (au grand damn de celui-ci).
Une autre idée interessante et de faire qu'autoriser l'usage d'un logiciel par le biais d'une interface n'étant pas un travail dérivé de celui-ci (par exemple permetre l'accès aux fonctions d'un logiciel libre par http) nécessite que le code de ce logiciel soit distribué (la restriction qui serait optionnelle) : http://www.newsforge.com/article.pl?sid=00/11/01/1636202&(...)
Ces drivers binaires, ils s'exécutent sur le PC ou sur un processeur embarqué sur la carte graphique/wifi/réseau/etc... ? Les deux? Dans quelle proportion?
Les parties considérés comme "à problèmes" s'executent dans le noyau. Les autres (firmwares) relèvent plus des détails de réalisation du hardware.
Si les codeurs n'utilisaient pas ces drivers non libres pour cartes graphiques, il n'y aurait aucun jeu vidéo 3D sous Linux...
C'est bien joli de critiquer, mais bon...
L'idée est que si les pilotes proprios étaient impossibles, les pilotes seraient libres, comme c'était le cas il n'y a pas si longtemps.
va reverse enginerer les pilotes ATi, c'est nettement plus hardcore qu'une bête carte réseau ou un pilote IDE
Et pourtant, y'a des bourrins qui y arrivent ! Ça doit être possible. http://r300.sourceforge.net/ supporte déjà ppracer et quake3 (proprio...).
En fait les développeurs de KDE 4 ont prévus bien plus: un système qui utilise vraiment les relations entre les documents, et pas juste des mots clef.
Ça s'appelle Tenor, et c'est décrit dans une interview de son développeur : http://www.linuxplanet.com/linuxplanet/reviews/5816/1/ .
Sinon l'interface avec des trucs qui tournent et qui bougent c'est classe, mais je sais pas si c'est efficace.
En pratique, on nous montre trois machins :
Le premier permet de savoir quand est disponible tel ou telle personne pour les faire partciper ensemble à une activité. En plus le machin est censé trouver des activité interessantes... si c'est vrai c'est de la pub intégrée dans le carnet d'addresse. Youpi.
Et puis, j'ai du mal à penser réellement en ces termes les disponibilité de mes proches : c'est pas parce qu'il sont libres d'habitude qu'ils seront d'accord pour participer, ni parce qu'il sont occupé d'habitude qu'il ne viendront pas. Donc je mail les gens que je veut voir, pas ceux qui sont disponibles.
Surtout que ça suppose d'avoir collectée des informations sur la disponibilité des gens et que ces gens les tiennent à jour dans leurs ordinateurs. Quand on en est à ce stade, il faut changer d'amis.
Par contre il présente même pas la possibilité de classer les gens par groupe, autrement plus utile.
En terme de fonctions de recherche, KDE 3.4 ne sait pas grouper les gens par horaire de disponibilité, mais il sait mémoriser et tenir à jour cette information, ainsi que la localisation des gens... enfin, tout ça pour dire que c'est pas winfs qui est présenté mais juste une interface, qui n'est à priori pas prévue (la vidéo est juste un mockup).
Ensuite on nous montre un truc qui permet de classer des films par préférence. Youpi. Y'a encore des trucs qui tournent, et qui affichent de toutes petites previews au lieu du nom du film. Ergonomie == 0.
Et enfin, l'outil qu'on nous montre permet mettre en relation des personnes des dates, des photos, des personnes et des lieux. C'est pas neuf.
Et encore, il sont obligé de taper l'adresse email des personnes à la main pour leur écrire.
Et les fenêtres sont toutes penchées... c'est vraiment que de l'amuse-oeil pour client en mal de patience. Ça présente l'interêt de mettre en relation des informations dans un cas où ça n'en a pas vraiment, sans présenter quoi que ce soit de propre à winfs (tout sauf les photo est issu de l'internet), et en supposant une "application de création de fête" qui n'existeras pas, à ma connaissance.
AU fait quelqu'un sait si le "nouveau" ZFS de Sun sera supporté sous GNU/Linux ?
Non, Sun a choisi une licence maison incompatible avec les GPL <3.0. Et puis, jamais les developpeurs Linux n'accepteraient d'un tel code : déjà que reiserfs 4 a du mal à passer parce qu'on lui reproche de dupliquer des fonctionalités du noyau...
Ça dépends, on peut avoir besoin de tel ou tel logiciel qui ne seraient pas dans la distrib en version stable (apc, eaccelerator, openoffice2.0), où de certaines fonctionalités (mpm, selinux...).
quand tu en aura marre de passer plusieurs heures par semaine à t'occuper de ton système
Je le fait parce que ça m'amuse mais ce n'est pas une nécessité. Un "emerge sync && emerge -uvD world;etc-config" toutes les semaines suffirait (suffit à mon serveur en fait). J'estime le temps d'interaction avec la machine à dix minutes dans ce cas.
tu reviendra, comme beaucoup, vers un système binaire
À d'autres ! J'utilise des distros sources depuis mes débuts, à peu près à la même époque que toi.
D'ailleurs je connais plus de gens qui font le passage dans le sens binaire vers source que le contraire.
Crois moi, quand on passe son temps à customiser des serveurs, on a pas du tout envie de customiser sa Workstation, on veut que ça marche et c'est tout.
Justement !
Un type qui upgrade sa glibc et/ou casse tout son arbre de dépendance (ce qui se passe à l'heure actuelle sous debian si tu installe kde 3.5) perds beaucoup plus de temps qu'un gars qui lance un "emerge kde-meta" avant d'aller se coucher.
Utiliser une distro source augmente le temps d'installation initial de la plupart des logiciels, mais réduit l'interaction nécessaire avec la machine.
Et à moyen terme, le contrecoût disparait : en cas de mise à jour tu a plus vite fait de compiler toi même que d'attendre que le mainteneur sorte son paquet (au mieux, il va aussi vite que toi à compiler, en pratique beaucoup moins). Alors c'est ton CPU qui bosse, mais avec un nice de 20 (NICENESS dans le make.conf) ça se voit même pas (sauf sur les portables).
Et je ne suis de toute manière pas convaincu de la pérennité d'une Gentoo sur le long terme.
Les miennes se portent bien, depuis quelques années déjà.
tu installera les librairies Gnome, parceque ça sera toujours plus simple et rapide que de customiser son système
Sous gentoo, virer les dépendances à gnome me prend 16 secondes, montre en main (je viens de faire le test, il inclut la phase de login).
Tant qu'on est à en parler, la dernière version de Konqueror supporte Gmail et Gmap, à condition de camoufler son user agent en repectivement Firefox et Safari.
On ne peut pas tourner autour de quelque chose sans que l'inverse soit également vraie.
Géométriquement oui, mais si tu tu observe le mouvement des objets je trouve ça plus douteux :
Imagine : un fou te tourne autour en courant avec une balle de tennis à la main. Comme il est fou, il pense que c'est toi qui court.
À un moment il lance la balle de tennis qu'il tenait, droit devant lui.
Toi tu voir la balle prendre la tagente et suivre une jolie ligne droite, et lui il va pas comprendre (il va voir une parabole, ou shadokoïde quelconque mais pas droit).
Bon, en fait pour que ça marche sans tricher il faudra que les épaules du gars restent parallèles aux tiennes pendant sa course (donc un fou très entraîné), mais le résultat sera à peu près le même au sens où son référentiel sera pas galiléen du tout.
Pour en revenir au sujet de départ, je trouve que l'interêt de compiler ses paquets est d'être libre des dépendances binaires, beaucoup plus strictes. Par exemple je peut figer (une ligne dans portage.mask) php à la version 4.1, ou passer à kde 3.5, sans que ça n'exprime des contraintes sur la version de ma glibc ou de quelque autre composant plus critique.
Autre exemple : installer xine implique d'installer des librairie de Gnome sous debian, parce que sinon les gnomistes ne pourraient pas accèder aux fonctionalités dont ils ont besoin (c'est d'autant plus dérangeant que Xine est necessaire à KDE). Sous gentoo un "useflag" (mot clef à mettre où non dans un fichier) adapte dynamiquement les dépendances aux habitudes de l'utilisateur.
De manière plus générale, ça permet de proposer à ceux qui les veulent des fonctionalités qu'on ne pourrait pas imposer à tout le monde.
(et le gain de perfs est à priori réel, par rapport à des binaires 386 - 686 je dit pas par contre)
Pour les cd audio et les dvd, je n'ai jamais ete empeche d'user de mon droit a la copie privee, meme l'unique cd copy controlled que j'ai achete n'a pas moufté quand je l'ai rippe (il m'a pose moins de probleme que des cd a moitie foireux qui pourtant passent tres bien dans mon autoradio, ma chaine hifi etc).
Moi j'ai expérimenté un truc rigolo : des CDs dans une matière qui se raye quand elle passe dans un lecteur de vitesse supérieure à 2x (AIR: "everybody hertz" et "10kHz legend", par Sony).
On me les a offerts pour noël, je les ai écoutés dans la voiture, nikel. En arrivant chez moi j'ai voulu les ripper en Flac pour faire une copie de sauvegarde et ça en a bousillé un avant que je comprenne. Comme il a été acheté dans une boutique à des lieu de chez moi (et pour pas faire chier celui qui me l'avait offert), j'ai été obligé de le télécharger sur edonkey.
J'ai ripé le second après un hdparm et c'est passé comme une fleur.
L'absence de labal CDAudio aurait dû attirer mon attention, mais je me suis pas méfié. Enfin... tout ça c'est pour dire que tout le monde n'a pas ta chance.
Un autre problème peut venir du cache des disques durs : [...] et la plupart des fabriquant désactivent l'instruction permettant de le vider
S'il te plait, tu pourrait expliquer techniquement ce qu'il en est, je vais bientôt mettre en place une machine pour enregistrer énormément de données à toute vibrure, et ce truc sur les caches internes m'intrigue...
Je peut répeter le peu que je sait : beaucoup de disques durs, de cartes raid (et, parait-il, Linux à une époque) désactivent les commandes de synchronisation de cache, utilisées par des outils de benchmarks pour faire leur tests.
L'interêt c'est de forcer le bench à utiliser le cache. S'il fait ses tests sur de petits fichiers ça change tout.
Y'a un gars qui a écrit un petit programme pour vérifier si le disque obéissait : http://www.livejournal.com/users/brad/2116715.html (le warning au début est lié à l'auteur de la news slashdot qui avait mal compris et qui croyais que le programe ne faisait intervenir que le comportement du disque)
D'après lui, un workaround pour certains disques IDE est de carrement désactiver le cache avec hdparm, mais ça marche pas systématiquement.
Le rapport avec les systèmes journalisés c'est qu'à mon avis, si le cache se vide pas, y'a (entre autre) un risque que le réordonnancement des données dans le cache par le disque dur bousille le journal si le système plante au mauvais moment.
J'ai dû lire un truc là dessus mais je sais plus où... désolé.
Ah et puis quand je dit qu'à mon avis les caches servent à rien c'est parce que Linux utilise la ram à la place, qu'il sait aussi réordonancer les écritures mais que lui il triche pas.
... j'espère ne pas avoir dit de bêtises... je retrouve pas toutes mes sources mais ça m'a l'air logique.
Sinon, si tu fait des trucs importants, tu devrais envisager d'utiliser une alimentation de secours.
Le message « scandisk a corrigé une erreur » je l'ai vu quelques fois en effet, lorsque j'arrêtais mal Windows 9x, mais cela ne m'a jamais occasionné la moindre perte. Je pense plutôt qu'il s'agissait de fichiers temporaires propres au système.
Laisse moi le temps de reprendre mes esprits... tu affirme que fat32, système de fichiers mal conçu par excellence et non journalisé, est plus résistant que XFS ?
Sinon on peut effectivement imaginer que toutes les corruptions aient eu lieu sur des fichiers temporaires...
je m'étais habitué à avoir un système de fichiers en béton armé.
Cette notion n'a pas de sens, pour le peu que j'en sache.
Un système de fichier peut être journalisé au niveau de la structure du fs (Reiserfs, NTFS, XFS) ou des données (Ext3 mode journal). Dans ces deux cas il est tiendras en cas de chute.
À mon avis, un système de fichier "en béton" ça veut juste dire que tu n'a pas connu de problème à l'époque de ce fs, pour une raison ou une autre, par exemple que ton disque était moins vieux ou que ton grille pain n'était pas backdoré par les extra terrestres.
Ou alors, ta mémoire a des défaut subtils... quoi qu'il en soit ça ton cas particulier n'est pas ce qui m'intéresse, et j'aimerais bien que tu compare les FS sur autre chose que ton expérience personnelle.
Sinon, tu vas sur un forum et tu dit "chez moi ça marche pas". Grosso modo, y'a pas d'autres informations dans ton post.
A un moment tu dit :
je parle de la moitié de ton home qui a foutu le camp on ne sait où, où de ton système qui est en vrac et refuse de booter parce qu'il ne trouve plus ses petits.
Si tu perd des données sans y avoir accédé en écriture dans la minute qui précède, ou la structure des dossiers, c'est que ton matériel est défaillant, je persiste.
Et si tu veut être sûr que tes données ne seront pas corrompues en cas de crash, il existe un moyen, et un seul : le mode journal de ext3, c'est tout.
Ceci dit, je doute que microsoft ait déployé un système semblable par défaut sur ntfs, parce que c'est couteux en perf. Donc je persiste à penser que tes problème ne viennent pas du FS.
Je doit reconaitre que NTFS est particulièrement corriace, je l'ai vu marcher^Wramper sur des disques qui avaient presque plus de secteurs defectueux que de fichiers. Peut être qu'il réalloue les secteurs défectueux ailleurs ?
Par contre sur le PC de ma maman il a décidé récemment de faire des écrans bleus. Même le CD d'install de windows plantait, alors que la partoche était parfaitement lisible sous linux... comme quoi desfois.
Pour en revenir au sujet, je conseille au gens qui ont des pertes avec leur FS de tenter "smartctl -t long", on a souvent des surprises. Dans ce cas, activation de smart dans l'espoir qu'il réalloue les secteurs, et sinon formatage bas niveau !
Un autre problème peut venir du cache des disques durs : ça sert plus à rien sous Linux (pas à quelques Mo de cache près), et la plupart des fabriquant désactivent l'instruction permettant de le vider pour augmenter leur perfs dans les benchs. Ça contourne le log, et le FS peut rien y faire.
Souvent y'a la ram aussi... enfin pleins de bonnes excuses. C'est vrai que XFS et reiserfs réagissent mal au hardware défaillant de manière chronique mais ils résistent en cas de plantage ponctuel.
En fait, j'ai pas assistée à des corruptions spontané de partitions sans problèmes matériels derrière depuis des versions antidéluviennes du 2.4 . En supposant que ça vous soit réellement arrivé, et de manière reproductible, il ne vous reste plus qu'à faire un rapport de bug.
Ouais, enfin, c'est assez frustrant de n'avoir jamais rencontré une seule corruption de système de fichiers sous Windows (et ce malgré les plantages de Windows 95 et Me)
Pour dire que fat32 est résistant il faut en vouloir... rien que le coup du versionning de nom par checksum sur un octet c'est rigolo... en plus il est pas journalisé, je compte plus le nombre de "scandisk à corrigé une erreur" que tout le monde zappait. Sans parler des perfs, ce truc c'est l'archétype du système conçu uniquement pour la rétrocompatibilité (avec win9x justement).
[^] # Re: C'est possible-complément
Posté par un_brice (site web personnel) . En réponse au journal Un truc qui manque à Linux. Évalué à 2.
Alors que depuis linux t'a rien à faire (sauf éventuellement rediriger un port), juste fish://IP depuis n'importe où.
Et j'en profite pour clarifier je voulais dire par là que GNU/Linux gère bien mieux SMB que windows ne gère fish, ou même ftp.
[^] # Re: C'est possible
Posté par un_brice (site web personnel) . En réponse au journal Un truc qui manque à Linux. Évalué à 5.
Ça s'appelle fish. Y'a pas besoin de configurer quoi que ce soit, juste d'avoir ssh d'installé. Et c'est très sécurisé.
Bon, ça c'est pour entre deux linux (cas de ton journal). Après, quand t'a un windows dans la partie, le moyen le plus propre c'est de configurer un partage automatique des répertoires home (ou du slash, si tu veut faire comme sous windows).
Suivant tes goûts, ça peut se faire en éditant trois lignes de codes ou en clicouillant quatre fois la où il faut (dans samba de kcontrol, tu choisi "nouveau partage" et tu demande à partager les répertoires maisons). Je doute que tu ait bien cherché pour manquer ça !
Remarque que ça pourrait être fait par défaut, mais c'est pas anodin d'un point de vue sécurité, et en fait ça en sert que quand tu est gêné par la présence d'un windows donc...
Dans mes souvenirs les outils de mandrake sont encore plus simples.
C'est un choix de la distribution, pour faire sentir que partager des donnée par samba n'est pas anodin. Ça peut se désactiver dans l'onglet qui va bien de kcontrol .
Mais de toutes manières le problème vient de windows : il ne sait pas accéder de manières transparentes aux partages par fish/ftp. "Linux" (KDE et Samba plutôt), quoi que t'en dise, s'en sortent bien mieux.
Pour tes problèmes de nomages évoqués en 2) c'est encore une fois windows qui fait mal son job, lan:// n'a aucune difficulté à présenter une vue hiérarchique des services d'un réseau.
[^] # Re: De quoi tu causes ???
Posté par un_brice (site web personnel) . En réponse au journal Nous y étions.... Évalué à 7.
http://linuxfr.org/2005/12/04/20001.html
[^] # Re: deja pris
Posté par un_brice (site web personnel) . En réponse à la dépêche Pilotes binaires dans Linux: quel est le problème ?. Évalué à 7.
Et à d'autres endroits qu'il ne liront pas les rapports de bugs fait avec d'autres compilateurs.
Alors bon, en pratique ça marche avec d'autres, mais c'est pas plus un objectif que le support des pilotes binaires.
[^] # Re: deja pris
Posté par un_brice (site web personnel) . En réponse à la dépêche Pilotes binaires dans Linux: quel est le problème ?. Évalué à 4.
C'est un fan de la FSF qui lui a ouvert les yeux.
De plus les développeurs Linux ont mis dans leurs prérequis GCC>2.95.3 et GNU Make>3.79.1.
Sur d'autres compilateurs/make les rapports de bugs sont ignorés.
C'est quand même une reconnaissance officielle.
[^] # Re: GPL v2 ou suivante
Posté par un_brice (site web personnel) . En réponse à la dépêche Définition du processus de rédaction de la GPL version 3. Évalué à 3.
[^] # Re: et avec ça...
Posté par un_brice (site web personnel) . En réponse au journal Intégration Beagle dans nautilus. Évalué à 2.
Par exemple au lieu de chercher les photos avec le mot clef "vacances" et "nièce" tu chercheras les photos que tante Mireille t'a envoyée en Août. Ça évite d'avoir à faire des annotations sur les photos (même s'il existe des outils efficaces pour en faire).
Et pour les documents textes (ou équivalents), il suffit d'indexer le contenu (prévu aussi).
[^] # Re: bof
Posté par un_brice (site web personnel) . En réponse au journal apt-build : gadget ou pas ? votre avis à vous ?!. Évalué à 2.
Et je doute très fortement que tu ait mis en place selinux sur une debian en moins d'un mois de travail intensif. Des choses, parmis tant d'autres, qui ne sont pas necessaires avec des distributions sources (et qui ne sont que des exemples).
Admettons. Il reste que j'utilise des distros sources depuis assez longtemps pour que l'attrait de la nouveauté ai fini de jouer.
Non, je voulais pouvoir utiliser Konqueror pour aller sur Gmail et les filtres KMail par imap, plus la webcam.
Pareil pour selinux, ssp, Jabber2 sur amd64... ce sont des choses qui nécessitent de compiler et qui sont utiles.
D'ailleurs il ne s'agit souvent pas de minutes mais d'années avec debian stable, et de 6 mois en testing. Et ceci à cause du lien fort qui existe entre les versions des packages utilisateurs et du coeur du système, sur toutes les distributions binaires.
Je ne vois pas ce que tu veut dire. Sur mon serveur je ne fait plus que les mises à jour réglementaires.
Non, je ne compte que le temps d'interaction avec la machine que l'opération me coute. Et ce temps est très court sous gentoo.
Le reste ne corresponds pas à un compromis que j'aurais à faire. Que ma machine compile ou se repose, c'est son problème: elle marche et ça me suffit.
[^] # Re: Et la LGPL?
Posté par un_brice (site web personnel) . En réponse à la dépêche Définition du processus de rédaction de la GPL version 3. Évalué à 3.
Y'a d'hors et déjà une boite qui fait des FS en propriétaire sous Linux (paragon software, assez connue normalement) : http://www.ntfs-linux.com/ . Et ATI qui fait des drivers.
Pas que je trouve ça bien (à priori, ce que fait paragon est illégal). Mais si ils sont dans la légalité alors on peut facilement supposer qu'un de ces composants serait légal s'il était GPL3.
Autre méthode : utiliser une double licence GPLv3/GPLv2 pour ne changer que le minimum. C'est d'autant plus faisable que des pans entier du noyeau sont sous licence GPL, "version 2 ou supérieure" (la couche IP par exemple).
L'idée c'est que pour ajouter des composants GPLv3, on n'a besoin que de convertir les interfaces et le coeur du noyau, quitte à récrire les parties correspondants aux gens qui sont morts (à priori peut nombreux).
Donc pas besoin de changer la licence des drivers (qui doivent représenter l'essentiel du code), des FS existants, peut être même des fonctions d'initialisations... Ça fait tout de suite moins herculéen. Surtout si tu compte que le coeur noyau doit être écrit par une poignée de personnes dont un bon nombre doit être encore actif.
Si (comme tu le dit) un gars aurait eu besoin de quelques années pour convertir tout le noyau, alors une dizaine de gars motivés devraient pouvoir en convertir le coeur en un an.
Et enfin, au pire, une autre possibilité serait de faire comme nVidia ou ndiswraper : une couche d'abstraction qui permettrait de produire des pilotes/filesystems portables, et la publier sous GPLv3 sur des systèmes BSD.
Ensuite intégrer sa version GPLv2 dans le noyau officiel. Dès lors les composants GPLv3 intégrés au noyau peuvent utiliser la version GPLv2 sans en dériver.
[^] # Re: Et la LGPL?
Posté par un_brice (site web personnel) . En réponse à la dépêche Définition du processus de rédaction de la GPL version 3. Évalué à 6.
Sinon l'idée d'une plus grande compatibilité est excellente, ça permetras d'unir plus de projets derrière cette licence et d'en réduire le nombre. Notement, si Linux passe en GPL3 (ce qui s'annonce difficile), on peut espérer récupérer du code de Solaris (au grand damn de celui-ci).
Une autre idée interessante et de faire qu'autoriser l'usage d'un logiciel par le biais d'une interface n'étant pas un travail dérivé de celui-ci (par exemple permetre l'accès aux fonctions d'un logiciel libre par http) nécessite que le code de ce logiciel soit distribué (la restriction qui serait optionnelle) :
http://www.newsforge.com/article.pl?sid=00/11/01/1636202&(...)
Enfin, elle pourrais prévoir le cas des brevets, et peut être même interdire l'usage de drms (utilisable pour empêcher en pratique le logiciel d'être libre) :
http://zdnet.fr/actualites/informatique/0,39040745,39260233,(...)
[^] # Re: Une question, comme ça...
Posté par un_brice (site web personnel) . En réponse à la dépêche Pilotes binaires dans Linux: quel est le problème ?. Évalué à 4.
[^] # Re: Oui, mais....
Posté par un_brice (site web personnel) . En réponse à la dépêche Pilotes binaires dans Linux: quel est le problème ?. Évalué à 5.
L'idée est que si les pilotes proprios étaient impossibles, les pilotes seraient libres, comme c'était le cas il n'y a pas si longtemps.
Et pourtant, y'a des bourrins qui y arrivent ! Ça doit être possible.
http://r300.sourceforge.net/ supporte déjà ppracer et quake3 (proprio...).
[^] # Re: trop passera pas, mais joli quand meme
Posté par un_brice (site web personnel) . En réponse au journal Un service marketing pour Linux ?. Évalué à 2.
Ça s'appelle Tenor, et c'est décrit dans une interview de son développeur : http://www.linuxplanet.com/linuxplanet/reviews/5816/1/ .
Sinon l'interface avec des trucs qui tournent et qui bougent c'est classe, mais je sais pas si c'est efficace.
En pratique, on nous montre trois machins :
Le premier permet de savoir quand est disponible tel ou telle personne pour les faire partciper ensemble à une activité. En plus le machin est censé trouver des activité interessantes... si c'est vrai c'est de la pub intégrée dans le carnet d'addresse. Youpi.
Et puis, j'ai du mal à penser réellement en ces termes les disponibilité de mes proches : c'est pas parce qu'il sont libres d'habitude qu'ils seront d'accord pour participer, ni parce qu'il sont occupé d'habitude qu'il ne viendront pas. Donc je mail les gens que je veut voir, pas ceux qui sont disponibles.
Surtout que ça suppose d'avoir collectée des informations sur la disponibilité des gens et que ces gens les tiennent à jour dans leurs ordinateurs. Quand on en est à ce stade, il faut changer d'amis.
Par contre il présente même pas la possibilité de classer les gens par groupe, autrement plus utile.
En terme de fonctions de recherche, KDE 3.4 ne sait pas grouper les gens par horaire de disponibilité, mais il sait mémoriser et tenir à jour cette information, ainsi que la localisation des gens... enfin, tout ça pour dire que c'est pas winfs qui est présenté mais juste une interface, qui n'est à priori pas prévue (la vidéo est juste un mockup).
Ensuite on nous montre un truc qui permet de classer des films par préférence. Youpi. Y'a encore des trucs qui tournent, et qui affichent de toutes petites previews au lieu du nom du film. Ergonomie == 0.
Et enfin, l'outil qu'on nous montre permet mettre en relation des personnes des dates, des photos, des personnes et des lieux. C'est pas neuf.
Et encore, il sont obligé de taper l'adresse email des personnes à la main pour leur écrire.
Et les fenêtres sont toutes penchées... c'est vraiment que de l'amuse-oeil pour client en mal de patience. Ça présente l'interêt de mettre en relation des informations dans un cas où ça n'en a pas vraiment, sans présenter quoi que ce soit de propre à winfs (tout sauf les photo est issu de l'internet), et en supposant une "application de création de fête" qui n'existeras pas, à ma connaissance.
[^] # Re: Autre chose, oui mais quoi ?
Posté par un_brice (site web personnel) . En réponse au journal Fait n°1 : Linux n'est pas sujet à la fragmentation.... Évalué à 3.
[^] # Re: bof
Posté par un_brice (site web personnel) . En réponse au journal apt-build : gadget ou pas ? votre avis à vous ?!. Évalué à 2.
Je le fait parce que ça m'amuse mais ce n'est pas une nécessité. Un "emerge sync && emerge -uvD world;etc-config" toutes les semaines suffirait (suffit à mon serveur en fait). J'estime le temps d'interaction avec la machine à dix minutes dans ce cas.
À d'autres ! J'utilise des distros sources depuis mes débuts, à peu près à la même époque que toi.
D'ailleurs je connais plus de gens qui font le passage dans le sens binaire vers source que le contraire.
Justement !
Un type qui upgrade sa glibc et/ou casse tout son arbre de dépendance (ce qui se passe à l'heure actuelle sous debian si tu installe kde 3.5) perds beaucoup plus de temps qu'un gars qui lance un "emerge kde-meta" avant d'aller se coucher.
Utiliser une distro source augmente le temps d'installation initial de la plupart des logiciels, mais réduit l'interaction nécessaire avec la machine.
Et à moyen terme, le contrecoût disparait : en cas de mise à jour tu a plus vite fait de compiler toi même que d'attendre que le mainteneur sorte son paquet (au mieux, il va aussi vite que toi à compiler, en pratique beaucoup moins). Alors c'est ton CPU qui bosse, mais avec un nice de 20 (NICENESS dans le make.conf) ça se voit même pas (sauf sur les portables).
Les miennes se portent bien, depuis quelques années déjà.
Sous gentoo, virer les dépendances à gnome me prend 16 secondes, montre en main (je viens de faire le test, il inclut la phase de login).
[^] # Re: euh.........
Posté par un_brice (site web personnel) . En réponse au journal konqueror, adblock et bfilter. Évalué à 2.
Sous gentoo, tu fait comme d'hab, avec l'ebuild récupéré sur http://kde-look.org/content/show.php?content=25927 sauf que tu remplace "need-kde 3.4" par "need-kde 3.5".
# Tant qu'on y est
Posté par un_brice (site web personnel) . En réponse au journal konqueror, adblock et bfilter. Évalué à 4.
[^] # Re: pas les seuls
Posté par un_brice (site web personnel) . En réponse au journal les francais ont-ils un QI de poule?. Évalué à 6.
Imagine : un fou te tourne autour en courant avec une balle de tennis à la main. Comme il est fou, il pense que c'est toi qui court.
À un moment il lance la balle de tennis qu'il tenait, droit devant lui.
Toi tu voir la balle prendre la tagente et suivre une jolie ligne droite, et lui il va pas comprendre (il va voir une parabole, ou shadokoïde quelconque mais pas droit).
Bon, en fait pour que ça marche sans tricher il faudra que les épaules du gars restent parallèles aux tiennes pendant sa course (donc un fou très entraîné), mais le résultat sera à peu près le même au sens où son référentiel sera pas galiléen du tout.
[^] # Re: bof
Posté par un_brice (site web personnel) . En réponse au journal apt-build : gadget ou pas ? votre avis à vous ?!. Évalué à 4.
Pour en revenir au sujet de départ, je trouve que l'interêt de compiler ses paquets est d'être libre des dépendances binaires, beaucoup plus strictes. Par exemple je peut figer (une ligne dans portage.mask) php à la version 4.1, ou passer à kde 3.5, sans que ça n'exprime des contraintes sur la version de ma glibc ou de quelque autre composant plus critique.
Autre exemple : installer xine implique d'installer des librairie de Gnome sous debian, parce que sinon les gnomistes ne pourraient pas accèder aux fonctionalités dont ils ont besoin (c'est d'autant plus dérangeant que Xine est necessaire à KDE). Sous gentoo un "useflag" (mot clef à mettre où non dans un fichier) adapte dynamiquement les dépendances aux habitudes de l'utilisateur.
De manière plus générale, ça permet de proposer à ceux qui les veulent des fonctionalités qu'on ne pourrait pas imposer à tout le monde.
(et le gain de perfs est à priori réel, par rapport à des binaires 386 - 686 je dit pas par contre)
[^] # Re: attaquer
Posté par un_brice (site web personnel) . En réponse au journal "'auteur de NVU tire à boulet rouge sur les auteurs de l'ammendement VU. Évalué à 5.
On me les a offerts pour noël, je les ai écoutés dans la voiture, nikel. En arrivant chez moi j'ai voulu les ripper en Flac pour faire une copie de sauvegarde et ça en a bousillé un avant que je comprenne. Comme il a été acheté dans une boutique à des lieu de chez moi (et pour pas faire chier celui qui me l'avait offert), j'ai été obligé de le télécharger sur edonkey.
J'ai ripé le second après un hdparm et c'est passé comme une fleur.
L'absence de labal CDAudio aurait dû attirer mon attention, mais je me suis pas méfié. Enfin... tout ça c'est pour dire que tout le monde n'a pas ta chance.
[^] # Re: Normal, c'est une feature...
Posté par un_brice (site web personnel) . En réponse au journal XFS: demain j'arrête.... Évalué à 4.
Je peut répeter le peu que je sait : beaucoup de disques durs, de cartes raid (et, parait-il, Linux à une époque) désactivent les commandes de synchronisation de cache, utilisées par des outils de benchmarks pour faire leur tests.
L'interêt c'est de forcer le bench à utiliser le cache. S'il fait ses tests sur de petits fichiers ça change tout.
Y'a un gars qui a écrit un petit programme pour vérifier si le disque obéissait :
http://www.livejournal.com/users/brad/2116715.html (le warning au début est lié à l'auteur de la news slashdot qui avait mal compris et qui croyais que le programe ne faisait intervenir que le comportement du disque)
D'après lui, un workaround pour certains disques IDE est de carrement désactiver le cache avec hdparm, mais ça marche pas systématiquement.
Le rapport avec les systèmes journalisés c'est qu'à mon avis, si le cache se vide pas, y'a (entre autre) un risque que le réordonnancement des données dans le cache par le disque dur bousille le journal si le système plante au mauvais moment.
J'ai dû lire un truc là dessus mais je sais plus où... désolé.
Ah et puis quand je dit qu'à mon avis les caches servent à rien c'est parce que Linux utilise la ram à la place, qu'il sait aussi réordonancer les écritures mais que lui il triche pas.
... j'espère ne pas avoir dit de bêtises... je retrouve pas toutes mes sources mais ça m'a l'air logique.
Sinon, si tu fait des trucs importants, tu devrais envisager d'utiliser une alimentation de secours.
[^] # Re: Komposé
Posté par un_brice (site web personnel) . En réponse au journal Je n'arrive pas à m'habituer aux bureaux virtuels.... Évalué à 2.
http://thegraveyard.org/skippy.php
Sinon, c'est un peu HS, mais pour KDE y'a aussi KXdocker qui implémente un docker à la macosx, avec tout plein de plugins rigolo (pas que je soit fan, mais c'est bien réalisé).
http://www.xiaprojects.com/www/prodotti/kxdocker/main.php?ac(...)
Vivement KDE4, que ce genre d'outils soient intégrés.
[^] # Re: Normal, c'est une feature...
Posté par un_brice (site web personnel) . En réponse au journal XFS: demain j'arrête.... Évalué à 3.
Sinon on peut effectivement imaginer que toutes les corruptions aient eu lieu sur des fichiers temporaires...
Cette notion n'a pas de sens, pour le peu que j'en sache.
Un système de fichier peut être journalisé au niveau de la structure du fs (Reiserfs, NTFS, XFS) ou des données (Ext3 mode journal). Dans ces deux cas il est tiendras en cas de chute.
À mon avis, un système de fichier "en béton" ça veut juste dire que tu n'a pas connu de problème à l'époque de ce fs, pour une raison ou une autre, par exemple que ton disque était moins vieux ou que ton grille pain n'était pas backdoré par les extra terrestres.
Ou alors, ta mémoire a des défaut subtils... quoi qu'il en soit ça ton cas particulier n'est pas ce qui m'intéresse, et j'aimerais bien que tu compare les FS sur autre chose que ton expérience personnelle.
Sinon, tu vas sur un forum et tu dit "chez moi ça marche pas". Grosso modo, y'a pas d'autres informations dans ton post.
A un moment tu dit :
Si tu perd des données sans y avoir accédé en écriture dans la minute qui précède, ou la structure des dossiers, c'est que ton matériel est défaillant, je persiste.
Et si tu veut être sûr que tes données ne seront pas corrompues en cas de crash, il existe un moyen, et un seul : le mode journal de ext3, c'est tout.
Ceci dit, je doute que microsoft ait déployé un système semblable par défaut sur ntfs, parce que c'est couteux en perf. Donc je persiste à penser que tes problème ne viennent pas du FS.
[^] # Re: Normal, c'est une feature...
Posté par un_brice (site web personnel) . En réponse au journal XFS: demain j'arrête.... Évalué à 5.
Par contre sur le PC de ma maman il a décidé récemment de faire des écrans bleus. Même le CD d'install de windows plantait, alors que la partoche était parfaitement lisible sous linux... comme quoi desfois.
Pour en revenir au sujet, je conseille au gens qui ont des pertes avec leur FS de tenter "smartctl -t long", on a souvent des surprises. Dans ce cas, activation de smart dans l'espoir qu'il réalloue les secteurs, et sinon formatage bas niveau !
Un autre problème peut venir du cache des disques durs : ça sert plus à rien sous Linux (pas à quelques Mo de cache près), et la plupart des fabriquant désactivent l'instruction permettant de le vider pour augmenter leur perfs dans les benchs. Ça contourne le log, et le FS peut rien y faire.
Souvent y'a la ram aussi... enfin pleins de bonnes excuses. C'est vrai que XFS et reiserfs réagissent mal au hardware défaillant de manière chronique mais ils résistent en cas de plantage ponctuel.
En fait, j'ai pas assistée à des corruptions spontané de partitions sans problèmes matériels derrière depuis des versions antidéluviennes du 2.4 . En supposant que ça vous soit réellement arrivé, et de manière reproductible, il ne vous reste plus qu'à faire un rapport de bug.
Pour dire que fat32 est résistant il faut en vouloir... rien que le coup du versionning de nom par checksum sur un octet c'est rigolo... en plus il est pas journalisé, je compte plus le nombre de "scandisk à corrigé une erreur" que tout le monde zappait. Sans parler des perfs, ce truc c'est l'archétype du système conçu uniquement pour la rétrocompatibilité (avec win9x justement).
[^] # Vous êtes sûr que vous avez rêvé.
Posté par un_brice (site web personnel) . En réponse au journal waah. Évalué à 3.