GeneralZod a écrit 2316 commentaires

  • [^] # Re: geany

    Posté par  . En réponse au journal Le logiciel Open Source qui me donne du plaisir ..... Évalué à 2.

    Je le trouve pas spécialement exceptionnel, surtout depuis que Gedit a intégré un système de plugins.
    http://live.gnome.org/Gedit/Plugins
  • # Emacs

    Posté par  . En réponse au journal Le logiciel Open Source qui me donne du plaisir ..... Évalué à 2.

    parce je le vaux bien :o)
  • [^] # Re: KHTML n'est pas mort

    Posté par  . En réponse au journal Qt 4.4 : Version de démonstration. Évalué à 2.

    Moi, j'y vois du mépris pour les développeurs KDE qui bossent sur WebKit et un épisode de plus dans la campagne de désinformation vis à vis de WebKit.

    some prefer to team up with a shiny and mighty company as opposed to joining our multi-faceted desktop project.

    Ça c'est pas une attaque personnelle gratuite ? Et y en a d'autres.
    Comme toujours, le monde n'est pas noir ou blanc.


    > les devs qui ont fait le plus gros du travail ces dernières années.
    Personne ne dit qu'ils se sont contentés d'appliquer des patchs mais ça constitue une bonne partie de leur boulot. Mais on oublie que les développeurs KDE contribuant aujourd'hui à WebKit ont été de gros contributeurs à KHTML auparavant incluant l'auteur initial du code !
    Quant ils ont constaté que le gros du boulot était d'appliqué des patchs provenant de WebKit, ils ont préférés travailler directement sur WebKit dès qu'Apple a ouvert le développement.
    Alors c'est un peu facile de leur dire: "ouais mais ça fait un moment que vous ne contribuez plus au code (de KHTML)". Indirectement leur boulot est retombé dans KHTML, mais l'équipe actuelle feint de l'ignorer et les assimile à des "blablateurs qui en branlent pas une".

    Moi, ce qui me fait chier, c'est de voir un petit groupe verrouiller la question du moteur de rendu de KDE4 non pas pour des raisons techniques ou éthiques mais par amour-propre.
    Ce que je constate c'est que l'équipe KHTML n'a aucun véritable argument contre l'introduction de WebKit dans KDE. Personne n'ayant parlé de virer KHTML, auraient-ils tout simplement peur de la comparaison ?
    Hein, avec la technologie KParts, KDE n'a aucun problème pour gérer deux moteurs de rendu
  • [^] # Re: KHTML n'est pas mort

    Posté par  . En réponse au journal Qt 4.4 : Version de démonstration. Évalué à 2.

    Je ne suis pas d'accord avec ton analyse.
    Certes, Zack Rusin est assez hargneux dans son billet, mais il répondait à une série de billet assez agressifs vis à vis des développeurs KDE engagés dans WebKit.
    Quant à son dernier commit, il date de mars 2005 (et non pas d'il y a 4 ans). Si on se replace dans le contexte, avec un certain nombre de développeurs KDE clés comme Aaron Seigo ou Lars Knoll (mainteneur original de KHTML), George Staïkos (gros contributeur à KHTML) ont considérés sérieusement de fusionner les deux projets (Unity) après qu'apple ait décidé d'ouvrir le développement sous la pression de KDE.
    Ils ont choisi de soutenir WebKit, non pas parce sous la pression d'un éventuel employeur, mais pour de bonnes raisons (Cf le billet de Z. Rusin).
    Le gros du boulot de l'équipe KHTML s'est borné depuis quelques années à appliquer les patchs provenant de WebKit, hein.
    Même si ils ne contribuent plus à KHTML directement, les développeurs KDE contribuant à WebKit ont parfaitement leur mot à dire contrairement à ce que prétend l'équipe actuelle.

    C'est une guerre interne entre deux factions de développeurs KDE, point barre.Comme egcs ou php en son temps, le fork est meilleur que l'original, soit on est mature et on se réconcilie, soit on s'obstine. Aujourd'hui, KDE4 n'a aucune raison de privilégier KHTML à WebKit.
  • [^] # Re: En passant...

    Posté par  . En réponse au journal Matthew Szulik démissionne. Évalué à 2.

    Remarque, c'est mieux qu'avoir un siège fictif dans un paradis fiscal. ;-)
  • [^] # Re: Fedora, c'est mieux que ubuntu

    Posté par  . En réponse au journal Ubuntu a finit de manger son pain blanc ?. Évalué à 2.

    @Raphaël: une Fedora est supporté 13 mois, à partir de Fedora 8 et supérieure, les mises à jours seront supportés. Sinon, RHEL/CentOS qui sort environ tout les 18 mois dispose d'un support de 7 ans.

    De plus, le public visé par FedoraProject n'est pas le même que celui d'Ubuntu, Ubuntu se veut user-friendly, Fedora community-friendly.
    De part leurs natures et objectifs, les deux distributions ne sont pas en concurrence.
  • [^] # Re: Re:

    Posté par  . En réponse au journal Matthew Szulik démissionne. Évalué à 2.

    Le départ de M. Szulik est un test pour RH, mais comme tu le soulignes, son business-model est solide. Jim Whitehurst est un excellent gestionnaire, à lui de prouver qu'il a également du charisme et de la vision à long-terme.

    Le fait qu'il utilise Fedora montre qu'il a une connaissance des logiciels libres et qu'il n'est pas totalement déconnecté de la communauté donc pas de remous à prévoir effectivement.

    Bref, je suis plus marri par le départ prochain de M. Spevack, ça va être plus dur de lui trouver un successeur à sa hauteur. :)
  • [^] # Re: KHTML n'est pas mort

    Posté par  . En réponse au journal Qt 4.4 : Version de démonstration. Évalué à 3.

    Les principaux développeurs de KHTML ont déjà switché sur WebKit.
    http://zrusin.blogspot.com/2007/10/khtml-future.html

    De toute façon, seul le meilleur survivra, et avec le support d'Apple, de Trolltech, et de bon nombre de développeurs de KDE, il y a de fortes chances que WebKit l'emporte. KHTML était une excellente base, WebKit a permis de maximiser son potentiel et de lui donner de la visibilité.
    WebKit supporte plus de plateformes, avance plus rapidement, a été repris par nombre d'acteurs commerciaux (Nokia, Adobe, Trolltech) et sa part de marché explose. WebKit comble une bonne partie du "retard" sur Gecko.
    Vous vous rappelez de egcs/gcc ?

    En tout cas, merci et bravo à l'équipe KHTML et WebKit pour leur fantastique travail !
  • [^] # Re: Re:

    Posté par  . En réponse au journal Matthew Szulik démissionne. Évalué à 2.

    D'après Max Spevack, il semblerait que Jim Whitehurst utiliserait déjà Fedora.
    Il a quitté Delta Airlines cet été après sa non-désignation au poste de CEO malgré qu'il ait redressé la société.
    Sa bio à Delta Airlines: http://www.delta.com/about_delta/corporate_information/corpo(...)
  • [^] # Re: Trollman

    Posté par  . En réponse au journal La Flame War de l'année ?. Évalué à 2.

    Je me suis bien marré, j'ai quant même eu du mal à reconnaitre la seconde image comme un fake. :D
  • [^] # Re: Traduction

    Posté par  . En réponse au journal Matthew Szulik démissionne. Évalué à 2.

    Ça varie selon les entreprises, mais en règle générale, le conseil d'administration nomme ou renvoie la direction, supervise leurs actions et donne leurs avis sur la stratégie générale. Ils représentent les actionnaires et ont les cordons de la bourse.
    Le président lui a plus un rôle d'arbitrage et décide de l'ordre du jour.
  • [^] # Re: Enooorme !

    Posté par  . En réponse au journal La Flame War de l'année ?. Évalué à 2.

    > Fedora n'est pas dans la liste des distributions recommandées/certifiées par la FSF.
    Mais Blag Linux l'est ... Blag Linux = Fedora + paquets provenant de dépôts tiers, cherchez où est l'erreur.
    http://www.gnu.org/links/links.fr.html

    Techniquement, la FSF n'a aucun arguments contre Fedora, les derniers échanges entre la FSF et Rahul Sundaram (Community Manager) soutenaient que Fedora était même plus stricte que la FSF sur les questions des licences et brevets logiciels.
    Après, la FSF n'a jamais donné les raisons pour laquelle Fedora n'est toujours pas listé comme une distribution GNU/Linux libres.

    Insulter RMS et la FSF est inutile voire stupide, d'ailleurs la FSF n'a pas de processus formel pour "certifier" les distributions. Par contre, leurs critères de sélection des distributions libres me semblent plus que floues et obscures.

    Une des hypothèses que j'ai formulé est que la FSF ne veut pas donner l'impression de soutenir une distribution 'majeure' et garder une sorte de neutralité.
  • [^] # Re: Avec screen

    Posté par  . En réponse au journal Gvim moins bien que Vim ?. Évalué à 2.

    Euh, cream c'est une configuration de vim et gvim .... c'est pas un concurrent.
  • [^] # Re: strip

    Posté par  . En réponse au message texte visible dans une librairie dynamique. Évalué à 2.

    Plusieurs solutions qui me viennent à l'esprit :
    * obsfuquer le code. http://www.ioccc.org/
    * chiffrer le code et le déchiffrer à la volée.
  • [^] # Re: Real Time ?

    Posté par  . En réponse au message Choisir une distrbution ?. Évalué à 2.

    Vu tes besoins, un kernel-rt (PREEMPT_RT) devrait largement suffire, voire même un kernel classique bien configuré.

    Malheureusement pour le real-time sous XP ,on trouve rien a moins de 5000¤ pour le kit de dévellopement et les licences sont pas triste non plus


    +1
  • [^] # Re: trem-RT :)

    Posté par  . En réponse à la dépêche La guerre du temps réel. Évalué à 5.

    WinCE 6.0 est TOUT sauf temps-réel "dur", en tout cas, je refuse de l'utiliser dans une application "safety critical".
    Au niveau déterminisme, Linux+PREEMPT_RT est nettement plus fiable. En plus,

    Au niveau industriel, WinCE a fait une petite percée dans l'automobile avec "WinCE for automotive", Microsoft s'est associé à quelques constructeurs et équimentiers. Kuka Gbmh (fabricants de robots Allemand) propose deux solutions de virtualisation pour utiliser soit WinCE soit VxWorks en concurrence de Windows.
    Le seul avantage de WinCE sont les outils de développements et encore, un routard de l'embarqué sait générer sa chaine de cross-compilation comme un grand. :o)
  • [^] # Re: trem-RT :)

    Posté par  . En réponse à la dépêche La guerre du temps réel. Évalué à 3.

    Normalement, tu peux descendre beaucoup plus bas avec PREEMPT_RT en deça des 100µs jusqu'à 16µs (avec le kernel de l'osadl).
    Avec mon kernel de base avec le profil "voluntary preemption", j'ai des latences max de 5ms en utilisant le bench cyclictest.
  • [^] # Re: Adeos, RTAI, Xenomai

    Posté par  . En réponse à la dépêche La guerre du temps réel. Évalué à 6.

    De très bonnes solutions temps-réels même si j'ai une préférence pour Xenomai.
    D'ailleurs, Adeos a été créé par un Français Philippe Gerum (OpenWide) -également co-leader de Xenomai- sur la base d'un article de Karim Yaghmour (OperSys)
    Adeos est une solution élégante pour contourner le brevet de FSMLabs, conceptuellement c'est très proche d'un hyperviseur.

    http://home.gna.org/adeos/
    http://www.xenomai.org/index.php/Main_Page
    http://www.linuxdevices.com/articles/AT7788559732.html
  • # C'est bien mignon tout ça

    Posté par  . En réponse à la dépêche La guerre du temps réel. Évalué à 6.

    ... mais c'est de la gueguerre marketing.
    Même si les principaux architectes de kernel-rt sont certes Ingo Molnar (RedHat) et Thomas Gleixner (Linutronix - auteurs des High Resolution Timer), kernel-rt reste un effort collectif.
    Novell a mis deux développeurs sur kernel-rt : Gregory Haskins & Adam Bellay et ils sont loin d'être passifs. C'est compréhensible que RedHat n'apprécie pas de s'être fait grillé la politesse, ils ont démarré kernel-rt, et ont investi 5/6 développeurs sur le projet mais c'est du logiciel libre, faut jouer le jeu.

    Enfin, malgré que PREEMPT_RT a encore pas mal de boulot pour arriver à concurrencer les RTOS classiques, il est relativement mature. Si on est pas trop exigeant au niveau des latences, on peut arriver à du déterminisme strict.

    Pour ceux qui veulent des vrais informations sur l'état du Temps-Réel dans le noyau Linux:
    http://rt.wiki.kernel.org/index.php/Main_Page
    http://www.osadl.org/
    http://linuxdevices.com/articles/AT4991083271.html
    http://lwn.net/Articles/252716/
    http://lwn.net/Articles/248929/
    https://ols2006.108.redhat.com/
  • [^] # Re: Et oui je suis là

    Posté par  . En réponse au journal Suck my geek. Évalué à 2.

    Ou très à l'ouest ... :o)
  • # Real Time ?

    Posté par  . En réponse au message Choisir une distrbution ?. Évalué à 6.

    > Mon but est de passer mon application sous windows xp embedded c#.net +DB MSDE 2000
    > et si posssible avec du realtime. +RTLinux ?

    C'est un peu contradictoire parce-que si tu veux faire du "temps-réel" sous un OS Microsoft, t'as pas beaucoup de choix:
    * Windows + co-noyau temps-réel (type RTX)
    * Windows CE prétendument Temps-Réel "dur" (c'est surement une blague de MS, parce que WinCE 6.0 ne l'est pas du tout)
    XP Embedded c'est un Windows XP éclaté en composants, il n'a rien de temps-réel. Faire du temps-réel en C#, c'est une blague, j'espère ! ;-)

    Un noyau Linux de base devrait te suffire, tu peux également utiliser le patch PREEMPT_RT, si tu veux du temps-réel avec des latences de l'ordre de 50 à 100µs (pour info, RTX c'est de l'ordre de 1ms d'après eux).

    Si tu veux des latences plus faibles ou des échéances qui doivent être respecter impérativement pour des applications life-critical, faut passer à plus costaud: RTAI ou Xenomai (plus à jour, mieux foutu).
    Mais là, faut coder en C avec quelques précautions. Une vraie application temps-réel, ça ne se limite pas à utiliser un noyau temps-réel.

    http://www.osadl.org/
    http://rt.wiki.kernel.org/index.php/Main_Page
  • # Just Use It

    Posté par  . En réponse au journal Nokia refuse la standardisation d'OGG au sein du W3c. Évalué à 2.

    Do compelling demos. Release video in Theora format. It may be easy to use a service that provides video for you in exchange for giving them certain rights but if you want your format to succeed, then increased usage is the way.

    * extrait du blog de représentant de la MoFo
    http://www.bluishcoder.co.nz/2007/12/video-element-and-ogg-t(...)
    * résumé de la situation par Luis Vila
    http://tieguy.org/blog/2007/12/11/surfacing-from-exam-hell-b(...)

    Il ne faut pas diaboliser Nokia un peu trop rapidement. Je pense qu'accroitre la visibilité des codecs Vorbis/Theora et du conteneur ogg.
    Ça peut notamment permettre de déminer le terrain si effectivement des brevets "sous-marins" existent mais également imposer ces formats comme un standard de fait surtout si les principaux moteurs les implémentent (Gecko, WebKit, Opera etc ...)
  • [^] # Re: Explications : la crainte des brevets dormants par les grosses boite

    Posté par  . En réponse au journal Nokia refuse la standardisation d'OGG au sein du W3c. Évalué à 3.

    Je ne sais pas pour les brevets mais pour les droits des marques déposés, c'est le cas. C'est une des raisons pour laquelle Mozilla défends si âprement les marques Firefox et Thunderbird.
    http://weblogs.mozillazine.org/mitchell/archives/2004/08/i_k(...)
  • [^] # Re: Dépôts tiers

    Posté par  . En réponse au journal Problèmes d'installation des logiciels : paquets sources ?. Évalué à 4.

    En tant que membre de l'association Fedora-FR, je tiens à souligner que notre projet de documentation contient quelques tutoriels concernant la création de paquets. Le chan #fedora-devel-fr (freenode) a été créé dans l'intention d'aider les nouveaux contributeurs à rejoindre le projet en tant qu'empaqueteur, traducteur. etc...
    Il y a quelques empaqueteurs francophones de Fedora (et des bons, pas des charlots) mais également EPEL, Livna qui trainent sur ce chan et qui seront ravis de vous aider, faire des revues de paquets et vous sponsoriser.
  • [^] # Re: Evolution est maintenant utilisable

    Posté par  . En réponse au journal Comparaison des clients mails sous Linux. Évalué à 2.

    @Plop: merci de préciser qu'elle date de juin 2005 ... ;-)
    self-quote: "Citation de MDI datant d'il y a 2 ans"

    > Mais AMHA, çà ne va pas alléger le bouzin. (au moins en taille de RAM)
    Mouais, Evolution fonctionne très bien sans evolution-sharp, la plupart des plugins restent écrit en C.
    C'est une fonctionnalité destiné principalement aux entreprises, avec les bindings Mono d'OOo, le port d'Evolution sur Windows, Ximian/Novell dispose d'une solution concurrente au tryptique .Net/Outlook/MSOffice.
    C'est une stratégie qui n'est forcément stupide de la part de Novell.