Croconux a écrit 1196 commentaires

L'argument de Free (qu'ils soit juste ou pas) est qu'ils ne louent pas la Freebox (elle est prétée)

Un peu bancal comme argument. On te la prète à condition que tu t'abonnes à leur service. C'est de la location. C'est comme dire que Windows est gratuit parce qu'il est préinstallé sur une machine. Il n'est pas gratuit, c'est compris dans le prix.

Tout ça me fait penser à toutes ces pubs où on abuse du terme "gratuit" : "Le 4e amortisseur gratuit". Bah non il n'est pas gratuit puiqu'il faut acheter les 3 autres. C'est -25% sur le lot de 4. Rien n'est gratuit dans l'histoire s'il y a une obligation d'achat.

images ce que ça donne si glib pango gtk+ gnomelib est dans la même librairie.

Ca n'a pas besoin d'être dans la même bibliothèque mais personellement je regrouperais gtk et pango.

Glib fourni des services de base (string, etc). c'est normal que ce soit séparé du reste. Gnomelib fourni tout ce qui permet l'intégration d'un programme dans Gnome. C'est aussi normal que ce soit une surcouche de Gtk.

Gtk, lui, fourni toutes les classes graphiques. Sauf que si je veux gérer les caractères étendus (langues asiatiques), bah là il me faut un machin en plus qui s'appelle pango. Même chose pour Gdk : Je fait un GUI j'utilise les Gtk_machin sauf que pour certaines choses il me faut utiliser les objets Gdk_machin.

Je ne vois que 3 couche dans tout ça : Une couche de base (Glib), une couche graphique non lié à un environnement de bureau particulier (Gtk), et une couche d'intégration à Gnome (Gnomelib). D'un coup ça devient plus simple que les whatmille librairies.

En meme temps le monsieur utilise Kde, c'est peut etre un trolleur de premiere :)

Pour avoir compilé un Gnome entier sur une LFS je confirme que c'est l'horreur pour les dépendances. Alors je veux bien croire Pat. La technique de base est "je tente de compiler dans un certain ordre et si le configure me gueule dessus je compile le truc qui lui manque".

KDE n'est pas forcément super évident à compiler la première fois mais au moins on ne change pas les dépendances ni l'ordre dans lequel il faut tout compiler à chaque version. C'est ce que dit Pat. Il s'est fait chier une fois à faire des scripts pour faire ses paquets et à chaque sortie de version il lance son script et youpla ça roule. Avec Gnome il y a de subtiles changements qui deviennent vite énervant. Vouloir faire modulaire c'est bien mais il faut choisir correctement où on coupe les morceaux. Si on fait un truc modulaire mais que tous les modules dépendent les uns des autres dans un ordre aléatoire c'est qu'on a pas coupé au bon endroit.

Bon, si c'est vrai, ca sera marrant de voir comment il va réagir quand kde 4 va arriver avec Hal + dbus :)

Si on choisi correctement ses interfaces on se contrefout de savoir ce qu'il y a en dessous. tout ce qui change c'est la couche basse qui doit cacher ce genre de détails à tout le reste du sytème.

Par exemple, j'aurais aimé que Mandrake me sorte une distrib full OpenLDAP avec des outils d'admin developpés en interne pour faciliter l'exploit.

Peut être parce que ça concerne des entreprises qui ont les moyens de payer. Les services qux entreprises sont une source de revenus non négligeable. C'est d'ailleurs l'un des business models du libre. S'ils fournissent tout ce dont les entreprises ont besoin de base comment vont-ils vivre? Déjà qu'on voit des boites (qui ont quand même les moyens d'acheter un powerpack) installer des versions download faut pas pousser.

a quoi correspondent ces brevets dans Java ?

A un tas de choses. Si je ne m'abuse le deuxième brevet couvre aussi tous les systèmes de composants distribués (DCOM, Corba). Je ne crois pas que Kodak ait été le premier a y penser. Il doit y avoir une foule d'antécédents. La lecture de ces brevets m'inspire plusieurs remarques :

