Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
aide





[ Précédent :: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 :: Suivant ]

protection: contre-attaque ET engagement de non agression mutuelle

Posté par herodiade () le 13/11/2005 à 16:19. (lien). Évalué à 10.

La news explique très justement que ce pool de brevet peut servir d'arme pour contre attaquer.
C'est un point interessant. Mais il y a quelque chose de beaucoup plus fascinant (et aussi moins polémique je crois, "la fin justifie-t-elle les moyens ? etc."), c'est que tout les adhérents sont aussi protégés par le simple fait qu'ils se sont engagés à ne pas s'entre-attaquer !

Le texte indique (traduit vite fait):


"Les brevets détenus par Open INvention Network seront disponibles gracieusement (sans frais) pour toute compagnie, institution ou individu qui accepte de ne pas utiliser les brevets dont il dispose contre le systeme d'exploitation Linux ou certaines applications en relation avec Linux".


Et je trouve ça absolument fascinant ! ça ouvre des abymes de questions et d'idées:

- Certains groupes sont fermement opposés aux brevets logiciels et n'acceptent pas l'idée d'utiliser des brevets, même pour contre attaquer.
Par contre je pense qu'ils souscriront volontier à cette idée: j'adhère à OIN et je m'engage a ne pas attaquer les autres adhérents , en contreparti je ne serait pas attaqué par les autres adhérents (dont IBM, Sony etc.). C'est donc une excellente garantie, même pour les simples individus, et on n'est pas forcé d'utliser OIN pour contre-attaquer (donc on peut rester intègre sur sa position).

- Pour de nombreuses compagnies, adhérer a OIN peut être un bon moyen de se protéger contre ces énormes boites (IBM dispose de milliers de brevets) à moindre cout (négocier avec IBM, à l'amiable ou devant un tribunal, même si on a des brevets a leur opposer où si on est dans son droit, c'est couteux et long).

- Du coup, OIN pourrait croitre exponentiellement: chaque nouvelle société qui y adhère apporte son lot de brevet, rendant ainsi OIN plus fort et dangereux pour les autres boites utilisant les brevets, qui seraient alors encouragées à adhérer. Je fantasme ? peut-être, mais ce serait superbe non ? et ce n'est pas impensable !
exemple: si je me fait attaquer par Sony, IBM ou Phillips, je crois que je serait très tenté de régler ça en 5mn en adhérant à OIN ! ou bien encore: si j'ai envi d'utiliser gratuitement une techno (linux related) de Sony ou IBM, je commencerai par adhérer à OIN pour ne pas être attaquable.

- Linux pourrai devenir très vite, grace à OIN, un système inattaquable tellement le nombre de brevets le protégeant seront nombreux.

- Le status quo (non attaque entre les grosses compagnies) est déjà plus ou moins effectif dans le monde du brevet logiciel. Mais ce qui pèse toujours lourd, ce n'est pas tant d'être attaqué que d'être attaquable.
Les compagnies attaquables perdent la confiance des investisseurs, les particuliers et sociétés s'empechent d'utiliser des technos brevetés à cause des incertitudes (cf. par ex. la lecture mp3, souvent exclus des distros bien que Frauhnofer ai indiqué qu'ils n'attaqueraient que les encodeurs).
Les brevets excercent déjà leur nocivité à plein régime par le simple FUD (fear uncertainty and doubt).

- Sera-t-il possible pour de simples individus adhérants d'utiliser OIN pour menacer des sociétés detenant des brevets, et les forcer à adhérer à leur tours ? (non plus contre-attaquer, mais prendre les devants !).
Je verai bien un tir groupé et massif sur Fraunhofer, divx, Apple, Secure Computing etc.

- Ce qui est couvert par l'alliance, "Linux operating system or certain Linux-related applications" est un concept à géométrie variable ... comment définisse-t-ils ceci ? Par ex. est-ce que l'ensemble de Debian GNU/Linux est compris dans cette définition ?

- Nokia s'est déjà engagé à ne pas attaquer les developpeurs et utilisateurs du noyau Linux. Pourquoi n'adhèrent-ils pas ? Et Sun ?

