GeneralZod a écrit 2316 commentaires

libvirt c'est avant-tout une couche d'abstraction, ça permet aux entreprises de gérer avec les mêmes outils (virt-manager, virsh etc ...)des solutions de virtualisations aussi diverses que Xen, KVM, OpenVZ, LXC etc ...
libvirt c'est une API stable à long terme, c'est une intégration poussée avec avahi, policyKit, gestion à distance etc ... C'est également virtio qui offre un accès aux périphériques de stockage et réseaux aux systèmes invités équivalent en performance aux VMWare guest tools ou les pilotes paravirtualisés Xen. L'émulation des périphériques d'I/O était quand même le goulot d'étranglement des solutions de virtualisations libres comme Qemu et KVM.
Pour RedHat, cela permet de garantir une certaine indépendance vis à vis de la solution de virtualisation proposé (Xen -> KVM).
Pour l'administrateur, gérer plusieurs solutions de virtualisation avec un seul outil et non pas une dizaine qui ont des approches très différentes. Couplé avec avahi et func (pas encore dans RHEL il me semble), on arrive à faire des trucs assez sympa dans des parcs.

Pour répondre à ta question, pour le moment non.

> Au risque d'en faire bondir certains, c'est finalement pour un PDA avec Windows Mobile ou un Apple iPhone que c'est le plus facile de développer des logiciels libres.

Moi, ça ne me fait pas bondir pour la simple raison que c'est vrai. Enfin, c'est pas les environnements libres qui manquent entre Android, LiMo, OpenMoko, Symbian etc ... J'espère que linux powered ou pas, webOS s'ouvrira ou crèvera avec les autres OS propriétaires.
Rien n'est plus chiant pour les développeurs et les utilisateurs qu'une balkanisation des systèmes.

> le développeur n'a visiblement même pas réfléchi à leur pertinence.
Normal, puisque l'application ne fait que scanner les services présents et récupérer les infos à sa disposition. Ce n'est pas le boulot du développeur de s-c-s de s'occuper de ça.
Je te recommande la lecture du blog de Richard Hugues, c'est un bon exemple (ici PackageKit) de la difficulté de réaliser une IHM cohérente et du choix des textes d'accompagnement. C'est le boulot des ergonomes et des équipes de régionnalisation (qui manquent cruellement de petites mains au passage).
Si tu t'en branle, merci de garder tes commentaires douteux pour toi.