- Comment peut-on accepter des brevets aussi vagues? Je pense que les gens qui trainent sur DLFP ne sont pas des tanches en informatique et pourtant même à plusieurs on a du mal à cerner ce que couvrent vraiment ces brevets. C'est du n'importe quoi. Ca vous dit qu'on se cotise pour breveter "la communication entre deux ordinateur"? Après on raquète tout le monde et on s'installe au soleil.

- Y a-t-il des gens un tant soit peut techniques dans les bureaux des brevets? J'ai l'impression que pour rédiger un brevet le but est d'en faire une description suffisament fumeuse (aka. marketing bullshit) pour embrouiller le pauvre gus qui va la valider (qui n'y connait pas grand chose) et faire croire qu'il y a quelque chose d'innovant la dedans.

http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs(...)

Q: What legal issues come up if I use GPL-incompatible libraries with GPL software?

If the libraries that you link with fall within the following exception in the GPL:

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them. Thus, if the libraries you need come with major parts of a proprietary operating system, the GPL says people can link your program with them without any conditions.

A priori, ça doit être plus véloce qu'une 7200 (moins sûr pour la 8500).

La 9200 est une version massacrée de la 8500 (underclockée de 250 à 166 MHz si mes souvenirs sont exacts). Donc effectivement c'est moins bien qu'une 8500 mais ça ne chauffe pas. Impecable quand on ne joue pas trop. J'en ai une aussi.

En revanche, les résultats qu'ils obtiennent avec la 7200 sont surprenants... moi j'obtiens 575 au glxgears...

