Larry Cow a écrit 5011 commentaires

Une extension XFace serait terrible :)

J'ai vu que des gens essayent, un peu partout dans le monde. Ca peut être sympa (sauf que pour ce que j'en ai vu, la grosse difficulté consiste à faire faire le travail d'uncompface par du javascript sans que ça prenne trois plombes, ou d'intégrer un bout de code C++ pour le faire, ce qui est tout de suite plus compliqué).

Merci à tous pour vos réponses: effectivement, grub place - dans ce cas - le disque IDE en hd1. J'aurais jamais cru ça, mais finalement c'est pas si mal. Le reste devrait rouler tout seul, à partir de là.

Par contre, par pure curiosité: qui est-ce, de grub et du bios, qui se charge d'accéder au dur USB? Le fait que grub voit USB et IDE de même manière laisserait supposer que c'est le BIOS qui 'cache' l'usb-storage derrière une interface compatible IDE, mais auquel cas quid des drivers usb-storage des OS actuels? Ils utilisent le BIOS aussi (et si c'est le cas, comment ça se fait qu'ils n'ont pas accès à des fonctionnalités bas niveau des disques IDE, comme SMART), ou bien ils outrepassent et font comme ils le sentent?

A moins qu'il n'ait voulu écrire "cette dernière tentative semble ici plus prometteuse".

(je sors)

Sûr, mais avec ce raisonnement là, tu peux déchiqueter sauvagement ton cable réseau: la vie elle est trop risquée.

Le ping est fait pour savoir si une machine est up. Si tu ne veux pas qu'on sache que ta machine est up, ça te regarde, mais si elle fournit par ailleurs un service à l'extérieur, c'est passablement ridicule, AMHA.

Ouép, mais dans la plupart des cas, un DROP va motiver une retentative (TCP oblige). Un REJECT a, lui, l'avantage de dire clairement qu'il ne s'agit pas d'un erreur, et que toute tentative de connexion est malvenue. La sécurité par l'obscurité, on sait ce que ça vaut...

Quand tu vois que certains administrateurs bloquent systématiquement les pings à destination de leur machine "parce que c'est plus securisé comme çà"...

C'est comme les gens qui privilégient le DROP au REJECT, dans iptables, sous prétexte que "ça économise la bande passante": "parce que tu comprends, comme ça je perds pas de temps à renvoyer un paquet comme quoi le port est bloqué".

Un petit tour sur les sites spécialisés, genre http://www.linux-on-laptops.com/(...) , ça peut aider pas mal.

Pour ton PC, je l'ai pas vu sur linuxonlaptops, mais il y'a d'autres Presarios qui ont l'air assez similaires, à comparer.

Il n'y a pas que la stabilité qui fait défaut: tout cela est d'une lenteur handicapante. Mais pas d'inquiétude, à priori c'est provoqué par tout l'attirail de debug.

J'avais bien compris, je soulignais juste que son test ne testait pas, finalement, ce qui faisait la spécificité de son système.

Ton idée de financement du LL (http://copos.berlios.de/donation.html(...) ) a l'air pas mal du tout. Seul détail: dans le test que tu comptes pratiquer (je te souhaite, au passage, bonne chance), comment le tiers de confiance va-t-il procéder pour "rembourser" les donateurs mécontents?

Ouai enfin scanner une machine pas à toi sans intention de nuire, faut quand même être un gros psyco :)

Perso, j'ai assez souvent affaire à des boulets^Hoptimistes qui se la jouent pirates du grand ternet sur irc, parfois allant jusqu'à me menacer de représailles sur ma machine.

On a beau se dire que ceux qui en parlent le plus en font généralement le moins, un petit nmap sur l'ip du contestataire nous en apprend souvent suffisament pour être rassuré (et, accessoirement, mort de rire).

http://unichrome.sf.net/(...) , alors, non?

Enfin je dis ça, j'ai pas encore testé sur le mien (un Aspire 1353).

Oui, et si ça te gonfle qu'il fasse payer sa version Windows, tu n'as qu'à considérer qu'il n'en fait pas.

Il offrait un plus à ses utilisateurs, très bien. Il le fait payer, on peut trouver ça moins bien, mais c'est juste.

Je reste pas d'accord: le monsieur ne fait pas de logiciel propriétaire. Il développe et publie un logiciel open-source, et fait payer la version binaire pour une plateforme "un peu spécifique" (ce que la GPL autorise complètement).