Je te conseille de jeter un coup d'oeil dans les messages d'alertes et les traductions d'Ubuntu, y a de quoi se taper un fou rire pendant un moment.
http://blog.racoon97.net/wp-content/uploads/2008/08/zattoo1-(...)
(Je t'épargne le très classique message qui dit que GParted est une arme de destruction massive).

C'est drôle, je me suis dis la même chose de ton message.
Sinon, dans la vraie vie, ça ne semble pas perturber l'utilisateur de base. La plupart ne farfouillent pas dans les services, et quand ils ont a le faire, c'est juste pour démarrer/arrêter un service.
Si ta seule critique porte sur le texte explicatif, c'est un peu faiblard, je suis sûr que le mainteneur sera ravi si tu lui proposes des descriptifs plus parlants. Tu le reconnais implicitement, toutes les fonctionnalités attendues sont présentes.
C'est du logiciel libre et libre à toi d'apporter ta pierre.

Ça ressemble comme deux gouttes d'eau à Growl (framework libre de notification assez sympathique sous MacOS X), il aurait pu avoir l'élégance de le citer. Tout ça pour se faire mousser comme le créateur des "notifications cool" ....

Voici le point d'un vue d'un développeur GNOME invité à l'Ubuntu Developer Summit:
http://blogs.gnome.org/desrt/2008/12/14/uds/
Visiblement, ils ont discuté avec Christian Hammond, le mainteneur de libnotify (la lib de notification FreeDesktop) et miracle, ils sont arrivés à ça:
>> canonical’s changes are going upstream this cycle

Enfin, la première contribution concrète d'Ubuntu pour le bureau libre et pour une fois, ce sera fait en upstream ! Formidable, faut continuer dans ce sens, les mecs !

Un passage savoureux qui montre bien l'importance et la génialité de cette idée pour Mark S.
>> by the end of the week many of us were refering to uds as “nbs: notification bikeshed summit”. in a way, it was a little bit demotivating to spend so much time talking on this subject.

ça se passe de commentaires.

system-config-services simple, efficace.
ça ressemble à ça: http://bobpeers.com/img/mainpage/services.png

> qu'est-ce qui les empêche de vendre (comme RedHat) leur versions serveurs d'Ubuntu [...] avec un support ?
Rien, ils le font déjà. Par ailleurs, si on compare les offres professionnelles de support de RedHat/Canonical/Novell, on se rends compte qu'à offre "égale", Canonical est nettement plus cher que les deux autres pour une qualité de support moindre, le moins cher étant Novell.
http://www.canonical.com/services/support
https://www.redhat.com/wapps/storehttps://www.redhat.com/wap(...)
// ils ont encore changé les liens chez Novell, j'ai la flemme de les retrouver.


> la politique actuelle de Canonical ne semble pas vraiment avoir pour but de générer de gros profits.

J'aurais tendance à appuyer sur le "actuelle".
L'existence de Canonical suffit à démontrer que Mark S. ne s'est pas lancé dans l'aventure Ubuntu juste pour le fun (sinon il aurait continué son mécénat via sa fondation).
On sent même une certaine impatience à générer des profits après 4/5 ans de vaches maigres. On peut citer, un réalignement de la politique commerciale de Canonical vers les serveurs, le problème du desktop étant que les particuliers ont tendance à préférer l'offre gratuite (Mandriva en fait l'expérience avec le Club, les versions boites et ça n'a pas marché).
Sans oublier, les déclarations agressives de Mark S. vis à vis des autres distributions (on se remémorera l'impair commis avec OpenSuSE), la volonté de synchroniser les distros et les gros projets sur le cycle d'Ubuntu alors que dès le départ Canonical ne participe pas ou peu en upstream.
Ça donne plutôt l'impression qu'il a compris que le morceau était trop gros pour lui. Et comme il est loin d'être stupide, il préfère équilibrer les comptes d'une boite qui lui fait perdre de l'argent sans perspective réelle à court et moyen terme d'en gagner (succès en demi-teinte du partenariat Dell, la fin du partenariat privilégié avec Intel sur Moblin etc ...)

Il y a un réel potentiel dans Ubuntu, et la prochaine étape consistera probablement à ouvrir le capital (je ne suis pas certain que Mark S. acceptera de perdre seul de l'argent pendant 4/5 autres années), et à s'ouvrir un peu plus à l'upstream.
Le fait de partager en upstream, ne rendra pas Canonical moins concurrentiel comme semble le croire l'équipe dirigeante actuelle mais bien au contraire de capitaliser une expertise précieuse (penser vente de support, amélioration substantielle de l'offre).

Le bug #666 est marrant
https://bugs.edge.launchpad.net/ubuntu/+bug/666

Il était en démo dans le stand Palm au CES, de plus, le SDK Mojo est accessible en pré-release privée.

Effectivement, il n'y a aucune annonce officielle à ce sujet sur le site de Palm ou lors de la conférence. Visiblement, l'information proviendrait des employés de Palm dans le carré VIP.
Le fait que les applications PalmOS ne seront pas supportés, la rapidité de développement, laisse à penser que c'est le cas.
http://techpulse360.com/2009/01/09/palm-webos-is-a-linux-int(...)

C'est pour ça alors que les publicitaires nous foutent du moby dans toutes les pubs.

N'empêche, la plateforme Mono attire une communauté de développeurs et se retrouve dans de vrais projets commerciaux.
Tu as beau tourner en dérision ces jeux, mais ça contredit totalement ta théorie selon laquelle aucun "décideur pressé" ne recommenderais Mono.

> c'est le trio HTML/CSS/Javascript qui est utilisé avec bases de données locales, stockage de fichiers, tout pareil comme avant...
Mais, je suis bien d'accord (les applications web utilisable offline sont légions), apparemment on ne sait pas bien compris.

ça reste limité, pas d'accès à l'accélération matérielle (ie: OpenGL, OpenCL), pas d'accès aux périphériques (caméra, bluetooth, microphone etc ...), pas d'accès aux fonctionnalités avancées (fais-moi un logiciel de prise de note compatible ODF uniquement en javascript).
À moins de fournir des bindings javascript qui seront tout sauf portables et encore moins standards, j'ai du mal à le concevoir.
Pou ceux qui douterait de la viabilité d'un seul SDK basé sur les technologies du web, je recommande d'étudier le cas iPhone et les réactions des développeurs (entre autre Will Shipley, John Carmack etc ...).

Il sortira quasiment 2 ans après l'iPhone, un an après les premiers smartphones Android, sans oublier LiMo (soutenu par Motorola, Samsung, LG, Nec etc...) qui prévoient des smartphones LiMo, Nokia avec Symbian, Qt etc ... Il ne bénéficiera pas de l'effet de surprise, il sera en concurrence frontale avec des offres plus matures et nettement plus attractives pour les développeurs. Je ne parierai pas sur le succès de cet appareil malgré toutes ses qualités, au mieux, Palm se remet au niveau de la concurrence.


Il est troublant de voir à quel point, Jon Rubinstein (actuel CEO de Palm Inc) s'inspire la stratégie de Steve Jobs (et il ne s'en cache pas). Dès son arrivée, il a stoppé bon nombre de projets dont le Foleo (une erreur impardonnable), il a fait le grand nettoyage dans son équipe (souvent remplacés par des anciens d'Apple), lancé un iphone-like. Il va même jusqu'à copier les erreurs commise par Apple (absence de SDK natif, environnement fermé limite "carcéral" comme l'iPhone).
C'est bien de s'inspirer des recettes qui marchent, mais ça demande un minimum d'esprit critique et de souplesse: Palm n'est pas Apple et Apple commets pas mal d'erreurs.

Palm essaie probablement de se relancer mais ça ressemble drolement au chant du cygne.
Plusieurs décisions contradictoires:
* On se débarasse du département de développement logiciel pour 3 ans après, redévelopper un nouveau système.
* Palm a complétement raté la révolution du NetBook avec Foleo. Beaucoup de communication autour, un produit prêt à être commercialisé et on annule tout à la dernière minute.
Résultat, Asus s'est assuré une position privilégié dans un marché en plein expansion, une position qui aurait pu être celle de Palm.
* le complexe propriétaire: alors que la plupart des constructeurs essaient de mutualiser les ressources autour de systèmes basés sur du logiciel libres (LiMo, Android, Symbian, Qt etc ...), Palm décide de créer un énième système qui n'apporte rien de spécial et qui est fermé.
C'est un coup d'épée dans l'eau, le matériel est alléchant, il y a de bonnes idées au niveau de l'interface mais c'est soit trop tard, soit pas assez.


> elles reposent sur les standards du web, donc (X)HTML, CSS et Javascript, JSON, choix judicieux de la part de Palm.
à en croire, l'expérience de l'iPhone, pas tant que ça, les développeurs ont râlés pendant des mois pour avoir un vrai SDK. D'une part, les possibilités sont très restreintes, d'autre part ça demande souvent la disponibilité d'un réseau 3G ou WiFi qui sont loin d'être présent partout.
Le succès du SDK non-officiel a obligé Apple à fournir son propre SDK, c'est dire à quel point la pression était forte.

Si tu lis Monologue aujourd'hui (bref Planet Mono), tu apprendras que le premier jeu Wii basé sur Mono est en vente, qu'il y a une multitude de jeux pour iPhone utilisant Mono.

Certes Mono n'a aucune chance sur plateforme Windows face à .Net, mais il reste un champ d'action très large pour Mono (embarqué, multiplateformes, vidéo-ludique etc)
http://www.mono-project.com/Companies_Using_Mono

Certes, mais ils font quant même partie de la toolbox du développeur Gtk+, Gtk+ s'appuie principalement sur les primitives de dessins de Cairo (le GDK fournit des fonctions d'interopérabilité avec Cairo), et libxml2 c'est le parseur xml du projet GNOME. ;-)
Si il n'y a pas de wrappers GObject, c'est que d'une part, l'utilité ne s'est pas fait sentir, d'autre part pour des raisons de performances. Par exemple, GStreamer utilise en interne GstMiniObject (GObject moins les fonctionnalités inutiles pour GStreamer) et non GObject comme classe de base pour des raisons de performances.

> Qt est très bien séparé en module et les modules sont tous indépendants.
Seulement depuis Qt4, c'était beaucoup moins drôle avec Qt3.
Ce que je voulais dire, c'est qu'il est plus facile d'introduire dans un projet une bibliothèque GObject qu'une bibliothèque Qt même si c'est faisable.

QtCore c'est du C++ et même pas du C++ standard, et RMS a décidé que GNU serait codé en C (avec un coding style tout pourri inspiré du Lisp) point barre.

C'est effectivement étrange, pourquoi ce refus de la LGPL ? Confusion avec la GPL ? frilosité ? absence de support ?

Je ne vois pas le problème la LGPL étant 100% compatible avec la GPL. Le seul truc serait qu'un port de la VCL (le toolkit d'OOo, à ne pas confondre avec le machin de Borland) vers Qt4 aurait été sous GPL (et là encore, je ne vois pas le problème).
Néanmoins, je vois pas vraiment l'intérêt de ce port, OOo est une usine à gaz, KOffice 2.0 (ainsi que la plupart des applications KDE4) est censé être multiplateforme et Qt 4.5 intégrera un support d'OpenDocument (Suffisant pour écrire un mini-traitement de texte sur plateforme mobile ;o) ). Quant à l'intégration visuelle, il y a le moteur de style gtk-qt ou on peut opter pour QGtkStyle.
Même en chargeant les libs KDE4, KOffice 2.0 reste moins lourdingue qu'OOo