- La non décision du parlement Européen concernant la brevetabilité logicielle ne rend elle pas caduque cette initiative en Europe ? Un particulier n'aura alors pas les moyen de se défendre (en faisant valoir l'illégalité du brevet) ni de contre-attaquer (puisque ces brevets n'ont pas de valeur).

[ Répondre ]

Re: portabilité

Posté par herodiade () le 13/11/2005 à 02:23. (lien). Évalué à 2.

Heu oui mais ce dont vous parliez c'est du besoin d'avoir le machin graphique de conception d'interface intégré à un éditeur (ce que j'ai compris par "IDE" en tt cas).

Parce que sinon: Qtdesigner est vraiment très bien pour faire ses interfaces à la souris. Et ensuite, effectivement, n'importe quel éditeur convient pour écrire le code C/C++ en dessous.

[ Répondre ]

Re: portabilité

Posté par herodiade () le 13/11/2005 à 02:17. (lien). Évalué à 2.

Et concrètement dans la pratique, il existe quelles IDE valables pour du Qt/C++ ? Aussi aboutis que Sharp Develop par exemple.

sous Linux & *BSD au moins, je ne dev pas sous d'autres plateformes on trouve notament kdevelop , assorti de tout le bazard pour les besoins précis (assistant pour l'aide/la doc, designer pour la gui, linguist pour l'internationalisation ...), ou XCode sous mac.

[ Répondre ]

Re: Protocole CARP

Posté par herodiade () le 07/11/2005 à 11:45. (lien). Évalué à 7.

Hum, il n'y a qu'un hôte qui utilise l'ip alors ? C'est simplement pour permettre le remplacement d'un hôte à chaud ? (redondance)

Oui exact.
Mais tu peut avoir deux (ou plus) IP flottantes gérées de la sorte par CARP et faire ainsi de la répartition de charge en proffitant de la puissance des deux (ou plus) machines: chaque machine utilise une des IP, on peut répartir le traffic par rr dns ou autre (et lorsque l'une des machines est en panne, l'autre récupère son traffic).

Bref, dans l'esprit de simplicité et minimalisme BSD, CARP a été conçu pour ne gérer que le failover/redondance, mais tout de même pour ne pas empécher la répartition de charge.

Dans la boite à outils complémentaires il y a aussi pfsync, qui permet de synchroniser les tables d'états et rulesets des firewalls entre les diverses machines et sasyncd pour synchroniser les SA IPsec (je ne crois pas que ce denier soit déjà porté d'OpenBSD 3.8 à FeeBSD 6). Le tout permettant de faire, par ex lorsque couplé à CARP, des firewalls et passerelles VPN redondants avec reprise de traffic automatique et sans interuption.

[ Répondre ]

portabilité

Posté par herodiade () le 06/11/2005 à 10:45. (lien). Évalué à 4.

