Bapt a écrit 772 commentaires

Comme dit dans le forum où tu as posté, tu as un problème de lecture sur ton CDROM, lecteur ou media.

Essaye de regraver ton iso sur un nouveau CD, si ça ne marche pas essaye avec un autre lecteur si tu en as un.

Ce n'est en aucun cas inutile, même si le projet semble avoir peu d'intérêt de prime abord, il apporte indirectement à tous les projets concerné par cette plate-forme de bénéficié de :
Correction de bug : plus une application est utilisée, compilée dans des environnements différents, plus il y a de chance de faire ressortir des bugs potentiels et donc de les corrigés : le code y gagne donc en propreté, et donc en perennité.
En portabilité.

Il est sous entendu ici qu'il s'agit d'une alternative aux autres systèmes d'exploitation libre ou pas.
les BSD ne sont pas des alternatives à Linux mais des alternatives à tout système d'exploitation.

Si tu ne veux pas d'OpenBSD, prend toi un FreeBSD ou un NetBSD, avec une carte Atheros... Le support est très bon sur ces deux OS aussi.
les derniers intel vont arriver bientôt sous FreeBSD :
http://lists.freebsd.org/pipermail/freebsd-mobile/2006-July/(...)

Apparemment je n'ai pas besoin de "reverse enginnerer" unrar, p7zip http://p7zip.sourceforge.net/ semble gérer toutes les version du format rar pour la décompressoin
Je teste ça ce soir :)

Je ne compte pas recréer l'algorithme de compression RAR, mais celui de décompression.

Donc au delà du côté légal ou non selon les pays, il ne parle pas de comment refaire un unrar.

Je vais regarde de plus près ce projet, ça m'a l'air intéressant.

Pour limiter le nombre de scripts pourquoi ne pas utiliser libarchive et bsdtar. Il détecte le format de fichier et gère les format suivant pour le décompression :
- tar
- tar.gz
- tar.bz2
- tar.Z
- cpio
- cpio.gz
- cpio.bz2
- cpio.Z
- zip
- iso (iso9660)

donc pour la décompression : une commande unique : tar xf :) et pour lister tar tf quelque soit le format supporté :)

plus d'info ici : http://people.freebsd.org/~kientzle/libarchive/
liste des formats supportés : http://people.freebsd.org/~kientzle/libarchive/libarchive-fo(...)

pour l'autodétection du format de compression du tar : gz ou bz2 ou rien, je crois que les derniers gnu tar le font aussi.

bsdtar est disponible chez tout les bon revendeurs :
tous les bsd récents :)
debian à partir de testing :
http://packages.debian.org/cgi-bin/search_packages.pl?keywor(...)
gentoo : http://packages.gentoo.org/search/?sstring=bsdtar
Pour les autres, je vous laisse chercher.

Avant d'affirmer qu'un projet info est mort, il y a deux choses a vérifier : l'activité des ML et l'activité du CVS/SVN/gestionnaire de source.
en 1 clique tu vois qu'ils sont vivant : "browse source" : dernier commit : 1 semaine.
en 3 clique tu vois ce qu'il ont fait : "browse source" -> "trunk" -> "Changelog"
http://diva-project.org/browser/trunk/ChangeLog?rev=314

Pour HP, linux ne concurence absoluement pas HP-UX, étant donné que HP ne supporte pas officiellement linux sur les architectures sur lesquelles tourne HPUX, donc pas de concurence à ce niveau là, maintenant les clients demandent du linux sur la gamme x86 d'HP, donc HP le fournit : suse et rhel jusque là, Debian aujourd'hui.

Au vue de ce que dit benny :

The most interesting pending feature here is network support for Thunar, which will include atleast browsing Samba shares and connecting Samba shares (and probably other network file services as well) via smbfs or FUSE.

Je pense qu'il va pas se faire chier pour le smb et utiliser un montage smbfs ou fuse.

