Toufou a écrit 1369 commentaires

Moi qui croyais que les "attaques" informatiques étaient bien définies et que ce type de requète n'en faisait pas partie...
Quelqu'un aurait plus d'info là dessus ?

Ce qui est vrai c'est qu'elle est détectable beaucoup plus facilement, et qu'une fois détectée elle est rapidement corrigée. On ne peut pas en dire autant de beaucoup de logiciels fermés.

J'ai eut le même problème avec FT Cable et l'abo plein accès:
- diminution du nombre d'IP lors du passage à pppoe: avant on en avait un certain nombre (1 fixe et jusqu'à 15 dynamiques je crois), après on en n'avait plus qu'une.
- déconnexion toutes les 24h alors que nulle part il est spécifié ce genre de choses.

Bon, il ne faut pas être trop méchant avec eux, ils tolèrent les serveurs sur leur connexions cablées mais bon, ils auraient pu nous demander notre avis avant de passer à 1 IP.

nawak :)

Ce que j'ai dit 2 post au dessus:
- je parie: parce que je n'utilise pas régulièrement KDE/QT, je ne peux donc pas savoir.
- la distinction avec les sockets: vu les éléments pertinents que tu a donné dans ton post à ce sujet, je n'ai pas compris ce que disais. Si tu as lu les posts qui le suivent, tu aurais dû t'en apercevoir.
- un préjugé: non, je me sers de composants au boulot sous Delphi et VB (je suis développeur). Les problèmes que je décris sont ceux que je rencontre tous les jours. Alors, je ne connais pas en détail le fonctionnement interne des composants que j'utilise, ce que je sais c'est que je ne peux pas les utiliser pour des problèmes de performance et de stabilité. Avec 64Mo, ce dont je dispose au boulot, il ne faut même pas penser à inclure un composant ActiveX style IE/Word/Excel dans une application et pourtant j'aimerais bien pouvoir le faire.

Ce qui me gène dans l'approche 'composants':
- actuellement, je n'ai vu aucune application raisonablement stable (c-a-d, qui crashe moins d'une fois par jour) utilisant ce genre de systeme alors que j'ai des applis GTK (que j'utilise chez moi, c'est pour ça que j'en parle) ne crashent pas pendant plus d'une semaine et en les utilisant tous les jours.
- les connaissance requises pour manipuler ce genre de concept sont nettement au delà de celles qu'il faut pour faire les même choses sans cette approche (ne serait-ce que parce qu'il faut connaitre des mécanismes de communication, des methodes, etc. en plus de ce qu'il fallait savoir avant). Excuse moi de ne pas être un dieu en prog, même si j'aime bien comprendre un minimum de ce que j'utilise dans mes programmes.
- dans 90% des cas, j'ai (enfin, les gens à mon boulot) un mauvais rapport ressources/fonctionnalités/maintenance/stabilité par rapport à de l'objet classique, et dans les petits projets l'approche objet elle même n'est pas forcément rentable. Et des petits projets, je pense qu'on est nombreux à en faire.
- la réutilisation, c'est bien joli sur papier mais c'est extrèmement difficile en vrai. Une facture chez les assureurs ne ressemble pas structurellement et "comportementalement" à une facture chez un garagiste.
- comme je te l'ai déjà dit ça augmente encore plus le risque de problèmes dûs au code caché (comme pour de l'objet, mais avec en plus des mécanismes de communication opaques)

Ce qui me gène dans vos posts (P. Fremy et toi), c'est que j'ai l'impression que vous présentez l'approche composant/réutilisation un peu comme on a présenté l'objet, les bases de données objet ou le micro noyau: c'est LA manière de faire, LA solution miracle. Je dis juste que je ne le pense pas, que je pense que c'est juste une manière de faire et j'explique pourquoi. Je n'ai rien contre l'objet ou le composant, mais je trouve techniquement idiot de le mettre à toutes les sauces à tout prix.