La seule chose qui pourrait être discutable, c'est les ajouts de codes destinés à "protéger" la version payante, mais j'ai tendance à considérer que ça ne nécessite pas de pendre le monsieur haut et court. En fait, le point qui me dérange le plus dans sa protection, c'est qu'il devait bien se douter qu'elle ne servirait à rien: le code source de la version "non-protégée" étant toujours diffusé.

Ceci dit, j'étais moi-même utilisateur occasionel de xchat-win32, et cette décision ne m'arrange pas spécialement. Mais il s'agit de son travail, et je me dois de la respecter (en fait, j'envisagerais même de payer la version binaire, s'il s'avérait que mon utilisation de windows devait s'amplifier dans l'avenir).

Je trouve le début de levée de bouclier contre ce monsieur un peu exagérée. Certes, c'est une mauvaise nouvelle pour ceux qui utilisaient XChat sous windows (il y en a beaucoup, ici?), et encore.

Après tout, le code-source reste disponible, et manifestement compilable sous windows (puisqu'un autre développeur propose des binaires gratuits), donc fondamentalement en GPL. Bien entendu, s'il diffusait le source de sa "protection", cela serait mieux. Mais il existe au moins un autre exemple de logiciel "libre" diffusant une version source (sous licence zlib) et une version binaire légèrement différente: le jeu Cube.

Alors d'accord, Cube est sous zlib et non GPL, les binaires de Cube sont gratuits (ils utilisent juste un protocole réseau légèrement modifié pour "garantir" des parties sans clients non-binaires)... mais l'idée de faire payer les compilations sous Windows me semble un moyen séduisant de faire rentrer de l'argent dans les caisses sans léser les utilisateurs (par rapport à Tux Racer, par exemple, le code reste GPL).

Par contre, un effet pervers pourrait être la mort d'XChat pour windows, les utilisateurs de cette version cherchant généralement à éviter le shareware mIRC.

En même temps, tu parles de Windows en temps que serveur, là. Je dis pas que ça excuse les reboots, mais en l'occurence je parlais de Windows en temps que station de travail.

J'aurais du préciser, mea culpa.

- avec linux il faut recompiler le noyau pour installer un driver
- pas de compatibilité binaire car c'est un OS libre
- Les dev Linux sont pas cool avec les utilisateurs de pwc qu'ils laissent tomber.
- etc...

Mes frères ne me sorte jamais de tels conneries !

Ca risque pas, en effet, si comme tu le dis ils sont d'indécrottables windowsiens. pBpG est un linux-user, en plus d'être employé chez Microsoft: il bénéficie donc des deux "cultures", et est certainement plus à même que toi (linuxien) ou tes frangins (windowsiens) de faire des comparaisons entre les fonctionnements respectifs de linux et windows.

Très franchement, si je limitais mes connaissances de linux à des versions datant de NT4, je n'irais pas bien loin.

Par ailleurs, le chargement à la demande sur linux 2.0, tu dois mal te souvenir: il y avait bien un support de modules, mais pour le "hotplug" c'était pour ainsi dire inexistant. Sans parler de l'ipv6 qui était plus que balbutiant (voire absent).

je (et mes frères aussi) confirme très très fort qu'il faut rebooter 50 fois le bousin à l'installation du moindre driver).

Je t'affirme (et je poste ce message depuis un windows XP, c'est dire à quel point je pousse la rigueur scientifique dans l'expérimentation) que la seule installation qui m'ait motivée un reboot était celle d'une carte vidéo, et que donc au pire un driver nécessite "50" fois moins de reboot que tu ne le prétends. Si j'étais énervé, je te taxerais même de mauvaise foi, pour l'exemple.

Plus ou moins de F. Perusse:

- Quel salaud!
- Et encore, hier il m'a appelé sur mon téléphone portable pendant que j'étais dans mon jacuzzi pour me parler de mes copropriétés...
- Et après?
- Ben rien, c'était juste pour te dire que j'avais un téléphone portable, un jacuzzi et des copropriétés.

Enfin ce que j'en dis...

Non, tu es d'une mauvaise fois infini.

Autant pour toi.

Reviens quand Windows ne demandera pas de rebooter lorsque t'installes un drivers, change de couleur de fond d'écran, etc...

Tu devrais utiliser Windows plus souvent (en fait, non, mais au moins tu pourrais critiquer sans dire de la merde). Sur 2000 ou XP, rares sont les drivers qui demandent un reboot (le seul exemple que j'ai sous le coude c'est la carte vidéo).

Ou explique nous quel est le caca dans Windows qui impose de rebooter 1000 fois plus souvent qu'avec Linux.