575 avec un 9200? Tu doit être en rendu logiciel. Avec ma 9200 je suis à 1500 (à comparer avec les 2500 qu'ils obtiennent avec une 8500, on voit bien le sabotage effectué).

Bon ensuite comme je ne suis pas joueur, la 9200 répond 100% à mon besoin :
Idem. De mon côté j'attends beaucoup des cartes à base de XGI Volari V3 : Perfs correctes, refroidie en passif, sortie HDTV. Sachant que SiS a fourni aux devs les docs pour leurs anciennes cartes (Xabre) pour a peu près tout - y compris la sortie TV - ça laisse présager de bonnes choses pour les Volari.

Au premier abord, on a l'impression que tu passes à Debian pour dire que tu es sous Debian et ne plus subir la "honte" de dire : "J'utilise Mandrake".

Qu'est-ce que tu en sais? J'ai l'impression qu'il veut juste tester ce qui se fait ailleurs. Pourquoi devrait-on rester scotché à vie sur sa première distro? On teste, on joue avec et quand on a trouvé une distro qui va bien on l'adopte. Ca me parait logique comme comportement, non?

avec ma GeForce 6800 GT 256 Mo toute neuve, un P4 3.3 GHz et 2 Go de Ram, je n'arrive qu'a 41 images/s en 1600x1200

Rien que ça, ça ne me donne pas envie d'y jouer. Le jeu est fourni avec une centrale nucléaire de poche pour alimenter le tout et une petit bidon d'azone liquide pour refroidir?

Et part le "ah c'est beau" le jeu vaut quelque chose ? Parce qu'un jeu c'est avant tout pour jouer, ce n'est pas une demo. Si le gameplay est identique à ce qui existe je ne vois pas trop l'intéret.

(Ca va surement moinsser mais honnêtement ce genre de jeu qui nécessite un matos de folie et pas innovant pour 2c me laisse complètement froid)

Allez hop - - - -> []

je vais tourner des players multimedia
Muine je suppose?

un IDE
Monodevelop?

Pas étonnant ces logiciels ont été conçu pour Mono et servent de vitrine technologique. On peut dire la même chose pour Java. Les logiciels qui ont été conçus en n'utilisant que ce qui implémenté dans classpath tournent impecablement.

et si t'es chaud NetBeans / Eclipse)) ?
La comparaison n'est pas très fair play. Essaie de faire tourner une applic conçue pour le framework de MS sur Mono, genre une appli de MS. Tu as le même problème.

Java propose de réinventer la roue pour qu'elle soit portable, alors que .NET propose de ne pas perdre du temps et réutiliser l'existant.
C'est clair qu'au lieu de faire du code portable on devrait tous se mettre à coder pour windows et utiliser Wine. Quel progrès.

Ils sont pas plus en retard sur la réimplementation de ce que je vais appeler le "Framework" que ce que l'est Mono.

Mono s'est concentré sur l'implémentation de ce qui figure dans la norme ECMA (c'est à dire les bases). Du coup ils peuvent facilement sauter comme des cabris en disant "ça y est on a fini". C'est un peu facile. Côté java, les packages de base aussi ont été réimplémentés.
Il me semble qu'au niveau status c'est kifkif.

il n'y a pas de solution autre que celle de Sun qui soit fonctionnelle sans avoir quelques années de retard

Et en quoi est-ce différent pour DotNet? Prend un programme fait avec le framework .net de MS et essaie de le faire tourner sur Mono. Tu aura s les mêmes problèmes. Si le programme en question utilise des classes non présentes dans Mono (using Microsoft.DirectX ?) c'est cuit.

La situation pour Mono est même moins avantageuse que pour Java car .net facilite l'utilisation de bibliothèques natives depuis du code alors que pour Java c'est très fortement déconseillé. Si une appli utilise une DLL native dont le nom commence par MSqqchose je pense que tu aura quelques difficultés à la faire tourner sur autre chose que windows.

une implémentation complète

Ca n'est pas vraiment le cas. Seuls les namespaces de base sont implémentés. Pour le reste on repassera. Du côté des implémentations libres de java on a un peu plus de choses de dispo.
De toutes façons microsoft enrichira au fur et à mesure le framework. Mono aura toujours un train de retard sur le framework MS, idem pour java vs classpath.

performante

Euh... tu as fait joujou avec Mono? Les performances du JIT sont loin d'être fabuleuses pour le moment. Ce n'était pas la priorité des devs jusqu'à présent.

Tout ça pour dire que je ne comprends pas l'engouement subit pour Mono et surtout le Java-bashing qui l'accompagne. Toutes les avantages que l'on trouve à Mono sont aussi valables pour les implémentation libres de Java, de même que les inconvénients.

Le problème c'est que ça implique un nivellement par le bas

Pas forcément. On peut envisager un système modulaire façon X11 ou OpenGL constitué d'un noyau de fonctionnalités de bases plus des extentions. Quand on a besoin d'une extention, on teste si elle est disponible ou pas. Comme ça peut tirer le meilleur parti de chaque toolkit.

alors qu'un grand nombre d'argument de Sun visait auparavant à discréditer ces mêmes concept

En créant Java, les devs de Sun on voulu créé un langage simple à apprendre et débarassé des fonctionnalités dont l'utilisation complexe et souvent mal maitrisée conduit souvent dans le mur (heritage multiple, surcharges d'opérateurs).

Il se trouve que dans le monde merveilleux du logiciel certains sont fans des goodies qui pimentent la vie. Sun a trainé les pieds mais ils ont fini par plier.

je me demande ce que le libre a gagné dans cette affaire

Je ne vois pas comment le libre pourrait gagner quelque chose avec des drivers fermés. Le libre, ATi s'en contre branle. Ils veulent juste faire acte de présence sur le marché Linux et ne pas laisser le champ libre à NVidia.

J'ai deux cartes ATi sur mes machines mais leurs drivers ne m'intéressent pas. Je préfère qu'ils contribuent aux drivers DRI en fournissant les infos nécessaires. C'est quand même allucinant qu'on puisse vendre du matos sans le mode d'emploi. Imagine si on te vendait un magnetoscope sur lequel il y a une grande serie de boutons sans nom sur la façade mais aucune légende sur leur utilisation et fourni avec un gus qui va effectuer les opérations que tu veux à la demande (en s'arrangeant bien pour que tu ne voit pas ce qu'il tape).

mais conserve une compatibilitée descendante au niveau du code

A lire à ce sujet les deux articles d'Arstechinica sur l'historique de l'architecture x86 :

http://arstechnica.com/cpu/004/pentium-1/pentium-1-1.html(...)
http://arstechnica.com/cpu/004/pentium-2/pentium-2-1.html(...)

Pour en rajouter sur l'héritage pesant :
Intel estimated that a whopping 30% of the Pentium's transistors were dedicated solely to providing x86 legacy support

Un tiers du processeur c'est assez énorme. Heureusement ça a diminué par la suite (le besoin de compatibilité avec le code 16 bits aussi).

Est-ce que quelqu'un sait s'il existe une jvm libre (et le javac qui va avec) qui implémente les nouvelles fonctionnalités (génériques, toussa) ?

J'ai cherché du côté de Kaffe et SableVm mais aucune annonce sur un éventuel support. Ils semblent plus s'intéresser à l'amélioration de l'existant.

Il arrive assez souvent de voir des gens distribuer du code sous une license sans en saisir les subtilités. Quand il s'agit de geeks qui ne sont pas juristes ça peut se comprendre. Lorsqu'il s'agit d'une boite ça devient franchement rigolo.

Récemment je suis tombé sur le site de Scitech qui développe des drivers (pas libres) pour X. A ma grande surprise ils proposent la bibliothèque à la base de leur drivers sous double license LGPL/proprio. Ca m'a surpris car quel est l'intérêt de la version proprio puisqu'on peut utiliser lier un programme proprio sur une bibliothèque LGPL? Ils expliquent que pour les développement commerciaux il faut passer par la license proprio. Il me semble qu'ils ont un peu lu de travers la LGPL. Le juriste de service va avoir très mal aux fesses le jour ou une boite va utiliser leur produit en version LGPL et leur faire remarquer qu'ils en ont le droit.

Peut être ça les fera réfléchir avant de déposer des brevets bidons.

Et pourquoi ça? Déposer un brevet ça ne coûte pas grand chose pour une boite et ça peut rapporter gros. Ce jugement ne va rien changer. Les "gros" du secteur vont continuer à nous inonder de brevets bidons parce que même si seulement un sur dix est déclaré valide il suffit à rentabiliser l'investissement.

N'importe quelle HP, Canon ou Epson pas trop recente et pas trop compliquée .

Canon??? C'est l'un des rares constructeurs pour lesquels il n'y a à peu près aucun driver Linux à part pour des antiquités qu'on ne trouve plus dans le commerce. Avec HP et Epson, il n'y a pas trop de problème mais Canon c'est définitivement du Windows only.

Ca m'a tout l'air d'être un WinModem, modem où l'OS fait tout le boulot à la charge du CPU à condition que l'OS soit Microsoft (TM) Windows (R).
cf http://freewebhosting.hostdepartment.com/g/gromitkc/winmodem.html(...)

Il se peut qu'il soit malgré tout supporté sous Linux (Linmodem)
Pour savoir si ton modem est supporté un 'lspci -v' te permettra de trouver le type exact du chipset. A comparer avec la base de connaissance des chipset supportés:
http://freewebhosting.hostdepartment.com/g/gromitkc/dips/roster.htm(...)

S'il est supporté la marche à suivre se trouve là:
http://walbran.org/sean/linux/linmodem-howto.html(...)

Ca m'a l'air d'être ça :
http://www.ussg.iu.edu/hypermail/linux/kernel/0406.1/1496.html(...)

Des cas de oopses lors de phases de forte charge mémoire ont été reportés. Ca peut venir de plusieurs chose:
- barrette de ram foireuse mais si ça marchait bien avant il n'y a pas de raison (un test de tes barettes peut permettre de lever le doute).
- un bug dans l'allocation de pages mémoire.

La deuxième possibilité a l'air d'être la bonne. Un problème a été identifié à ce sujet. Si une tentative d'allocation de page échoue, ça peut partir en oops. Un patch a été proposé mais pas encore inclus à ma connaissance :
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/1846.html(...)

Voilà j'espère que ça pourra te dépanner.

Tu utilises quel noyau? Patché ou pas? Est-ce que tu as du matos "exotique"? Si ça part en kernel panic je pencherais pour un problème matériel/driver qui part en vrille.

Je n'ai rien trouvé d'anormal dans les logs (syslog, dmesg, xfree86)
Et dans kern.log? Pas de "kernel panic" ou de "Oops"?