Ouais, c'est une manière de voir... comme tu le dis :
"si toutes les applis etaient bien faites, il n'y aurait meme plus besoin d'écrire du code.". Je pense que c'est aussi le problème de l'approche par composant, si c'était bien fait ce serait plus simple, plus léger et plus stable.

Pour ma part, je n'ai jamais vu un seul environnement basé là dessus (KDE/Gnome/Windows) qui n'ai pas ces défauts:
- en utilisation: lenteur, taille et instabilité. Ce que je constate c'est que GTK+ sans gnome c'est petit, rapide, stable et répond à 99% de mes besoins. Je parie qu'on a la même chose avec QT sans les parties OLE-like de KDE.
- en programmation: c'est décrit en détail dans mes autres posts.

Quand tu me dis mais non c'est chouette, ça marche et on peut en mettre partout c'est un peu comme si je disais le Hurd c'est bien, ça marche et on peut en mettre partout: c'est chouette oui, ça marche, non, on peut en mettre partout oui mais bon, on peut éviter de s'emmerder avec ça dans 50% des cas.

Trois points:
- l'intégration:
à part l'intégration visuelle (affichage dans ton appli et intégration des menus du composant) que tu peux difficilement faire avec deux applications séparées, le reste, si ces applications sont bien faites, tu peux le faire avec des mécanismes plus simples sans s'arracher les cheveux.

- réutilisation de l'existant:
ton exemple est une forme de non réutilisation de l'existant: pourquoi transformer les pages de man/info en html au lieu de lancer l'application dédiée sur la bonne page ?

- paramétrage du composant:
Avec ton exemple, tu te retrouves comme avec msdn où on peut se servir de l'aide pour aller surfer sur le net. Bon ce n'est pas bien grave mais si tu veux l'empecher, bon courage. Tu illustres ce que j'ai dit dans un post au dessus: si le composant est trop générique (ou a trop de fonctionnalités), dans la plupart des cas, tu passes autant de temps à bidouiller un bridage, un ajout où une modif qu'à refaire le composant avec des libs de plus bas niveau.

Ok vu comme ça je veux bien. En gros, si j'ai bien compris la différence se trouve dans le fait que tu définis aussi le protocole de communication dans la spécification de ton composant. Mais je ne comprend toujours pas ce qu'amène de mieux un modèle d'aussi haut niveau par rapport à des communications plus 'primitives' telles que celles qu'on peut établir grace à ces moyens (IPC/socket). Tu disposes des mêmes moyens: une unité de traitement et une interface avec cette unité (protocole et moyen de communication). Il me semble que c'est juste une nouvelle manière de faire et que son seul intéret est d'amener plus de diversité dans les manières de faire.

Ce qui me gène vraiment en fait c'est que je trouve que l'approche par composants a un mauvais rapport fonctionnalités/ressources comsommées. Et c'est aussi une infâmie à stabiliser manifestement, le modèle étant nettement plus complexe que les méthodes habituelles. Ca me fait un peu penser à l'approche RISC/CISC pour les processeurs ou a l'approche micro noyau vs monolithique: on va avoir des composants bien plus complexes que ce dont on a généralemnt besoin et ce, au au prix d'une perte de performances et d'une maintenance énormes.
Pour résumer ma pensée:
1- je doute fortement qu'on puisse réellement réutiliser la plupart des composants existants car ils seront trop généralistes, peu adaptés aux situations sur le terrain et bien trop gourmands pour ce qu'on veut en faire.
2- ce genre d'approche transforme et déplace la difficulté de conception mais ne la diminue pas: on se prend la tête à adapter l'existant tant bien que mal au lieu de se prendre la tête à concevoir du nouveau: bof.
3- on augmente considérablement le niveau requis pour se servir de ces choses: il faudra connaitre des mécanismes supplémentaires aux existants pour pouvoir se servir correctement de ces outils. Déjà qu'en 2 ans d'IUT ou en 3 ans d'école d'ingé on a juste le temps de comprendre les bases, je me demande ce qui sortira des écoles: des spécialistes .net qui ne comprennent rien aux réseaux ?
4- je continue à penser que ce modèle (comme tout modèle) est adapté à certaines situations mais pas à toutes. Tout faire touner dessus simplifiera certaines choses mais complexifiera d'autres.