L'idéal serait d'utiliser fuse avec smbfs et/ou smbnetfs, il ne resterait plus qu'a coder un frontend à fusermount :)

J'adore ces phrases des gens comme moi qui disent aux devs : "mais c'est rien il ne reste qu'à coder ça ..." :)

Moi quand je regarde l'anonce d'intel, je vois bien Keith Packard parmi les développeurs,
quand je regarde http://en.wikipedia.org/wiki/Keith_Packard (la page française n'est pas à jour), il bosse chez Intel depuis ... août 2006 :)

Soit je n'ai pas tout compris à ton post, soit :
PA-RISC et Itanium sont deux architecture différentes. Et oui j'ai vue beaucoup de machines avec des processeurs Itanium, en général plusieurs proco dans la même machine. Mais HP abandonne peu à peu l'itanium pour conserver le PA-RISC pour les serveurs HPUX.
Intel n'a rien avoir me semble-t-il avec les processeurs PA-RISC.

Pour pousser dans le sens de ton post, chez Intel il y a :

Eric Anholt :
- développeur dri (radeon, intel)
- développeur Xorg
- mainteneur des paquets X chez FreeBSD

Keith Packard :
Qui a fait beaucoup parlé de lui lors du fork xorg/Xfree, et c'est de lui que sont venus beaucoup de modernisation de Xorg.

Ces deux là ne sont pas de simple développeurs Intel, ils participent profondément à Xorg, et depuis un moment, et y compris dans des domaines qui sont concurent à Intel, Eric Anholt travaillant par exemple sur les dri/drm Intel et dri/drm libre ATI.

J'ai envoyé un mail à vendorwatch.org pour voir si ça les intéresse d'étendre les fonctionnalité de leur avec ce projet, j'attend la réponse de leur part, je vous tiens au courrant.

Je suis d'accord avec toi, mais comme je le dis avant je ne pense pas être assez qualifié pour avoir des résultats concrets. En revanche, si personne de plus qualifié ne veux pas prendre les rennes, je le ferais, tout du moins j'essairai, mais il me semble important de pouvoir présenter les informartions techniques de manières propres et précise. si je le fait c'est comme si une secrétaire faisait un diagramme UML, il y aura peut être toutes les informations, mais se sera certainement inutilisable par les développeurs car non fait dans les règles de l'art.