La comparaison Gtk+/Qt est à la fois non pertinente et pertinente.
Non pertinente, parce que l'équivalent de Qt c'est GLib/Cairo/Gtk+/GStreamer/GtkWebKit/libxml2 etc ...
Pertinente, car si Qt est un framework unifié maintenue par une entité (Qt Software), on peut considérer que l'ensemble des bibliothèques autour de Gtk+ constituent un framework à part entière dont le ciment est GObject et qui offre (en pratique) également une vraie cohérence.

Moi, j'apprécie les 2 plateformes, la première pour son côté tout-en-un (framework extrêmement complet, outils associés performants), la seconde pour la possibilité de réutiliser séparément les différents composants, son dynamisme (D-Bus, Telepathy, GEGL, Gnome-Scan etc ...).
La différence principale c'est le modèle de développement, Qt est clairement une cathédrale (et une magnifique!), alors que Gtk+ & cie c'est le bazar. Chaque modèle à ses qualités et défauts, et Qt s'ouvre un peu plus au bazar.

Il doit s'en battre les roubignoles:
1. la licence GPL est conservée.
2. la licence LGPL reste une licence GNU.
3. même si la LGPL est moins appréciée que sa grande soeur la GPL, c'est considéré comme un mal nécessaire pour permettre l'interopérabilité entre le libre et le propriétaire.
4. RMS cherche à créer un écosystème libre auto-suffisant et utilisable par tous, et non pas à exterminer le logiciel propriétaire.