Je n'ai jamais participé à un grand projet, donc je ne peux pas voir l'intéret de ces modèles dans ce cas, mais pour le cas du developpement des applications que M. tout le monde a sur son bureau,je ne vois vraiment pas d'autre intéret que ceux cités par le post d'origine => une tentative de prise de pouvoir par MS en déplaçant le problème sur un terrain dont il maîtrisera la norme et les outils. Qu'on récupère des idées et qu'on offre un support pour ne pas s'isoler, pourquoi pas ? Mais se lier étroitement à ces technologies comme le désire MDI me semble un bon moyen d'envoyer direct gnome à la poubelle (déjà qu'il n'est pas super utilisable...) en le complexifiant au delà du besoin et de la capacité de maintenance des developpeurs.

Est-ce que tu vois la différence entre la commande 'cat' et un parser ?
N'importe quoi, cat et un parser n'ont pas les mêmes fonctionnalités/usages. Alors que là on parle d'une communication interprocessus selon deux méthodes différentes.

- aucune appli n'a de methode standard pour parler a une autre. Heureusement, on commence a voir des choses avec Bonobo, DCOP ou SOAP, mais ca reste encore tres fragmente et incompatible.
les sockets et les IPC System V ce n'est pas standard ? Il suffit de spécifier le protocole de communication. Je ne vois pas la différence avec la spécif d'un composant.

- aucune appli n'a de methode standard pour reutiliser des composants d'une autre appli. La aussi Gnome et KDE commencent a nous apporter des solutions, mais c'est tardif.
La programmation par composants c'est peut-être bien sur des gros dévelopements serveurs (je ne connais pas du tout le domaine, mais même là je doute) mais je n'arrive toujours pas à voir l'intéret au niveau client par rapport à une librairie. Plus tu t'approches du besoin métier / utilisateur, plus tu dois personnaliser ton interface et tes structures: la réutilisation se restreint de plus en plus. Alors avoir des composants style browser html dans ton appli, à part bouffer des ressources (non tout le monde ne change pas un parc de 100 machines tous les ans), ça sert à quoi ?