Je ne me défile pas pour le projet, je veux (et c'est pour ça que je le présente) le réaliser, mais dans la mesure de mes compétences. Il est important si on ne veut pas faire un projet mort né de s'entourrer des personnes compétentes. De plus il ne s'agit pas là d'un projet de dev, ou je peux pondre un code pas propre mais qui fonctionne, qui attire des gens, et que j'apprenne au fur et a mesure à codé propre grâce au projet. Là si les informations présentées sont inutilisables, personne ne pourra s'en servir. En revanche si quelqu'un de compétent le fait, je serai à même d'apprendre et à en faire d'autres propres, donc utiles.

Merci pour la proposition, je m'en occuperait bien, mais pour plusieurs raisons, je ne pense pas être le mieux placé :
- Je n'y connais rien (pour le moment ?) en développement de driver.
- Je n'y connais rien (pour le moment ?) en Hardware et encore moins en spécification harware.
- Je n'ai pas de site sur lequel l'héberger.
- Enfin et surtout, j'aimerai bien savoir la légalité de la chose avant de me lancé la dedans.

En ce qui concerne le fait de ne rien y connaitre en hardware et spec hardware, c'est à mon avis très génant pour ce lancer dans l'aventure, car je pense (peut être à tord) que la présentation et la lisibilité des specs est un point important pour que le projet soit réellement utilisé et utilisable. De plus il faut savoir un minimum de quoi on parle. Il s'agit là d'un réflection de quelqu'un (moi) qui n'a aucune idée de ce que peut être le développement de drivers, j'ai juste des infos vulgarisés sur le domaine, mais certainement beaucoup trop vulgarisé (comprendre plein de non sens, idées reçues), et les éléments majeurs d'un tel projets devraient selon moi auvoir une certaine crédibilité auprès des dev kernel pour les motiver à participer un peu plus.

Secondo, comme précisé plus haut, il serait peut être intéressant de contacter vendorwatch pour héberger ce projet.

En revanche ce que je peux faire, c'est aidé si quelqu'un se lance là dedans : essayé de récupérer les specs déjà disponible en ligne pour les centralisées, contacté les développeurs kernel des divers projets d'OS OpenSource : Linux, Hurd, FreeBSD, NetBSD, OpenBSD, DragonFly-BSD, Reactos, et tous les autres que j'oublie là mais que j'aurais vite fait de répertorié à se moment là pour les motiver à contribuer.

En clair je n'ai pas de pétrole, mais des idées et je pense que c'est un bon point de départ.

En même temps, c'est un reproche que l'on peut aux développeurs linux, même si le plus important et on les remercies pour ça c'est de codé des drivers, mais sous FreeBSD par exemple, tous les drivers sont systématiquement accompagnés d'un manpage.

C'est très pratique pour connaitre le matériel supporté : et comment utiliser le driver : http://www.freebsd.org/cgi/man.cgi?query=axe&apropos=0&a(...) par exemple à partir de là j'ai acheté mon adaptateur usb/ethernet sans me poser de question.

Des ajouts sont régulièrement fait au niveau compatibilité du matériel : les scanners usb sont un bon exemple, la chaine d'identification du scanner est rajoutée au driver, et le nom du scanner rajouté au manpage :
http://www.freebsd.org/cgi/man.cgi?query=uscanner&apropo(...)

Très pratique.
Ca ne prend pas beaucoup de temps au dev et ça change la vie des utilisateurs.

De la même manière les interfaces dans le kernel sont documentées pour facilité la vie des développeurs, au sein de manpages, par exemple :
http://www.freebsd.org/cgi/man.cgi?query=usb&sektion=4&a(...)

Un peu de documentation ça ne fait de mal (c'est chiant et rébarbatif), mais c'est important.

Pour revenir au sujet :
Si le mainteneur du driver vient à changé pour des raisons diverses, le suivant sera bien content de trouver les specs, pour pouvoir améliorer le driver, le dev initial a peut être fait un driver qui marche, mais il n'est pas forcément optimum, et du code cochon n'est pas facile à lire, il peut aussi s'être trompé en implémentant certaines parties des spécifications. Bref le code ne reflète pas forcément correctement, ni proprement les specs.

Moi je ne parlais pas de faciliter d'installation (je m'en fou de la phase installation) mais de faciliter d'administration

Oui autant utiliser leur site si ils le veulent bien. reste le problème de la légalité de publier des specs obtenues par reverse engineering

Oui mais la difficulté est à mon avis plus importante que partir de specs, car legalement un hacker BSD ne peut le faire que si il lit le code du driver GPL pour se faire une idée de comment le matos fonctionne => faire des specs, puis il doit "l'oublier" pour coder en fonction des specs obtenues donc on gagne une étape.
Mais là je suis d'accord que le hacker linux n'aura pas envie de se faire chier a faire des specs qui ne lui resserviront pas.
En revanche, les architectures kernel sont très différentes entre les différents OS libre, par exemple (je n'y connais rien en hack kernel c'est ce que j'ai cru comprendre, merci de me corriger si j'ai tord :)) les hackers linux sont assez libres pour le devs de drivers réseaux et l'architecture de leur driver, sous les BSD, ce n'est pas la cas, tous les drivers en tout cas sous OpenBSD reprennent la même architecture, imposée par le kernel pour facilité la maintenance et le développement. Cette architecture n'est pas forcément compatible avec celle de linux donc un hacker linux aura certainement beaucoup de difficulté à rééutiliser un driver BSD, d'ailleur il n'y a pas à ma connaissance beaucoup de repompe de code BSD sous linux ces derniers temps en ce qui concerne les drivers.