Très honnètement, c'est de moins en moins vrai (on pourrait même argumenter que ce n'est plus vrai du tout). En six mois d'utilisation de Windows, les seuls reboot "fréquents" sont ceux liés au besoin de remplacer un fichier utilisé par le système (ça semble très chiant à l'utilisateur linux que je suis, mais dans l'idée c'est pas plus stupide pour éviter certaines merdes).

Au final, tu as _beaucoup_ de raisons philosophiques ou morale de critiquer Windows, tu as suffisament de raisons techniques également. Alors inutile de rajouter des affirmations péremptoires non-appuyées (tautologiquement), ça donne vraiment pas une image crédible de toi (ni de la communauté, pour ceux qui sont amateurs de généralisations abusives).

J'ai jadis utilisé un "larrycow" chez sf.net, mais tu auras surement plus de succès en utilisant la redirection d'adresse de linuxfr.

On peut effectivement se poser des questions sur les dérives d'un tel système, mais par rapport aux tickets c'est un réel progrès. Contrairement à ce que tu sembles craindre, nul besoin de sortir ton portefeuille, bien au contraire: pour peu que ton badge soit dans une poche à bonne hauteur, te trémousser devant le capteur est généralement suffisant ;)

Après un an d'Imagine-R/Navigo à Paris, j'ai un mal fou à me remettre aux tickets de métro. C'est vraiment malpratique, à côté des puces.

Je n'avais pas vu que vous aviez déjà préparé un découpage en tâche sur sourceforge, mea culpa. C'est clairement une bonne idée, mais ça nécessite de s'y tenir un minimum (sinon, au mieux ça ne sert à rien, au pire ça peut arriver à freiner).

Si tu rentres à EPITA à la rentrée, et vu ton age, on peut supposer que tu es futur sup. Dans ces conditions, il serait intéressant de savoir si tu comptes présenter Nählwë comme projet libre. Si c'est le cas (et sauf précision contraire de la part des responsables pédagogiques), il serait préférable que, jusqu'à la fin de ton année, seul ton groupe travaille sur ce projet. Accepter des contributions extérieures sur un projet scolaire, dans la pratique ça peut certainement passer, mais ça reste sujet à caution. Voilà pour ça, je dis peut-être de la merde et tu as peut-être l'intention de gérer ça en parallèle de ton projet libre.

Pour la gestion de projet libre (comprendre: projet de développement de logiciel libre, hein), je dirais surtout qu'il ne faut pas mettre la charue avant les boeufs: tant que vous êtes en "petit comité", la bonne vieille page sourceforge/gna/savannah/trac et une bonne communication au sein du groupe suffit amplement. C'est d'ailleurs d'autant plus facile quand le groupe a possibilité de se voir physiquement régulièrement.

En revanche, c'est vrai que dès que le nombre de contributeurs augmente, il vaut mieux assurer une gestion de projet un peu plus fine pour éviter que le projet ne s'enlise. Par exemple, organiser des rencontres sur irc, user et abuser des mailing-lists, mettre en place une politique plus stricte de vérification des patchs avant intégration en CVS ou release (ceci étant particulièrement important si, en plus d'avoir plein de contributeurs, tu as plein d'utilisateurs lambdas, qui comprendraient mal que "leur" soft cesse de fonctionner après une mise à jour), etc.

Mais mettre en place ce genre de choses peut s'avérer un peu lourd sur un projet de peu de personnes, et le principal est à mon avis de se permettre de migrer vers des méthodologies bien strictes, mais de ne pas trop s'empoisoner la vie avec. En gros, pas tomber dans le "génie logiciel" sans nécéssité absolue, mais avoir un code suffisament bien organisé et commenté pour pouvoir y venir le cas échéant.

Un écueil à éviter, particulièrement si ceci est un projet scolaire en devenir, ne pas oublier qu'un travail de groupe est fait pour être fait par ... le groupe. Ca a l'air con, dit comme ça, mais on en a tous fait l'expérience un jour, du groupe de projet complètement déséquilibré avec un mec qui fait tout et les autres qui rament pour essayer de servir à quelque-chose. Cette situation est très courante (au moins dans les projets libres EPITA que j'ai pu voir) et particulièrement frustrante pour les deux parties: celui/ceux qui avancent ont l'impression (justifiée) de tout faire, et les autres ont passent leur temps à essayer de comprendre l'existant, et sont toujours en retard d'un wagon. Idéalement, dans ces cas-là, les "tracteurs" ont intérêt à s'arréter un temps pour racccrocher les "remorques", sinon le projet risque fort d'aller dans le mur.