D'après ce que je comprend de ce que disent la FSF et l'OSI qui sont les plus deux grand formalisateurs des idées de Free Software ou Open Source, il me semble que c'est une différence fondamentale: l'un encourage le 'copyleftage' ( http://www.fsf.org/copyleft/copyleft.fr.html(...(...)) ), l'autre ne se préoccupe pas de ce type de problème.

Autant, au niveau de la license c'est plus ou moins pareil (les licenses conformes à l'OSD ( http://www.opensource.org/docs/definition.html(...(...)) ) sont libres ), autant en tant que mouvement, il me semble que c'est assez différent pour être distingué.

C'est sur que je ne comprend toujours pas comment on peut encore confondre _ici_ Free Software et Open Source. Idem pour FSF et GNU.

That's no good, brother, that no good.

Bah, il existe le même genre de problème entre les différentes versions de windows

Hmmmm au hasard, sous delphi 6.0 le DBgrid délire complètement (la sélection particulièrement) si la souris est pourvue d'une molette ou si tu veux faire du D&D avec, le ADODataSet comporte des fonctions qui ne marchent pas (avec oracle, le Locate, par exemple), et les composant ADO génèrent des exceptions que la VCL ne récupère pas. Et pourtant il est déjà sorti un patch.
Sous CLX pour windows, il faudrait que je retrouve mon test pour trouver des exemples. Et puis, quitte à faire du QT, autant en faire du natif, non ?

La présence de Kylix et BCBuilder dans le monde Linux-pour-PC ne va certainement pas révolutionner le monde du libre/open source, d'autant plus qu'il existe des IDE (comme KDevellop ou Lazzarus) qui promettent nettement plus et qui ne sont pas liées à un toolkit ou à une architecture. Certes, elles ne sont pas finies, mais bon, celles de borland non plus (pas plus que VB de MS, je ne connais pas VC++). Kylix et Lazzarus, au moins, ont un avenir et bénéficient d'un avantage énorme: c'est au minimum de l'Open Source.

Les Composants ne font que ce que l'on demande de faire. Il sont bien dressés.
Pas ceux de la VCL qui est une grosse bouse truffée de bugs. Et le peu que j'ai testé de CLX m'a fait revenir à la VCL.

Et j'irais jusqu'à dire qu'on avait pas vu ça depuis longtemps.

Le BSA lui proposera un arrangement "à l'amiable" du style: soit tu achêtes ce que tu pirates, soit on t'explose au tribunal... Il vaut mieux faire appel à un autre organisme style l'APP ( http://www.anti-piraterie.com.fr/index.htm(...) ).
Sinon c'est sur que le jour où il faudra cracher les 300€ pour son petit XP familial + les 1000€ pour avoir un office pro juste pour taper 3 lettres dans l'année, les gens regarderons plus du côté des 100€ d'une Mandrake (ou autre) complete.

Même que ça s'appellerai de la piraterie que ça m'etonnerai pas :). Piratage, gravage, hashage, cédérom ... Y a pas à dire, la langue française s'enrichit tous les jours :)

Je me demande comment ils vivent le port de la sale étiquette de rebelle anarcho-communiste-antiaméricain-pabolamondialisation-etc qui va si bien avec linux ;) Plus sérieusement, vu comme c'est pas facile de bouger les décideurs pressés du privé pour faire entrer le libre dans une boite, j'applaudis ceux qui arrivent à faire bouger les décideurs pressés de l'administration.

Oui, c'est le problème, ce n'est pas une fonction standard. Mais bon, comme tu disais, il suffit de jouer avec les #define. De toutes manières, je pense pas que ce soi le seul endroit où tu as des problèmes de portages qui t'amènes à jouer avec la compilation conditionnelle.

man __clone()

Sous Linux, il me semble qu'il existe une fonction non standard qui s'apelle __clone et qui permet de faire ce que tu demandes (partage de la tables des signaux et/ou du PID, etc).

Pour le scp il y a un freeware WinSCP qui n'est pas trop mal, même s'il est encore en beta pour la v2.0



http://winscp.vse.cz/eng/(...(...))

Avoir Mac, c'est comme acheter des meubles Art Deco au lieu d'aller à Conforama : c'est très beau mais très cher.
Ben en fait pas tant que ça... Un PC de qualité coute presque le prix d'un mac à peu près équivalent. C'est juste que le bas de gamme mac commence plus haut que le base de gamme PC (pas de mac à 5000F). Au niveau des portables, ça a l'air grosso modo la même chose.
Pour ma part, j'ai hésité pour le renouvellement (inutile d'ailleurs, mais c'est un conditionnement difficile à défaire) de ma machine, et je n'aurais pas eut une opportunité PC, j'aurais peut-être pris un mac. De toutes manières, c'est linux qui aurait tourné dessus :)

Steve Jobs a bien anticipé en proposant un OS Basé sur de l'Unix et sur les outils de dev GNU : il s'assure ainsi la disponibilité de pleins de logiciels.
Il me semble que en 89 le Next était déjà proposé avec gcc... Il n'est pas à son coup d'essai le bougre :)

Non, c'était juste histoire de dire qu'en info le pognon injecté ne fait pas tout. Ca aide, c'est sur, mais beaucoup de concepts ont été trouvés par des individus (ou des groupes) sans trop de moyens.
Selon moi, l'amateurisme à une grosse influence et reste un enorme foyer à idées que ne remplacera pas forcément un raz de marée de pognon.