De plus, par reverse engineering un hacker arrivera a retrouver les specs mais pas toujours de manière complète, elles lui permetteront de faire un driver fonctionnel, mais peut être pas un driver ayant toutes les fonctionnalités offerte par le matos, et un autre hacker d'un autre kernel aura peux être d'autre partie de ces specs, et les complètera, permettant au premier d'enrichir son driver.

De plus, il y a peut être plein de gens qui savent faire du reverse engineering sur du matériel, et donc pondre des specs sans pour autant savoir (avoir envie de) coder des drivers : apparemment l'équipe des drivers broadcom linux fonctionne séparément (comme dit plus haut) avec des spécificateurs et des codeurs. Ca pourrait pas mal faire avancé les choses, moins de reverse pour les hackers, plus de specs.

Enfin a long terme ça peut peut être pousser les constructeurs à déposer leurs specs eux-même sur un tel site (je rêve peut être un peu là :)).

Merci.

Thunderbird + Lightning, c'était la solution utilisée avant Kubuntu, mais quitte à utiliser kubuntu autant utiliser au maximum les outils fournis par KDE, non ? on a déjà viré konqueror pour FF. Alors on a essayé de pousser avec kontact se disant qu'il faillait juste le prendre en main, et qu'il devait avoir toutes les fonctionnalités voulues.

Pour info la machine est sous kubuntu depuis 2 mois, je n'ai pas écrit un journal le lendemain de l'install, on l'a laissé vivre (la distrib) un peu, le temps de s'habituer.

Puis je trouve ça limite pitoyable cette façon qu'ont les mecs de dire :
- "j'ai pris ça pour ma nana car c'est assez simple pour elle".

Je n'ai absolument pas dit ça. Elle a choisit KDE après avoir vue les démos, et screenshot, elle ne voulait pas de gnome car pas beau et préférait avoir plein d'option de configuration possible.

En revanche, elle a juste envie de se servir de son PC et recherche une distrib facile d'accès pas parce qu'elle n'est pas capable de recompilé un noyau ou de jouer avec un BSD (elle en est largement capable), mais parcequ'elle n'en a pas envie. Je n'ai pas choisit pour elle, on a choisit, et j'ai fait l'install parce qu'elle s'en fout et qu'elle n'a pas envie de la faire.

Elle sait largement se débrouiller en informatique, et utilise facilement mes PCs Gentoo et FreeBSD, mais n'a pas envie de passer du temps à installer sa machine et encore moins à l'administrer; elle veut juste l'utiliser.

C'est dingue les généralisation comme ça : ce n'est pas parce que j'écris un journal sur l'installation d'un linux sur le PC de ma copine que je suis un mysogine torsionnaire qui ne laisse rien faire à sa moitié sous prétexte que c'est un fille !!! Faut pas déconner.

Je fais un post pour répondre (essayer) à tout le monde :