D'ordre plus général, je vais enfoncer un paquet de portes ouvertes:
* toujours commencer par une bonne phase de réflexion "sur papier" et au moins partiellement en groupe. Le but est d'arriver à une spécification à peu près claire du produit, que ce soit d'un point de vue fonctionnel (le logiciel doit faire ça) que technique.
* ne pas non plus pousser la réflexion trop loin. Vient toujours un moment où les spécifications sont remplies de "à voir", "à tester", "je sais pas si ça peut marcher". Que ces intérrogations viennent du fonctionnel (relativement rare) ou de la technique, il n'y a pas cinquante manières de savoir: il faut tester. Un bout de code fait à l'arrache pour démontrer la faisabilité est généralement suffisant.
* Dès que le fonctionnel est prêt (ça devrait être la première chose disponible), commencer à réfléchir à des manières de tester le résultat. Il ne s'agit pas d'implémenter une batterie de test (pas encore), mais d'avoir une idée de ce qu'on devra trouver dans la-dite batterie de test. Parce que, en fin de projet, tu as rarement le recul nécéssaire pour établir une liste objective de points à tester.
* Dans un projet professionnel, on dit généralement que le fonctionnel ne doit pas dépendre de l'implémentation. Dans un projet à but pédagogique (que ce soit scolaire ou personnel), la chose est nettement moins évidente ;)
* Avant de commencer à coder pour de bon, prendre un peu de temps pour réflechir à la structure du projet. Des choses aussi bêtes que "les en-têtes vont dans tel répertoire, les sources dans tel autre". Mais c'est toujours suant de devoir déplacer des bouts de projet complets pour éviter la nécrose (et CVS n'aide pas vraiment ce genre de pratique, en plus).
* Essayer au maximum de coder au même endroit, géographiquement, au moins au début, et surtout si certains maitrisent mal la programmation ou les outils utilisés. Ca permet une saine émulation.
* Ne pas trop hésiter à jeter un bout de code qui sent mauvais. Même si on a passé des heures dessus, le réecrire proprement prendra généralement beaucoup moins de temps la deuxième fois, et on gagnera un temps fou par la suite.
* Toujours dans les enfonçages de portes ouvertes: user et abuser du papier ou du tableau blanc: ca aide beaucoup à éclaircir les idées, et ça peut permettre (si les gribouillis sont human-readable) de servir de base de communication.

Les points que j'ai énoncé ici sont plus du ressort de la gestion de projet en général que de la gestion de projet libre en particulier, mais un bon projet libre, particulièrement tant qu'il est géré par une petite équipe bien circonscrite, peut se gérer selon la manière générale. Les spécificités du libre, qui ne sont en outre pas une obligation, concernent la gestion des contributions externes (patchs, bug reports, etc.), qu'il sera largement temps de commencer à gérer quand vous en aurez :)

Maintenant, si je puis me permettre deux-trois commentaires sur ton projet: le sujet est intéressant, mais plutôt ambitieux (il me semble). Si tu maîtrises bien des choses comme le MIDI, ou que tu disposes de bonnes librairies pour faire le boulot à ta place, pas de problème. En revanche, dans le cas contraire, ne compte pas trop sur ton passage à EPITA pour combler tes lacunes: tu y verras des choses d'ordre beaucoup plus général, et devras travailler ces aspects par toi-même.

(bon, avec un post comme ça, je vais me facher avec les ingénieurs en génie logiciel, les pro-epita, les anti-epita, les gens-qui-n'aiment-pas-lire-des-textes-trop-longs, ... misère)

Tu n'as pas du bien lire le commentaire auquel tu répond. Croire que le libéralisme demande "plus d'Etat", c'est faire preuve d'un léger manque d'information. Le libéralisme (qui, soit dit en passant, n'est à l'heure actuelle ni prôné ni mis en oeuvre par aucun parti politique français, de droite comme de gauche) vise à coupler la liberté économique (traditionellement à droite) avec la liberté de moeurs (généralement considérée comme le fief de la gauche).

On peut être en désaccord avec cette doctrine, mais de là à la réduire à un vulgaire état policier... restons crédibles.

Je suis dans le cas numéro 2, sauf que le local technique sera sans tableau de brassage (ce sont des combles inhabités et inhabitables, dans lesquels un pc aveugle se bat déjà avec les araignées). Donc à priori, tout se fait/fera par des cables RJ45 normaux amputés à un bout pour se brancher sur une prise murale. Mais pour le switch, tout tombera comme des prises RJ classiques.