Un plus pour qt4 si la portabilité est un objectif important (c'est un peu comme ça que je comprend le "dont le but sera notamment d'être distribuée le plus largement possible").

À ma connaisance mono (donc C#) n'est pas encore porté sur la plupart des systèmes *BSD (et en particulier sur les architecture non i386) ; Idem pour java (surtout si tu a besoin d'un jdk1.5, qui par ex n'est pas porté sur Mac OS X, mais gcj n'est pas encore très portable non plus). Par ailleur la large audience que tu semble vouloir toucher sera certainement heureuse de n'avoir pas à installer des interpréteurs pour faire tourner l'appli, surtout les non informaticiens.

La légereté (économie de mémoire) est aussi un bon argument en faveur de qt par rapport à java/mono.

Dans tout les cas (heu, en fait pour java et qt au moins) il y a des bindings opengl à disposition et ont toutes les widgets nécéssaires pour faire des "interfaces bien léchées", donc semblent remplir les (trop peu détaillées) contraintes techniques que tu indique.

[ Répondre ]

améliorations des performances

Posté par herodiade () le 05/11/2005 à 13:31. (lien). Évalué à 10.

Au rayon des changement, il faut signaler une amélioration très sensible des performances, en parficulier sur les accès au systeme de fichier et de façon générale sur les systèmes SMP (d'ailleur de très nombreux drivers, surtout pour les cartes réseau, sont maintenant, depuis la branche 6, mpsafe et leur travail est partiellement parallélisable ...).

Il semblerait que l'énorme travail effectué sur l'écriture et l'intégration du nouveau scheduler, l'elimination de giant lock etc. mis en place avec la branche 5 commence à peine à porter ses fruits avec la branche 6 qui vient d'arriver.

C'était un travail de longue haleine, mais c'est agréable de constater que les choix faits des années plus tôt étaient réalistes et pertinents !

Un autre changement sympa: le proto carp est maintenant supporté.

[ Répondre ]

Re: pilotes ipw2x00

Posté par herodiade () le 29/10/2005 à 21:48. (lien). Évalué à -2.

Le driver ne contient pas le firmware

Oui oops ma langue à fourchée ! je voulais dire bien sur dire : "Dans certains cas le firmware ne peut pas être inclus dans les distributions".

Tu as toujours l'ancien ?

Ou tu ne l'a jamais eu parceque tu vient d'acheter la carte. Et personne n'a le droit de te le refiler sans accord avec le constructeur ... dommage ;)

Sinon il y aura toujours moyen de faire des scripts qui l'extrait du exe

Oui, problable. Mais bon ... on sombre dans le très bricolo, très fragile, et fort peu intégré (c'est pas vraiment du fonctionnement out-of-the-box).

D'un autre cote qu'est ce qui l'interesse la majeur partie des utilisateurs ?
-Le prix,


En l'occurence l'utilisateur trouvera vraissemblablement son chipset Intel intégré dans son portable centrino (ou autre), et je doute que les 1 ou 2 euros de la rom fassent la différence. Si l'utilisateur avait vraiment le choix et se préoccupait surtout du prix, il prendrait surement du ralink (avec firmware) et boycotterai, par ex, le prismgt/prism54 (sans firmware). Donc ça tomberai plutot bien ;) (par contre il raterait l'excellent atheros, qui est quand même très cher). Malheureusement l'utilisateur n'a pas le choix, et il se retrouvera souvent, par exemple, avec une carte graphique chère et au gpu surpuissant qui ne lui sert à rien (avec, à coté, un winmodem idiot, une carte wifi sans firmware, et bientot un chipset de drm tcpa ...).

Je ne sait pas pour vous, mais je trouve que l'évolution / l'utilisabilité des technos 802.11a/b/g (sous Linux

[ Répondre ]

Re: pilotes ipw2x00

Posté par herodiade () le 29/10/2005 à 21:38. (lien). Évalué à 7.

Le driver ne contient pas le firmware

Oui oops ma langue à fourchée ! je voulais dire bien sur dire : "Dans certains cas le firmware ne peut pas être inclus dans les distributions".

Tu as toujours l'ancien ?

Ou tu ne l'a jamais eu parceque tu vient d'acheter la carte. Et personne n'a le droit de te le refiler sans accord avec le constructeur ... dommage ;)

Sinon il y aura toujours moyen de faire des scripts qui l'extrait du exe

Oui, problable. Mais bon ... on sombre dans le très bricolo, très fragile, et fort peu intégré (c'est pas vraiment du fonctionnement out-of-the-box).

D'un autre cote qu'est ce qui l'interesse la majeur partie des utilisateurs ?
-Le prix,


En l'occurence l'utilisateur trouvera vraissemblablement son chipset Intel intégré dans son portable centrino (ou autre), et je doute que les 1 ou 2 euros de la rom fassent la différence. Si l'utilisateur avait vraiment le choix et se préoccupait surtout du prix, il prendrait surement du ralink (avec firmware) et boycotterai, par ex, le prismgt/prism54 (sans firmware). Donc ça tomberai plutot bien ;) (par contre il raterait l'excellent atheros, qui est quand même très cher). Malheureusement l'utilisateur n'a pas le choix, et il se retrouvera souvent, par exemple, avec une carte graphique chère et au gpu surpuissant qui ne lui sert à rien (avec, à coté, un winmodem idiot, une carte wifi sans firmware, et bientot un chipset de drm tcpa ...).

Je ne sait pas pour vous, mais je trouve que l'évolution / l'utilisabilité des technos 802.11a/b/g (sous Linux & *BSD en particulier) est de plus en plus byzantine. On avait quand même moins de conneries avec les bons vieux chipsets ethernet je trouve. Mais il faut dire que c'etait une techno qui avait murit dans le monde pro avant de toucher le grand public ...

[ Répondre ]

Re: pilotes ipw2x00

Posté par herodiade () le 29/10/2005 à 19:29. (lien). Évalué à 4.

Je suis d'accord avec le fait qu'on ne peut pas se passer de BIOS propriétaires distribué dans les périphériques, et que ce n'est pas gravissime.

Mais le problème n'est pas le même pour un bios intégré au périphérique et un périphérique dont le bios doit être chargé par le kernel.

Lorsque le firmware n'est pas distribué avec le matériel, il doit l'être avec l'OS, et à ce moment sa licence est une question importante.

Selon les constructeurs (mais c'est bien le cas pour intel et les firmwares ipw), celà pose des problèmes de distribution ; nous sommes soumis au bon vouloir des constructeur de nous accorder le droit de redistribuer le firmware. Dans certains cas le driver ne peut pas être inclus dans les distributions "libres" (librement dérivables) ou celles pour lesquelles aucune autorité ne peut signer un accord de certification. Et le jour ou Intel trouve plus pratique de ne pas distribuer le firmware autrement qu'en bundle .exe avec le driver windows, tu peut changer de carte (ou passer à ndis, ou windows, mais bon ...).

Et je le répète, dans les deux cas nommé ici (Connexant/prism et Intel) la redistribution pose problème, et les constructeurs refusent de collaborer à tout niveaux (y compris pour les specs).

ca à même des avantages: tu peux au moins uploader n'importe quel autre firmware facilement, sans flasher, et donc écrire peut être ton propre firmware

Ici il n'y a aucune différence avec un firmware qu'on peut flasher en EPROM. Si le constructeur te fournis un firmware (eg. vieux prismII/prism2.5), tu peut aussi le reverse engeneerer etc.

Cette nouvelle tendance au firmware chargé dynamiquement par l'OS dans certains chipsets wifi est surtout motivée par un sens de l'économie de bouts de chandelle de la part des constructeurs, qui s'épargnent ainsi quelques kilos de rom...

[ Répondre ]

Re: pilotes ipw2x00

Posté par herodiade () le 29/10/2005 à 19:22. (lien). Évalué à 2.

Non, ce n'est pas le même problème pour les périphériques qui intègrent déjà leur bios.
Dans ce cas il n'y a pas de contrainte sur la redistribution de l'OS.
Heu... cf. ma réponse à Nicolas qui dit la même chose ci-dessous (j'ai la flemme de le re-écrire ;)

[ Répondre ]

Re: pilotes ipw2x00

Posté par herodiade () le 29/10/2005 à 19:17. (lien). Évalué à 6.

Je suis d'accord avec le fait qu'on ne peut pas se passer de BIOS propriétaires distribué dans les périphériques, et que ce n'est pas gravissime.

Mais le problème n'est pas le même pour un bios intégré au périphérique et un périphérique dont le bios doit être chargé par le kernel.

Lorsque le firmware n'est pas distribué avec le matériel, il doit l'être avec l'OS, et à ce moment sa licence est une question importante.

Selon les constructeurs (mais c'est bien le cas pour intel et les firmwares ipw), celà pose des problèmes de distribution ; nous sommes soumis au bon vouloir des constructeur de nous accorder le droit de redistribuer le firmware. Dans certains cas le driver ne peut pas être inclus dans les distributions "libres" (librement dérivables) ou celles pour lesquelles aucune autorité ne peut signer un accord de certification. Et le jour ou Intel trouve plus pratique de ne pas distribuer le firmware autrement qu'en bundle .exe avec le driver windows, tu peut changer de carte (ou passer à ndis, ou windows, mais bon ...).

Et je le répète, dans les deux cas nommé ici (Connexant/prism et Intel) la redistribution pose problème, et les constructeurs refusent de collaborer à tout niveaux (y compris pour les specs).

ca à même des avantages: tu peux au moins uploader n'importe quel autre firmware facilement, sans flasher, et donc écrire peut être ton propre firmware

Ici il n'y a aucune différence avec un firmware qu'on peut flasher en EPROM. Si le constructeur te fournis un firmware (eg. vieux prismII/prism2.5), tu peut aussi le reverse engeneerer etc.

Cette nouvelle tendance au firmware chargé dynamiquement par l'OS dans certains chipsets wifi est surtout motivée par un sens de l'économie de bouts de chandelle de la part des constructeurs, qui s'épargnent ainsi quelques kilos de rom...

[ Répondre ]

Re: pilotes ipw2x00

Posté par herodiade () le 29/10/2005 à 13:31. (lien). Évalué à 2.

Bin moi ça me fait grincer des dents dans les deux cas.

Le problème ne se résume pas en questions d'éthique/liberté/... mais aussi de qualité et de support: celà ajoute encore un composant dont les developpeurs n'ont pas le controle, ce qui commence à faire beaucoup pour les drivers ipw* et prism54 (les constructeurs respectifs n'ont jamais accepté de fournir aucune spec ou doc).

Leur intégration ne devrait pas être une raison pour ne pas boycotter ces chipsets (heureusement en ce qui les concerne, et en particulier prism54, on a d'autres raisons).

Par contre on peut faire une "echelle de pénibilité" des firmwares propriétaires selon que le constructeur autoriser ou non la libre redistribution du binaire (et avec ou sans signature d'accords).

Puisqu'on parle de cohérence dans les partis pris, il me semble que le cas pwc/pwcx (http://linuxfr.org/2005/05/31/19026.html ) n'était pas si différent mais à conduit au rejet du wrapper gpl par Linus ...

[ Répondre ]

Re: Adblock integré ?

Posté par herodiade () le 29/10/2005 à 00:03. (lien). Évalué à 2.

Dans mon cas:
- mon webmail
- 1 ou 2 sites de news (dont parfois linuxfr, lemonde.fr ...)
- les 3 ml qui recoivent les logs et/ou contenus des commits cvs sur les projets auquels je participe
- le bugtracker de mon taf
- le gestionnaire de doc (aka wiki) de mon taf
- l'interface web sur mes outils de monitoring (avec souvent un ou deux onglets pour supplémentaires pour des choses qui nécéssitent une surveillance accrue).
- des groupes de 4 ou 5 onglets de docs/tutoriaux/specifications/... sur des des thèmes précis, parce que mon boulot fait que je bosse sur plusieurs choses à la fois, que je doit "switcher" entres des thèmes dans la journée mais que je retrouve les mêmes thèmes pendant plusieurs semaines. Donc les docs de références ou tutoriaux en cours de lecture restent là pendant quelque temps (et l'utilisation de bookmark est dans ce cas ingérable, une perte de temps).
- un ou deux onglets pour le surf courant (adresses recues par email, irc, news rss, recherches google ...)

Peut être que cet usage te parait abusif mais je crois qu'il va devenir commun au fur et à mesure que les "applications web" vont prendre le pas, ce qui est une tendance générale même pour les non-geeks (webmails, agreggateurs rss, blogs etc.).

Finallement le navigateur devient une interface uniforme et commode pour traiter de façon commune des données textuelles autrefois dispersées (news nntp, mail, écriture et lecture de docs applicatives/système etc). Le système des onglets aide beaucoup. SessionSaver aussi.

[ Répondre ]

Re: Adblock integré ?

Posté par herodiade () le 27/10/2005 à 21:52. (lien). Évalué à 2.

J'ai noté des améliorations dans les 1.5beta surtout sur le switch entre onglet.

Ah oui c'est clair, le switch entre onglets est beaucoup plus rapide avec la version 1.5 ! Je travaille avec 40 à 50 onglets ouverts en pemanence, dans ces conditions la différence est frappante.

Idem pour revenir sur la page précédente (ou repasser à la suivante), c'est maintenant instantané sur le html statique.

Ça me donne l'impression d'un firefox beaucoup plus léger (à moins qu'il le soit effectivement ?).

Le problème des "onglets bloquant tout" dont tu parle semble avoir disparu aussi. J'ai lu qu'ils avaient beaucoup travaillé là dessus pour la v1.5. Par contre ils n'ont pas encore corrigé le problème de "tab overflow" (lorsqu'on a trop de tabs, les plus récentes sortent de la zone d'affichage visible).

[ Répondre ]

Re: Réactivité

Posté par herodiade () le 25/10/2005 à 21:06. (lien). Évalué à 2.

Évidemment, avec Mozilla, j'ai regretté la possibilité offerte par Galeon de rétablir les onglets ouverts avant plantage.

Elle n'avait pas disparu de Galeon ? Je ne suis pas sûr à 100% (ça remonte à loin) mais il me avoir céssé d'utiliser Galeon à cause de la disparition de cette option (rétablissement après plantage ou fermeture globale) qui m'a poussé à changer. En tout cas j'avait été déçu par l'amoindrissement des fonctionalités, et la difficultée croissante à le compiler sur slackware (à cause des dependances).

Quoiqu'il en soit, j'ai découvert l'extension Session Saver de FF (qui ne l'empêche pas d'être un peu trop lourd à mon gout).

[ Répondre ]

Re: modifiable ?

Posté par herodiade () le 25/10/2005 à 09:57. (lien). Évalué à 2.

Je ne crois pas que la question portait seulement sur la dispo des sources des drivers.

En l'occurence Conexant est connu pour son chipset grand public PrismGT, pour lequel il n'a pas filé de docs aux devs d'unix libres (reverse engeneering, nous voilà) et surtout, à interdit la redistribution du firmware, même pour un but non lucratif (le prismgt fait parti de ces chipsets dont le constructeur a voulu economiser un petit bout de rom en forçant le chargement dynamique - avant chaque utilistion - du firmware par l'OS hote).

Bref on peut très bien se retrouver avec un driver opensource mais inutilisable sans un firmware binaire et problèmatique (comment son integration avec le noyau va-t-elle evoluer avec le temps ? impossible intégration dans les "distros" non officielles ? ...).

Bon, celà dit je ne sait rien sur le Conexant CX3110X.

Le chip bluetooth est étrange aussi, on dirait que ce n'est pas du CSR. Quelqu'un en sait plus ?

[ Répondre ]

Re: Mauvaise excuse

Posté par herodiade () le 24/10/2005 à 00:19. (lien). Évalué à 2.

Ah oui là c'est impardonable ! ;)

[ Répondre ]

Re: modifiable ?

Posté par herodiade () le 23/10/2005 à 23:56. (lien). Évalué à 3.

Pour la facilité de flashage, on dirait bien que oui (et le contraire eu été suprenant):
"Maemo 1.1 RC Coming [...] he new release features the following: [...]
Linux Flasher tool to flash new product software (or developer rootfs)".
(http://www.internettablettalk.com/ )

D'ailleur des types d'OpenEmbedded ont déjà sorti une image basée sur GPE (http://maemo.org/pipermail/maemo-developers/2005-August/0009(...)
J'espère qu'ils arriveront à faire une image qtopia/opie aussi :)

Pour le framework, je crois que tu peut l'essayer sans l'appareil (ils fournissent même un livecd).

Pour les drivers, il faudrait avoir la bête sous la main pour vérifier, mais c'est une vraie question, et je suis très intéréssé aussi. Surtout concernant le wifi, parceque le .config du kernel ( http://maemo.org/maemowiki/KernelConfig) m'inquiete un peu: CONFIG_CX3110X=m" et "CONFIG_FW_LOADER=y", donc on dirait bien du Connexant, un constructeur déplorable.

[ Répondre ]

Re: ...

Posté par herodiade () le 23/10/2005 à 21:02. (lien). Évalué à 3.

Roohhh le veinard, hé ! Bon pusique c'est comme ça, ta mission c'est de bugziller tout les petits bugs pour que la version définitive pour non-developpeurs qu'on achetera soit super au point :P (genre le problème d'internationalisation, il est reporté ?).

Nah, c'est la punition ;)

[ Répondre ]

Re: ...

Posté par herodiade () le 23/10/2005 à 20:56. (lien). Évalué à 4.

Bonne question, je me demande aussi, par exemple, si les bugs que tu a trouvé seront corrigés à la sortie (j'aimerai que l'appareil soit parfait, tellement je suis ébahi par l'honneteté de leur démarche logicielle).

ps: c'est vrai que c'est un peu dommage pour l'absence de chipset de téléphonie ; mais je suis certain que la horde de hacker sur la brèche trouvera à prouver l'utilité de l'appareil quand même ;)

ps2: un autre atout, son prix: 300 euros, c'est bien en-dessous du prix des autres PDA sous Linux.

[ Répondre ]

[ Précédent :: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 :: Suivant ]