Pour la plupart des entreprises, la licence LGPL passe relativement bien. Contrairement à Qt Extended, très peu d'entreprises ont besoin de patcher Qt, et encore moins ont d'intérêts à ne pas publier ses patchs.
Pour les plus réfractaires, Qt offre toujours une licence commerciale.
Personnellement, je suis curieux de savoir si Qt Software compte libérer tout les add-ons (notamment ActiveQt, ou bien l'intégration à Visual Studio), qui propulserait encore plus l'adoption de Qt.

Et encore, je parie qu'ils ont foutu la JVM proprio de Sun et non pas OpenJDK ...

Perso, j'ai du mal à voir comment ils feraient pour limiter l'OS aux seules machines Apple.
Les sources mises à disposition du public compilent et tournent sur n'importe quelle machine PPC et Intel (32/64 bits) et servent même de base aux noyaux modifiés des hackintosh.

Y a pas mal de conneries qui se sont planqués dans ce post:
1. Le kernel NT a été réécrit from scratch, donc Windows NT et ses successeurs (Windows 2k, XP, Vista, Seven) n'ont pas de code provenant des antiquités cités précédemment.
Le legacy code, tu le trouves essentiellement dans des couches de compatibilité indépendantes de l'OS comme l'API Win32, les personnalités OS/2, Posix etc ...
C'est un concept repris des travaux sur les micro-noyaux comme Mach et qui permet une certaine compatibilité avec des OS Legacy voire concurrent. Tu retrouves quasiment le même système sous OS X (Cocoa, Carbon, Classic, BSD, IOKit), dans le libre avec le micro-noyau temps-réel Xenomai et les personnalités (VxWorks, Posix, pSOS+, UiTron etc ...).
C'est loin d'être con, et ça permet une transition en douceur à la fois pour les développeurs et les utilisateurs.
2. Le kernel NT est écrit en C et C++ avec des vrais bouts d'assembleurs. Idem pour WinCE.
Même aujourd'hui, on peut difficilement écrire un OS tournant sur du vrai matériel sans taper dans l'assembleur.
3. Le kernel NT a été développé sur une plateforme non-x86 avant d'être porté sur x86 afin d'assurer sa portabilité. Windows NT a existé commercialement sur x86, MIPS, PowerPC, Alpha (Windows 2k a même été porté sur Alpha), Windows XP supportait encore l'Itanium, sans compter les ports qui n'ont jamais été commercialisés (SPARC, voire même les 68000 d'après certains).
Windows NT (et ses successeurs) a été conçu pour être portable, même si les ports ont été abandonnés faute de succès commercials, il est très possible que Microsoft soit encore capable de les ressusciter comme l'a récemment fait Apple avec OS X.

Je n'aime pas plus que toi Windows et Microsoft, mais pour être crédible, il faut un minimum d'honnêté dans une critique.