[ Précédent :: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 :: Suivant ]
Re: quelques explications s'il vous plait
>> ODF réutilise et repose sur de nombreuses autres normes W3C/IEEE pré-existantes, éprouvées et concrètement implémentées auparavant.
> 1) Et ? Ca veut dire que magiquement il ne faut pas lire ces autres normes ?
Pas vraiment (quoique : les standards existants ont certainement leur raison d'être, et des implémentations qui vont avec).
En fait ça veut surtout dire qu'on utilise les standards, au lieu de marcher dessus. De même que les diverses RFC décrivant les couches et protocoles réseau fonctionnent bien entre elles. Si on devait réinventer une pile complète « à la TCP/IP », mais différente et incompatible chaque fois qu'on sort un nouveau protocole comme HTTP, SOAP etc., le monde de l'informatique n'avancerait pas beaucoup.
> 2) C'etait OASIS,
heu oui, désolé ; j'ai aussi mis des « IEEE » en lieu de place de « ISO » dans le commentaire. Étourderie, quand tu nous tient...
> est-ce que OpenXML fait ce qu'il doit faire correctement ou pas. C'est la seule question a se poser. Le reste c'est du delit du sale gueule et n'a rien a voir
En réalité, le fait qu'un nouveau standard fasse exactement la même chose qu'un standard déjà validé est une objection et un des rares motifs de rejet reconnus et valables pour l'ISO.
[ Répondre ]
Re: quelques explications s'il vous plait
Mais :
1- ODF réutilise et repose sur de nombreuses autres normes W3C/IEEE pré-existantes, éprouvées et concrètement implémentées auparavant. D'où des specs très compactes. À l'inverse OpenXML, réinvente presque systématiquement la roue, d'où un format qui se documente en plusieurs milliers de pages.
2- Il existe déjà un standard bureautique validé par l'IEEE, développé collégialement par de nombreuses sociétés (Microsoft en faisait parti, au sein de l'IEEE) : le format ODF. Il est de fait supporté par plusieurs logiciels/implémentations différents. Pourquoi l'IEEE validerai un format de plus, incompatible avec le précédent, développé par une seule entreprise, entaché de brevets ?
La question serait plutôt : faut-il accepter et valider la méthode habituelle de MS « faire tout, seul dans son coin et fouler les standards existants du pied » en leur décernant en plus cette fois la petite médial de la standardisation, ou considérer qu'il y a un standard existant, et que, pour une fois, MS ferait bien de le respecter comme tout le monde (et pas de la même façon qu'ils « supportent » html, css & co, si possible). Un peu comme les US et l'ONU quoi.
[ Répondre ]
Re: logiciels libres permetant de sécuriser un minimum un winxp home
> Ils viennent parler de logiciels proprios sur plateforme proprio avec tous ses problèmes
En fait il a demandé (c'est vrai, maladroitement) des noms de logiciels libres pour protéger Windows XP (pas libre), et de fait, la dépêche parle aussi de ça (ClamWin).
Donc quelques pistes (je n'y connais pas grand chose, si vous avez d'autres idées...) :
- CoreForce (un port de Packet Filter, le pare-feu d'OpenBSD, sous Win)
- ClamWin (cf. dépêche)
- Winpooch
- WinPT (solution de chiffrement et signature numérique libre, basée sur GnuPG)
- OpenVPN et Stunnel (pour le chiffrement et auth des connexions)
- Password Safe (artistic licence, évolution d'un logiciel développé par Bruce Schneier pour conserver ses mots de passes de façon sécurisée), ou KeePass (même genre)
- Snare (un HIDS et analyseur de logs pour Win, sous GPL)
- TrueCrypt (un logiciel libre et multiplateforme de chiffrement des disques et partitions)
- Firefox et Thunderbird (bin oui, les virus aiment bien Outlook, et le support des auths sécurisées et du chiffrement & signature de Tunderbird est loin devant)
- OpenOffice en désactivant les macros
Au passage, et c'est une remarque que fait courament Theo de Raadt pour expliquer la licence d'OpenSSH : pour améliorer la sécurité de sa machine, il n'est pas inutile d'aider à l'amélioration de la sécurité des machines voisines, y compris des Windows (il suffit de penser aux conséquences des spams zombies, ou des saturations réseau causés par les vers affectants IIS).
[ Répondre ]
bonne nouvelle, mais nous ne sommes pas débarassés des FUD
Le doute concernant le respect de la propriété intellectuelle de SCO dans le code du noyau Linux a nuit à son utilisation dans certaines grosses sociétés, pendant des années. Ce n'est pas pour rien que Microsoft a financé SCO en 2003, date de début des procès (Microsoft a acheté une licence Unix à SCO au prix fort à cette époque).
Mais, et ce n'est certainement pas un hasard (les nombreux avocats de Microsoft ont certainement prévu l'issue du procès SCO), nous avons désormais un jeune et nouveau FUD du même type, tout frais, aux conséquences exactement similaires (introduisant un nouveau doute concernant la légalité de Linux) depuis quelques mois : les fameux 235 brevets que Microsoft possède et que Linux serait censé violer (selon MS).
Peut-être pas un hasard non plus, le fait que Novell soit le premier et le plus grand acteur du monde Linux a avoir accepté l'accord avec Microsoft concernant ces brevets. En effet Novell est maintenant la seule des grands distributeurs de Linux corporate vierge de ces grandes menaces virtuelles concernant la légalité de Linux (grâce à ce jugement, nous savons qu'ils possède les copyrights d'Unix, et leur accord avec Microsoft les lave du soupçon de violation de brevets).
Pas un hasard non plus, le fait que Novell pousse très fort des technologies justement brevetées par Microsoft sur le desktop Linux (Mono, serveur exchange-like, ...) : ils sont désormais les mieux placés pour racketter les utilisateurs en tirant parti de ces deux FUD (SCO et MS). Bravo l'artiste.
[ Répondre ]
Re: Quelle horreur !
Remarquez que dans certains cas (surtout pour les portables Toshiba, Thinkpads, Sony, ...) les touches spéciales sont envoyées au système sous forme d'évènements ACPI (et non sous la forme d'input events).
Richard Hughes, un des mainteneurs de HAL vient de lancer un appel à contribution auprès les utilisateurs disposant de claviers problématiques de ce type : il estime que HAL permet de gérer ces cas particuliers de façon très propre, et avec une bonne granularité, depuis qu'il a mis en place un framework adapté, mais a besoin d'informations concernant les divers claviers. SVP, aidez-le si vous pouvez :
* Mapping keys : unfucking one keyboard at a time, par Richard Hughes :
http://hughsient.livejournal.com/29730.html
* Et le superbe HAL Quirk Site :
http://people.freedesktop.org/~hughsient/quirk/
Vous pouvez aussi faire un tour sur la page des quirks si vous avez des problèmes avec l'hibernation, la mise en veille, ou avec la gestion du rétro-éclairage.
[ Répondre ]
Du plugin Plugin dans ses rapports avec les plugins de plugins
« Le plugin Plugin permet de modifier et d'étendre le comportement de plugins existants via de nouveaux plugins ; »
-> Le greffon Plugin permet de modifier et d'étendre le comportement des greffons existants via de nouveaux greffons.
Qui a dit que la traduction des termes informatiques rendaient le texte moins compréhensible ? :P
[ Répondre ]
Re: Mmmm, voyons voir...
> Bon en fait je suis en train de repenser une application et avoir un pmo qui agis au niveau record ça me serait assez pratique.
Au cas où tu ne l'ai pas déjà fait, il pourrait être prudent de jetter un oeil sur les frameworks complets existants, faits par des gens qui connaissent les besoins caractéristiques (des fw qui sont utilisés en prod, par exemple), et pas par des étudiants qui croient découvrir la lanterne magique.
Peut-être quelque chose comme :
http://www.cakephp.org/
http://www.symfony-project.com/
http://seagullproject.org/
etc.
En outre le choix de licence (GPLv3) de phpmyobjet t'impose de passer ton appli sous ce régime, et de ne pas utiliser d'autres libs sous une licence incompatible (comme, au hasard, GPLv2, LGPL, openssl, ...), ce qui est un beau sacrifice pour une telle lib.
Outre les critiques adressées ici, un exemple tiré du code source :
public function getAttribute($name) {
if(isset($this->object_attribute[$name]))
return $this->object_attribute[$name];
return FALSE;
}
J'imagine que la gestion des exceptions, ou différencier les attributs inexistants des attributs vides, c'est secondaire chez PMO...
[ Répondre ]
MultiDeskOS inside
Aussi loin que je comprenne ton design (je ne suis pas dev PHP), chaque objet MyObject correspond exactement a une (et une seule) table. Et les MyMap permettent regrouper ces objets cote à cote avec des bon tableaux à l'ancienne. C'est bien, mais si on danse mais si tu veut faire du relationnel ?
ORM signifie « Object Relation Mapping » : le but est avant tout d'abstraire les relations entre les objets. S'ils s'agissait seulement de saupoudrer les noms de tables et colonnes d'une pincée de syntaxe objet-like, on aurait surement appelé ça OTR (comme object table mapping).
Pour rester dans les exemples bateau, imagine que j'ai une entité "Utilisateur" et une entité "Addresse" (un Utilisateur ayant une seule Addresse, pour
faire simple). Je souhaite évidement pouvoir faire des choses du type :
$user = Utilisateur::getByName("Mickael Kael");
$user->address->setTown("Muflin");
$user->save();
Dans cet exemple on voit comment la relation pourrait être "abstraite" de la couche de persistance. En outre on aimerais pouvoir charger paresseusement (lazy loading) les objets et leurs attributs. Surtout lorsqu'on va sélectionner en profondeur (ex. ne pas charger toute les tables traversées (en plus, a coups de "SELECT *" !) en mémoire lorsqu'on fait un $user->client->address->town->getPostcode() sur un objet précis alors que pour ses congénères on n'utilise que $user->getClient()).
Si j'ai bien compris, pour le moment, l'utilisateur doit gérer ces relations à la main en écrivant ses requêtes et en agrégeant/associant manuellement les objets d'une même « ligne » (sic) du tableau MyMap, et en moulinant à l'ancienne pour reconstruire les liens en deréférençant les fkeys. Mais alors, quel intérêt d'un ORM (ou même, d'une vue objet) ?
> Le design pattern de pmo est documenté
J'ai lu le manuel indiqué en lien dans le journal (ici c'est culture Unix, alors si le man ne documente pas tout et qu'il faut lire des divx pour connaitre l'API...), mais je crois que tu n'avais pas compris mes remarques.
> PMO implémente par exemple active record, et fait même plus que cela [...]. PMO est plus souple que ADOdb [...] et les autres ORM PHP car c'est une API qui se concentre sur l'abstraction objet et non un framework qui va faire tout et n'importe quoi.
Et sinon ça va les chevilles ?
> PMO utilise PDO en couche d'abstraction, il permet donc d'utiliser Oracle, interbase, postgrsql, mysql
Ce que je voulais dire, c'est qu'ADOdb offre une API permettant de s'affranchir des petites différences de syntaxe SQL entre les divers moteurs (ce n'est pas seulement une façon d'unifier les drivers sgbd de php). Enfin bon c'est assez secondaire par rapport aux autres problèmes de PMO.
[ Répondre ]
Re: Mmmm, voyons voir...
Je pense que ce que alpage te suggère, c'est tout simplement de mettre en oeuvre des design patterns pour ORM connus et éprouvés, plutôt qu'inventer le tient au hasard (et découvrir plus tard, lorsque tu sera tenu d'assurer une rétro-compatibilité, les limitations).
Un exemple de motif de conception en vogue en ce moment : http://fr.wikipedia.org/wiki/Active_record_%28motif_de_conce(...)
Déjà plusieurs fois implémenté en PHP, par exemple ici : http://phplens.com/lens/adodb/docs-active-record.htm
C'est un bon exemple : John Lim a une remarquable expérience en la matière, tu peut t'en inspirer, et peut-être aussi utiliser sa bibliothèque ADOdb pour bénéficier d'une abstraction sur l'accès au moteur SGBD, donc d'une meilleure portabilité (parce que MySQL, c'est bien, mais il existe d'autres morteurs de bados (comment ça, "sqlite roxor" ? :P)).
[ Répondre ]
Explications de Linus Torvalds
Linus aurait choisi CFS plutôt que SD à cause de l'attitude quelque peu « religieuse » de Kolivas et de ses fans (considérer SD comme parfait, nier les problèmes ou troller avec ceux qui rapportent les bugs au lieu d'essayer d'en savoir plus et d'améliorer les choses).
Cf. http://kerneltrap.org/node/14008
[ Répondre ]
Re: Super interview
Oui. Je mettais l'accent sur la lenteur des disques (et, dans un autre post, sur l'importance des I/O schedulers plutôt que du scheduler CPU), parce je n'ai pas rencontré les problèmes dont parle Kolivas (lecture audio saccadée à cause d'autres processus qui consomment du temps de calcul, par ex.) depuis plusieurs années sous Linux. Je me suis même demandé si Kolivas a vraiment testé un kernel vanilla (sans les patchs "-ck") récemment.
Par contre j'ai parfois de tels symptômes (audio ou vidéo saccadée, souris et rafraîchissement des fenêtres qui lagguent un peu) lorsqu'un processus en arrière plan consomme beaucoup d'I/O block (ou, cas similaire, lorsque Firefox ou Amarok ont tellement avalé de RAM que le système doit jongler avec la swap, très lente du fait des accès disques).
(ps: briaeros007, tu parle à point nommé des 5400 dans les portables, et comme justement les ventes de portables sont - en proportion avec les ventes de machines desktop classiques - en croissance constante, ça fait de l'utilisation de ce type de disques un cas d'utilisation de plus en plus représentatif du « desktop Linux », je crois. Les disques SSD seront peut-être une bonne solution).
Et vous, avez-vous rencontré ces problèmes de saccade et lenteurs uniquement lié à la répartition CPU (sans grosse charge I/O concomitante), avec des kernels récents et en utilisation « desktop » ?
[ Répondre ]
Re: Regrettable
> la limite a 64 sur Windows est purement artificielle
Clair, c'est d'ailleurs pour ça que Windows est si populaire sur les grands systèmes.
> Quand a IPSEC, bah vu que tout le traffic chez MS est sous IPSEC, faut croire que ca marche plutot bien.
Avec autre chose que du 3DES et MD5 ou SHA-1, et en ESP mode tunnel (pas l2tp hein) ? Pour avoir déployé de l'IPsec sous FreeBSD, OpenBSD, Linux et Windows XP (oui, j'ai pas vu ce qui s'est fait ensuite), j'ai un point de comparaison : Windows est une merde.
> arreter de melanger Win95 et NT si tu veux etre pris au serieux.
On parle de desktop. Avant 2000, la version « desktop » de Windows, c'était NT ou Win95 ?
> T'as Adobe Acrobat pour Linux 64 bits ? Flash peut-etre ? Maya peut-etre alors ? Bon RealPlayer ? Quake 4 alors ?
Seulement des applications propriétaires, dont la moitié ont des équivalents libres (evince, n'importe quel média player), l'autre moitié (quake 4 ou Maya) n'est pas franchement ce qui fait le quotidien moyen de l'utilisateur de desktop). Manque Flash, ok. Pour le reste j'ai environ 15000 applications packagées dans mes dépots: à peut près pareil qu'en x86_32. Désolé de te décevoir, mais on est quelques un à trouver très confortable un environnement totalement libre (donc, n'utilisant aucune des applications que tu cite).
> tu ne sais absolument pas de quoi tu parles.
Ah bah, j'ai cité OpenXML à dessein : avec les specs, contrairement aux logiciels propriétaires, on peut voir les entrailles à l'oeil nu. Et là, mais les sales hacks pour respecter une rétrocompatbilité par impératif commercial (rq, c'est aussi péniblement visible dans les bugs non corrigés d'ie7), le réinventage de roue systèmatique, l'agenda marketing, le bloatage, vous ne pouvez plus les cacher.
[ Répondre ]
Re: Regrettable
>> 1) Tout d'abord il fait le constat que le développement de Linux se focalise sur le marché des serveurs et que le desktop est sacrifié
> Le constat est juste, et Con n'est pas le seul à le dire. Le desktop n'est pas "sacrifié", il n'y a pas autant de ressource que pour le serveur. C'est tout.
Par ailleurs, je me demande si ce n'est pas un peu artificiel d'opposer ainsi desktop et serveur.
Dans bien des cas, les fonctionnalités « serveur » d'hier sont le desktop d'aujourd'hui (par exemple : le réseau, le 64b et le SMP). C'est là qu'on peut apprécier les choix et la vision à long termes des mainteneurs de Linux (d'Unix en général, en fait).
Puisque visiblement les discussion sur ce journal portent souvent sur la comparaison avec Windows, on peut jouer à retracer les décisions pertinentes, à l'époque « orientées serveurs », qui font de Linux un noyau très puissant (je ne parle pas du userland) et de Windows le playskool que l'on connait :
- Le SMP. Il y a 2 ou 3 ans seulement, c'était considéré comme une fonctionnalité purement serveur. Désormais c'est (disons, les CPU multicoeurs) le moyen d'évolution principal annoncé pour les futures CPU, même grand public. Linux supporte le SMP massif depuis longtemps, et a pris une sacrée avance sur Windows dans le domaine (IBM fait tourner des Linux sur des machines à 1024 processeurs, Windows Sever 2003 plafone à 64 CPU, et Vista, c'est du desktop, seulement 2 !), ainsi que dans le calcul distribué (grands clusters, ...).
- Un OS vraiment architecturé pour le réseau (au lieu du TCP/IP ajouté comme un furoncle sur un OS pour dactylos). Si l'on compare les fonctionnalités réseau « avancées » de Windows et de Linux aujourd'hui, on se marre. Néanmoins de nos jours le réseau est considéré comme un compostant standard d'un environnement desktop (plus seulement des serveurs). Pour demain, ce sera IPv6 (Vista le supporte assez mal, parrait-il, sans même parler d'IPsec, Linux a une pile très avancée qui suit quasiment les derniers drafts de RFC au fure et à mesure).
- Un OS multiutilisateur, et un OS utilisant la MMU pour isoler les processus, même sur le desktop. Ok Windows a fini par le faire (mais le multiutilisateur quand presque tout est prévu pour fonctionner à la souris en premier lieu...). Rappelez vous de la « puissance du desktop » Win95. Le fonctionnement multiutilisateur est un élément complètement naturel sous Linux, dès le début, cependant que Microsoft en est encore à batailler pour désapprendre à ses utilisateurs à tout faire tourner en root (en « administrateur », pardon), et sortir des bouts de gui du noyau, c'est dire le chemin restant.
- Le support d'architectures 64 bits. Ça fait pas mal d'années que le « desktop Linux » tourne en 64 bits. Résultat, virtuellement toutes les applis fonctionnent en 64bits sur x86_64 Microsoft n'y arrivera sans doute pas avant longtemps (puisque, notamment, ils n'ont pas habitué les éditeurs tiers à supporter cette architecture : drivers manquants, applications pas portées, cercle vicieux du manque d'utilisateurs qui switchent et donc des éditeurs de logiciels peut encouragés : à mon avis il manquera pendant longtemps des composants cruciaux pour que le bureau Windows 64b soit viable, bien que dés à présent quasiment toutes les CPU x86 pour le desktop peuvent fonctionner en 64bits).
- Une pile SCSI bien soignée. Ça c'était très « serveur » il y a peu, mais aujourd'hui c'est mis à profit et réutilisé pour la gestion du très grand public SATA (et même le PATA en fait) sous Linux. Les développements « serveurs » ont fini par profiter au « desktop ».
- Les gestionnaires de volumes disques (Le LVM). Là encore, une fonctionnalité qui vient des systèmes unix (Linux était assez en retard par rapport à HP-UX ou AIX). L'utilisation « desktop » de LVM est en train d'être redécouverte (chiffrement de volumes/partitions, redimentionnement transparent, snapshots en guise de sauvegardes/"way back machine", ...).
- Le RAID. Une fonctionnalité « très serveur » qu'on trouve désormais salement implémentée en semi-hard sur la plupart des cartes mères desktop, je ne sait pas trop pourquoi d'ailleurs (heureusement, on a une vraie implémentation logicielle dans le noyau qui vaut bien mieux que ça).
- Patches temps réel, high resolution timers, dynticks : ça c'est plutôt l'influence de l'embarqué industriel que celle des serveurs, et c'est pas encore totalement mergé, mais ça fera une sacrée différence sur le « desktop Linux » (lorsque les patchs realtime seront intégrés, le noyau par défaut offrira, pour le traitement de signal/multimédia, une latence extraordinairement faible).
- ...
Donc oui, du gros travail est fait pour les fonctionnalités serveur, et oui, les mainteneurs de Linux sont exigeants là dessus. Mais si, ça profite et profitera au « desktop ». C'est bien l'intérêt d'avoir un noyau qui cherche le « one size fit all », de l'embarqué sur téléphone aux très grands clusters du top500.org.
C'est autre chose qu'un OS où les dirigeants et décideurs sont des services commerciaux, marketing, des actionnaires, où l'on s'impose de conserver une compatibilité arrière avec un ancêtre calamiteux parce que le marché importe plus que la rationalité technique, où l'on est prét à tout dupliquer, réinventer la roue, empiler les quick hacks (bonjour, OpenXML) pour sortir la fonctionnalité wizz bang desktop plus vite, où l'on réimplémente tout pour chaque plateforme un peu différente (Windows CE pour ARM/MIPS, un fork de NT sur ppc pour la xobx, ...). C'est du long terme, quoi. Et on a une terrible avance, les amis :)
Les performances du scheduler en terme d'intéractivité, ce n'est pas tout.
(ps: mais pour être honnête, si l'on compare le merdier de l'audio et des pilotes 3D sous Linux avec ce que font Windows et Mac, on n'est pas au point).
[ Répondre ]
Re: Super interview
> why does it take longer than ever for our computers to start, for the applications to start and so on?
En grande partie parce que, si les performances des CPU, la vitesse des bus mémoire et ATA, la quantité de mémoire vive, la capacité de stockage, les fonctionnalités (donc la taille) des logiciels ont considérablement augmenté, la rapidité des disques durs, elle, à quasiment stagné. La rapidité des disques durs a un rôle considérable dans le temps de démarrage des application ou de l'OS.
En somme nous subissons les conséquences d'une évolution peu harmonieuse des systèmes informatiques (matériel et logiciel). Ici, l'ordonancement des entrées/sorties, les caches, les queues d'accès disques, le prelinking et l'éditeur de liens dynamique, les systèmes de fichiers, etc. sont certainement plus cruciaux que le bon ordonancement des processus (CPU).
Il me semble que la vitesse et le débit des disques durs grand public (pas SCSI) n'ont même pas doublé en 10 ans.
[ Répondre ]
Les « mérites » de l'ordonanceur de MS Windows [was Re: BSD ]
> [mode mauvaise langue]Même pour MS ça leur fait un scheduler de moins à repomper...)[/mode]
À ce sujet, et parce que j'ai lu plus haut des remarque laissant entendre que le noyau (ou seulement l'ordonanceur ?) de Windows était meilleur que celui de Linux, une petite info pour relativiser.
Il est tout à fait clair que les développeurs du noyau Linux essaient de trouver un ordonanceur CPU (mais aussi un ordonanceur pour les E/S, ce qui est encore plus important) qui marche le mieux possible pour tout le monde, y compris les desktops et les serveurs, de façon propre, maintenable et globale. Donc pas de hacks/cochonneries, bien que ce soit facile et tentant d'en introduire à ce niveau.
Voici comment Windows (et Solaris) s'y prend, selon la description du développeur de l'ordonanceur « ULE » de FreeBSD, Jeff Robberson :
« Solaris and windows actually both hook into the window manager. The window manager tells the scheduler which x task or windows application is in the foreground. The scheduler then uses this to give an extra boost to those tasks. » (source : http://jeffr-tech.livejournal.com/6602.html ).
Ou, si vous préferez une source plus officielle ( http://www.microsoft.com/mspress/books/sampchap/4354c.aspx ) : « The foreground process is the process that owns the thread that owns the window that's in focus. When the foreground window changes to one owned by a thread in a process higher than the Idle priority class, the Win32 subsystem changes the quantum values for all the threads in that process [...] » (etc., lire le reste de la page).
En bref et en français: le noyau Windows ne « devine » pas vraiment quelles sont les taches interactives à privilégier. L'environnement graphique de Windows indique au noyau le processus dont la fenêtre graphique a le focus, pour que le noyau lui donne une plus grande priorité.
C'est pour le moins inélégant, et c'est une solution à courte vue pour améliorer l'interactivité en environnement graphique fenêtré (windows...), qui n'améliorera en rien le fonctionnement sur des serveurs, par exemple (à l'inverse d'une solution totalement algorithmique pour trouver quel processus mérite du temps CPU sans sale hack, comme Linux essaie de faire) ! Et ce n'est certainement pas adapté à un environment souple et non-monolhitique comme Linux, où l'environement/interface utilisateur n'est pas un « builtin » indélogeable, mais peut être de natures très différentes, nativement réseau et multiutilisateur (X11, protocole X en réseau, console, framebuffer, qtpe, tinyx, ...: il faudrait implémenter ce sale hack partout, et en pondérant l'usage simultané de plusieurs d'entre eux ou par plusieurs utilisateurs, et faire transiter une telle information sur le réseau,...).
Remarquez que l'idée n'est pas neuve : https://db.usenix.org/publications/library/proceedings/cinci(...)
[ Répondre ]
Re: Regrettable
>> 3) Mais les autres développeurs n'incorporent pas son code en mainline car ils se fichent complètement des performances desktop
> Ce qui est faux. Beaucoup (peut-être insuffisament) a été fait pour les performances du desktop.
Et aussi, dans cette interview, Kolivas glisse parfois de ses préoccupations particulières vers un jugement d'ordre très général concernant, pour résumer, « la qualité du desktop sous Linux pour l'utilisateur lambda ». Or son travail porte essentiellement sur un aspect très spécifique de « l'expérience desktop », à savoir les rapports entre la latence et l'intéractivité. C'est une dimension très importante, mais est-ce tout ? est-ce seulement l'essentiel ?
De ce que je peut entendre et lire (par exemple sur linuxfr), il me semble franchement que les utilisateurs finaux de desktops sous Linux sont bien plus souvent préoccupés par les problèmes de support du matériel (cartes graphiques et accélération 3D, cartes wifi, imprimantes, webcams, ...) ou de codecs, que du punch de leur ordonanceur. (évaluation herodiade, certifiée "à la louche"(c) ;-).
Il est même peut-être hasardeux de réduire la question des « performances desktop » à l'ordonanceur ou au pré-chargement de la mémoire virtuelle (par exemple ce n'est pas forcément ce qui compte le plus pour les « performances » du rendu 3D d'un jeux, ou le décodage d'un flux h264, ...). L'interactivité a en outre le désavantage d'être difficile à mesurer (ce qui explique surement une bonne part de ce que Kolivas considère comme un manque d'intérêt des autres développeurs pour son travail, il le reconnaît mais sous-estime peut-être un peu l'influence de ce facteur sur les décisions).
> Notons que Xen a été refusé (il n'y a qu'une partie de Xen qui vient d'être accèptée)
Quelqu'un aurait plus d'infos sur les projets de merge / l'état d'avancement de la partie restante (si je ne me trompe, c'est tout le support pour dom0 qui n'est pas entré durant la fenêtre des gros merges du 2.6.23) ?
[ Répondre ]
[ Précédent :: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 :: Suivant ]
Cette page a été générée par Templeet en 0.0921s (dont 0.011 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Tu es peu informé...
Tu semble avoir fort mal compris le problème.
Tu devrais vraiment te renseigner avant de lancer d'aussi abominables trolls de ton chapeau.
Si le code de Sam Leffler (dev de Broadcom et FreeBSD) est bien sous double licence, l'ath reverse-engeneeré par Reyk Floeter (du projet OpenBSD) n'est pas dual licencé !.
La seule licence utilisé par Reyk (la licence ISC, une BSD simplifiée) stipule quand même noir sur blanc (enfin, selon la couleur de ton term) :
ref.: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/ar5xxx.(...)
Je grasse. Comment un développeur peut croire qu'il peut se permettre d'enlever cette licence du fichier et y coller une autre licence à la place ?!
(Je passe sur toute la partie « opinion » de ton troll - tu gagnerai cependant à connaitre un peu l'histoire mouvementé du hal reverse-engeneeré par Reyk, pour te faire une idée plus informée - et ça n'est pas trop intéressant pour moi de débattre avec quelqu'un avec une opinion toute faite avant d'être informé).
[ Répondre ]