1/ C'est sûr que j'ai été un peu fort dans mes mots (je m'en excuse) :
"nul. saloperie. kernel foireux. paquet à la con. copie complète à revoir."
Mais je ne faisais que traduire mon sentiment face à la distrib, et non cracher sur le travail accomplit.

2/Concernant Kmail ma nana l'a trouvé pas pratique du tout, elle voulait une solution de mail intégré avec un calendrier, ayant entendu les échos sur kontact, et les éloges sur ce dernier, je me suis dit tant qu'a utiliser kde, autant l'utiliser, puisque au niveau fonctionnalité il fait la même chose qu'un evolution... Mais l'ergonomie générale ne lui a pas plu (à moi non plus). Ok il n'est pas « nul » c'était un peu fort, mais tout simplement inutilisable pour nos besoins. Et non ce n'est pas juste pour cette fonctionnalité (le html), mais pour un ensemble de chose : calendrier, mail, carnet d'adresse, cette fonctionnalité est la dernière en date qui nous a manqué, et c'est pour ça que je l'ai mise en avant (la plus fraîche quoi). Sinon je sais que le « problème » de kmail concernera toutes les distrib.

3/ Concernant le HTML dans les mails, je ne suis pas pour non plus, j'utilise sylpheed pour lire et envoyer mes mails sur mes machines perso, et je ne crois pas qu'il fasse de html, en tout cas n'est pas configuré pour chez moi, et c'est volontaire. Mais pour envoyer certains mails (faire part) elle aurait voulu que ce soit beau (et moi aussi pour le coup) et kmail n'a pas permis de faire ce que l'on voulait : une image en background d'un mail html.

4/ J'ai mis firefox car konqueror affichait pas certains site où elle se connecte contrairement à firefox, certainement de la faute des webmaster et non de konqueror, mais bon comme je l'ai dit dans le journal, elle veux juste un machine qui fonctionne et lui permette de faire ce qu'elle veut avec => firefox, flash c'est pour les jeux. Dans la lignée j'aurai pu installé thunderbird, mais ça faisait beaucoup.

5/ La liste des griefs énoncés n'est pas exhaustive sur Kubuntu, il y en a plein d'autre (adept très bien, mais pas assez complet, un bug avec le pointeur de souris chez moi etc.). Pour remettre les choses dans leur contexte, je voulais un distrib « prête pour le desktop out of box » un peu de config au départ n'aurait pas été gênant, mais là c'est un peu trop. J'ai suivit bêtement les échos positifs à propos de Ubuntu (facile d'utilisation, puissante et tout ça) je sais qu'un linux reste un linux quelque soit la distrib, mais le travail d'intégration qui permet à une distrib d'être facile d'accès n'est visiblement pas encore au point, j'ai du régulièrement sortir un term, et faire du vi ce qui ne me dérange pas, mais ma nana oui car elle veut pouvoir se débrouillé dessus seule une fois installé, ce qui n'est pas le cas.

6/ Le coup du kernel, j'avoue que je n'est pas cherché, car pour moi ce n'est vraiment pas sérieux, il s'agit du même kernel, même version upstream, je ne vois pas pourquoi il ne fonctionnerait pas - en regardant de près je trouverais certainement, mais pour la nième fois je voulais un distrib qui fonctionne out-of-box.

7/ 1G 256 Mo de ram ça paraît un peu lourd, mais j'ai mis toutes les barettes de SDRAM dispo chez moi puisqu'il s'agit de ma dernière machine en SD. De toute façon ça ne peut pas faire de mal.

8/ Pour firefox + flash, je ne me plein pas à flash, car sur une machine équivalente au boulot, mais sur un autre OS : FreeBSD, j'ai firefox + flash avec l'emulation linux et ça ne râme pas autant.

9/ Pour la version c'est bien un 6.06 LTS...

J'ai surtout fait ce journal, car comme le dit Marc Poiroud plus haut, Kubuntu se veut grand public, et c'est pour ça que je l'ai choisi, or le résultat n'est pas du tout (pas encore ? ?) à la hauteur de mes espérances. Je connais suffisamment linux pour savoir la quantité de travail derrière un Kubuntu et je tire quand même mon chapeau aux développeurs, mais je passe mon chemin. J'aurai pu faire des bug report et autre (je le fait pour d'autres distrib), mais il me fallait une ditrib "Facile d'accès" qui fonctionne globalement et pas qui risque de faire un freeze à chaque mise à jour qui ne sont en théorie que des mises à jours de correction de bug et de sécurité.

Le projet gtk-webcore est mort, en revanche le portage de webkit est en cours, et est compilable et presque fonctionnel :
Testé sous directfb ici : http://mail.directfb.org/pipermail/directfb-dev/2006-July/00(...)
ici des infos pour le compiler sous linux : http://wiki.opendarwin.org/index.php/WebKit:Building_On_Linu(...)
Mike Emmel en est le porteur principal.
J'ai hâte de voir apparaître des navigateur gtk légers :)