GeneralZod a écrit 2316 commentaires

> Je ne sais pas ce que PySide utilise pour écrire le binding.
Un fork de QtScriptGenerator basé sur Boost.Python (d'où l'absence de support de Python 3 contrairement à PyQt), un plugin permet également de générer directement du code utilisant l'API CPython.
http://www.pyside.org/home-binding/binding-generator/

Sur la mailing-list, il avait été évoqué de remplacer Boost.Python par smoke le générateur de bindings de KDE.

> juste qu'il avait une syntaxe bien supérieure a celle de 'cout <<' en C++.
Elle est surtout "defective by design".
Les chaines C, printf, etc ... tout ça c'était l'état de l'art dans les années 70/80, depuis, les std::string et les flux C++ sont arrivés. Certes, std::string et les flux C++ ont montrés leurs limites, mais Boost (qui porte bien son nom) permet de pallier à bon nombre de ces défauts.
Pour des entrées/sorties console, tu as de moins en moins de raisons d'utiliser les antiquités hérités du C.

Quant aux toolkits modernes, ils offrent des type string adaptés (support d'unicode, capacité de formatage robuste, i18n, etc ...), souvent interopérables avec la SL (je pense à QString, mais également glib::ustring ou bien wxString).


> le concepteur de D (un langage 'réinventant' le C++) qui est un expert C++ (il a codé un compilateur C++) a fait pour D 'writef' qui est une version améliorée de printf, PAS 'cout <<'..

writef n'a récupéré de printf que la syntaxe de formatage et un nom vaguement similaire. writef est type safe, comme tu le dis Walter Bright a une grande expérience dans l'implémentation de langage de programmation. Ça reste néanmoins plus proche de ce qui se fait en C++ qu'en C (même si personnellement, je trouve que ça s'inspire plus de l'équivalent Java en beaucoup moins bordélique).
Enfin, les entrées/sorties fournies par Tango la bibliothèque standard alternative sont nettement supérieures (ironiquement, l'équivalent de writef dans Tango s'appelle Cout ...) avec des capacités de formatage proches de ce qui fait actuellement (Boost.Format, QString, python, C#, etc ...). Et la bibliothèque standard la plus utilisée est Tango et non pas Phobos, celle qui offre des entrées/sorties le plus proche du C++.

C'est effectivement un des cas où les flux C++ sont pas très bien adaptés.
Tu as d'autres alternatives pour les chaines formatées comme la classe autosprintf fournie avec gettext, ou bien Boost.Format qui gérent en interne leur propre flux. Best of both worlds comme on dit.
Pour revenir à Qt, la solution recommandée c'est d'utiliser la méthode arg de QString qui offre la souplesse et une sûreté de typage comparable à celle de Boost.Format.

Par ailleurs, l'utilisation de std::endl au lieu de '\n', n'est pas forcément recommandé, std::endl force le flush du buffer d'écriture, à utiliser avec modération.

> Personellement je trouve les 'cout <<' du C++ pourri et utilise a la place les printf, ce qui est très rependu..

ça montre surtout que ton niveau en C++ n'est pas très bon. Les flux C++ offrent par rapport aux entrées/sorties C la sûreté de typage, moins d'erreurs possibles (avec les % notamment), facilement extensibles avec les types utilisateurs (suffit de redéfinir les opérateurs, en C rien de comparable, bien que la GNU libc offre quelques crochets).
Encore printf ça peut passer, mais des horreurs comme scanf non.

C'est un petit cafouillage de la part de Nokia/Qt, actuellement, tu ne disposes que d'une technologie preview de Qt 4.6 pour Maemo 5 qui en gros reprend Qt/X11 + quelques extensions propres à Maemo (enfin, ça marche plutôt bien).
http://qt.nokia.com/developer/qt-for-maemo-developers
Mais le support de Maemo 5 dans Qt ne sera finalisé que courant 2010, Maemo 6 (prévu en 2011) lui sera basé sur Qt.

Certes, manque à l'appel les regex et un bout de la partie compatibilité avec C99. Mais tu as toujours en fallback l'implémentation Boost. Si tu regardes bien, tu trouveras quelques bouts de la norme C++98/03 qui ne sont pas implémentés dans libstdc++. Quant aux autres implémentations, Visual Studio/C++ Builder se base sur celle de Dinkumware qui est complète (enfin, ils ne livrent pas tout dans le cas de VS). Pour le compilo Sun, ils sont complétement à la ramasse.
La plupart des développeurs C++ ont bien accueilli TR1 et certains s'en servent quotidiennement.

> Enfin, cette librairie ira de paire avec la nouvelle norme C++ qui n'est toujours pas là..
TR1 est avant tout une extension de C++03 qui pour la plupart ne nécessite aucun changement au niveau du compilateur. L'espace de nom std::tr1 ne disparaitra pas avec l'arrivée de C++0x (même si le contenu sera également disponible dans std)

> j'ai l'impression que Qt permet de faire de nombreuses choses équivalentes à la future Technical Report 1.
Qt duplique bon nombre de fonctionnalités de la bibliothèque standard C++ (QString/std::string, Tulip/STL, etc ...) pour diverses raisons notamment historiques. Qt précéde la norme C++98 et il a fallu attendre longtemps avant que la plupart des compilateurs aient un support décent de celle-ci. Sur certaines plateformes embarqués, pas d'exceptions, pas de RTTI, pas de STL !
Je ne comprends pas pourquoi tu dis *future* TR1 ? TR1 est un ensemble de propositions d'extensions de la SL en prévision de C++0x (la plupart étant basées sur Boost) qui dans l'ensemble a été assez rapidement adopté par les vendeurs et Boost fournit même une implémentation multiplateforme.

TR1 n'est pas mort-né, ça a plutôt bien marché (on peut pas en dire autant de TR2) et c'est inclus dans C++0x.

> ça serait d'avoir la doc d'une méthode quand on utilise la complétion
Tu as accès à l'aide contextuelle via le raccourci F1 et l'aide s'affiche dans un panneau à droite.

QtCreator est un excellent IDE pour travailler avec Qt, simple et sans fioritures, perso, je travaille avec une version Git régulièrement actualisée (ça me permet d'avoir le support de mercurial entre autre).
FakeVim permet d'avoir un éditeur décent presque entièrement pilotable au clavier, mais un FakeEmacs me ferait bien plaisir.

> une tonne de libs en plus
C'est relatif, en embarqué, on se limitera souvent à un seul toolkit graphique (et encore, c'est de moins en moins le cas), sur un desktop, c'est nettement rare.
Qt n'est pas plus lourd que Gtk+, wxWidgets & cie, et en terme de dépendances, rien d'extravaguant par rapport à un GNOME vanilla.

> il y a quelques bugs (la zone d'entrée de texte qui devient noire quand on écrit, les notifications, ...)
Jamais rencontré et pas recensé chez Fedora.
https://admin.fedoraproject.org/pkgdb/packages/bugs/qt
Le seul bogue graphique était un affichage bogué dans qtdemo-qt4 lié au pilote Intel, et il a été corrigé dans Qt 4.6.

> graphiquement c'est pas super bien adapté.
Avec QGtkStyle, tu remarques à peine la différence graphiquement.
Personnellement, je trouve que les applications s'intègrent mieux dans un environnement GNOME que les applications wxWidgets qui pourtant s'appuie sur Gtk+ sous GNU/Linux.

Pas besoin de passer sous KDE pour développer en Qt, les applications Qt s'intègrent très bien à un environnement GNOME.

Un article très intéressant sur la naissance du port et l'avancement du projet mois par mois par un ingénieur de Nokia/Qt.
http://labs.trolltech.com/blogs/2009/12/01/a-brief-history-o(...)

==> sys.stdout.write('\x1b['+str(y)+';'+str(x)+'H')
print te rajoute un newline d'où l'erreur de positionnement.
Si tu tiens à utiliser print, deux méthodes:
1) Python 2.x

chaine='\x1b['+str(y)+';'+str(x)+'H'
print chaine, # pas de parenthèses, sinon l'interpréteur s'emmèle les pinceaux.

2) Python 3.x

# from __future__ import print_function # pour que ça fonctionne avec Python 2.x
print('\x1b['+str(y)+';'+str(x)+'H', end='') # on spécifie le caractère ajouté en fin de chaine par défaut c'est '\n'

éventuellement posix_fallocate ou fallocate qui mappent l'appel système fallocate. Le premier n'est pas supporté par tout les systèmes de fichiers (dans ce cas, il se contente d'écrire des zéros ce qui est nettement moins performant), le second est un appel linux-only mais n'a pas les mêmes problèmes que son homologue posix.
Dans ce cas, pas besoin de ftruncate, mais il vaut mieux prévoir large dés le départ et ensuite redimensionner son fichier.

Le commentaire d'eMerzh me semble pertinent pour ce problème
http://linuxfr.org/comments/1085943.html#1085943

C'est effectivement la bonne méthode, mais Posix offre déjà un jeu de fonctions pour définir/ajuster la taille d'un fichier ==> truncate/ftruncate

c'est surtout l'éclaireur et l'avant-garde de notre présinain bien-aimé -sic-, croire que Lefebvre n'est qu'un opportuniste est une grave erreur.
Il n'existe que pour relayer l'action présidentielle sans que le squatteur de l'Élysée n'ait à se salir les mains, un homme de paille qui servira de bouclier si ça va trop loin. Dire tout haut, ce que le nain pense tout bas, voilà le vrai rôle de Lefebvre.

Tu t'enfonces, après t'avoir traité de "crétin", maintenant je "soupçonne", je "refuse" les opinions contraires et je "projette". Toujours dans le déni, toujours pas d'argumentation.
Quand on ne peut attaquer l'argumentation, on dénigre son interlocuteur, el classico.

> Ah bon, je suis un crétin? un crétin amusé, mais tout de même, inutile de poursuivre le débat
Le débat n'est possible que si on accepte de ne pas être détenteur de la vérité universelle.
Tu prétendais corriger mes "erreurs", au final, ton argumentation était bourré d'erreurs très grossières et de détournement (volontaire ?) de mes propos. Bien évidemment, quand on ne sait plus quoi dire, on préfère se tourner vers la dérision.

> Je ne comprends pas que personne ne relève tes errreurs.
Quels erreurs ?

> Pour mettre tout le monde d'accord, c'est la défunte Caldera qui a été la première.
Caldera était basé sur Debian ? C'est le mot debian que tu n'as compris dans "concept d'une Debian simple" ?
Caldera (devenu depuis The SCO Group, spéciale dédicace à notre ami Darl McBride) utilisait RPM comme système de paquetage pour son OpenLinux.

> Concernant Mepis, elle est sorti un an avant Ubuntu, alors que l'équipe de Shuttleworth bossait déjà dessus.
La première release de Mepis a eu lieu en mai 2003, Shuttleworth a constitué son équipe à partir d'avril 2004. Do the math.
https://www.mepis.org/history
http://www.ubuntu.com/community/ubuntustory


> Knoppix est moins une distribution qu'un live-cd bourré d'outils, pas du tout pour les débutants.
Tu dois avoir la mémoire qui flanche, parce qu'à l'époque, beaucoup se servait de knoppix pour installer/configurer rapidement une Debian fonctionnelle.

> Pas du tout, reprend des CD de versions 2002-2005 tu vas voir.
Si je reprends les médias d'installation de 2003/2004, c'était le cas.

> Gnome 2 est sorti en 2002
> sorti fin 2003
GNOME2 n'a vraiment été utilisable qu'à partir de la version 2.4, mais ce n'est pas là la problématique que tu feins d'ignorer. Le noyau 2.6 est une base saine pour apporter des technologies comme udev, HAL qui étaient encore en cours d'incubation en 2003.
Mi-2004, les principaux composants permettant de constituer un bureau moderne étaient matures, tout convergeait.
Comme je le disais, un an plus tôt (fin 2003), c'était pas prêt, un an plus tard (fin 2005), tout le monde était au même niveau.

> La valeur ajoutée d'Ubuntu c'est le choix de ces trucs: quoi mettre par défaut et comment bien configurer par défaut.
La valeur ajouté par rapport à Debian.

> Quel marketing viral? il ne faut pas employer n'importe quel mot à la mode. Ils ont fait du marketing oui, mais en quoi était-il viral?
Distribution massive de goodies (CDs gratuit), invention d'une pseudo-philosophie à la con (qu'ils n'ont jamais respecté), plus tard un code de conduite (digne d'une école maternelle) des pratiques courantes du marketing viral.
Le terme viral n'est pas péjoratif ici, ça désigne une politique marketing spécifique.

> ça laisse entendre que l'équipe Ubuntu est nulle, ne fais rien, etc.
Ils ne sont certainement pas 'nuls', ils ne sont pas payés à 'rien foutre', on est bien d'accord.
En revanche, ils prennent beaucoup au libre et rendent très peu. Mis à part bazaar et upstart (qui végéte depuis quelques temps), quelle est la contribution d'Ubuntu à la communauté ? peanuts
En terme de contribution, ils sont quasi-inexistants dans GNOME, un comble pour la distribution sensée être 'leader' sur le desktop !!!!

> Ce qui est insultant pour les pointures "historiques" (venues de Debian) qui s'y trouvent.
Ce qui est insultant, la mauvaise utilisation de leur talent. Au lieu de se limiter à chier des paquets et à bricoler des patchs qui très souvent ne seront jamais upstreamés et qui auront une durée de vie courte parce que la même fonctionnalité aura été re-développé en upstream en mieux, ils seraient mieux utilisés à travailler directement dans Debian ou les projets upstreams.

Les projets upstreams, Debian gagneraient des contributeurs compétents et avanceraient plus vite, et par contre-coup Ubuntu serait gagnante.
Tu trouveras beaucoup plus de pointures issues de Debian travaillant chez Red Hat soit dit en passant.


Bref, tu devais soit-disant relever mes erreurs, mais au final, il en reste pas grand chose de pertinent. Tu t'étonnes que personne ne relève mes "erreurs", mais à aucun moment, tu ne t'es posé la question de savoir si ce n'était pas TOI qui te trompais.
Certains sont parfaitement conscients que Canonical/Ubuntu ne sont pas parfaits, qu'Ubuntu n'est pas une vraie distribution communautaire, certains vivent avec comme Jono Bacon, d'autres essaient de changer les choses de l'intérieur comme Benjamin Mako Hill ou Corey Burger.
Reste les fanboys indécrottables pour qui Canonical/Ubuntu/Mark Shuttleworth constituent la sainte trinité intouchable, pour eux, on ne peut plus grand chose.

> Redhat/Fedora Party
Pourquoi Redhat/Fedora ? et pourquoi pas Novell/OpenSuSE, Mandriva/Mandriva, ou bien Canonical/Ubuntu (probablement la moins communautaire de toute).
Si on excepte Debian, parmi les distributions citées, Fedora est très certainement celle dont le fonctionnement est le plus proche d'une gouvernance communautaire.

Faut arrêter d'accoler systèmatiquement Red Hat à Fedora, Fedora Linux est édité par la communauté Fedora, Red Hat Enterprise Linux est basé sur Fedora.
Ça fait plus de deux ans, qu'il n'y a plus de distinction entre les contributeurs, que *toutes* les décisions relatives à la distribution sont prises au sein même de Fedora. L'abandon du Core ce n'était pas pour faire joli.

De plus, ça m'étonnerait beaucoup qu'on installe des RHEL lors des install party Fedora.

> Rien ne leur empêche d'essayer de vendre la musique des majors sans DRM
Les DRM sont une condition sine qua non pour les majors, ça a pris des années pour Apple et Amazon pour obtenir la possibilité de vendre la musique sans DRM. Apple a même du concéder l'abandon du prix unique par titre alors qu'ils sont leader sur ce marché.
Si c'était si facile que ça, les boutiques en lignes indépendantes sans DRM (voire avec des formats ouverts) fleuriraient.

Visiblement, ce serait plus un partenariat commercial avec Amazon et non pas un store indépendant (donc on peut oublier le support des formats ouverts). Probablement, ça se résumera à une intégration dans un lecteur (soit Rhythmbox, soit Banshee qui est multiplateforme désormais), et Ubuntu One.
C'est pas une mauvaise idée, mais on galvaude toujours la marque Ubuntu avec des services propriétaires.

En même temps, le Canonical Store sera soit un clone de Jamendo (en terme de contenu et de format de distributions), soit un truc bourré de DRM comme les autres boutiques en ligne, voire les deux.
Canonical n'a pas le même poids qu'Apple et pourra difficilement faire avaler la couleuvre "sans DRM" aux majors.

"problème" réglé, la mise à jour arrive.
Pour ceux qui veulent les détails et l'explication:
https://www.redhat.com/archives/fedora-devel-list/2009-Novem(...)

> Disons qu'Ubuntu, en plus d'avoir bien profité de la base saine de Debian, a surtout amené une idée toute simple mais qui a fait son chemin : une application pour une tâche.

C'est surtout Mepis qui a généralisé le concept d'une Debian simple, la différence c'est que Mepis se basait sur KDE. Ubuntu a répondu à un besoin: une Debian accessible avec GNOME.
Knoppix était très populaire à un moment.

D'après mes souvenirs du temps où Mandrake s'appelait encore Mandrake et Yast était encore propriétaire, une installation par défaut des distributions précédemment cités = 1 environnement de bureau = 1 application par tâche. La seule différence, c'était la possibilité de choisir les paquets mais ça demandait une intervention de l'utilisateur.

Ubuntu coïncide avec l'arrivée de GNOME2, du noyau 2.6 et de pleins d'autres trucs qu'ils n'ont fait qu'empaqueter. Contrairement à d'autres comme SuSE ou Mandrake qui ont essuyé les plâtres, ils sont arrivés avec un bureau pas trop mal chiadé sans trop s'inquiéter de l'historique. Tu rajoutes le marketing viral, le succès était prévisible.
Ubuntu sortait un an avant ou un an après, elle n'aurait probablement pas eu le même succès.

Effectivement, ça reste dans l'esprit des system-config-tools, on facilite la vie des utilisateurs sans interférer avec une administration classique.
Pour RHEL6, je n'en sais pas plus que toi mais je pointerais le fait que les deux responsables sont deux ingénieurs de l'équipe desktop de RH et pas des moindres. ;-)

Effectivement pas d'installation dans le /home

1. ça installe uniquement les paquets signés (par défaut, les dépôts officiels)
2. effectivement, c'est limité aux utilisateurs en local (merci PolicyKit)
3. ça ne concerne QUE PackageKit, ni rpm ni yum n'installera de paquets sans identification.
Si PackageKit n'est pas installé (par ex. une installation serveur), rien à craindre.
4. ça ne constitue pas une faille de sécurité en soi (Cf point 2.), l'utilisation de sudo/gksudo reste bien plus dangereux que PackageKit/PolicyKit.
5. c'est une erreur de communication, le mainteneur de PackageKit a mis par défaut cette fonctionnalité sans communiquer l'information à ses pairs (rien dans la liste de diffusion, la roadmap, les notes de versions etc ...). D'ailleurs, la seule discussion au sujet de ce "nouveau" comportement a eu lieu sur une liste de diffusion Freedesktop, il y a plus de 6 mois.
Et comme PackageKit n'installe que les paquets signés, personne ne l'a détecté (les paquets ne sont pas signés lors du cycle de développement) avant la release.

Le problème ce n'est pas la fonctionnalité en soi, mais l'absence de réflexion commune autour.
Ce comportement ne convient pas à tout le monde, pas de débat contradictoire (les mainteneurs ont été pris de court comme vous, le débat fait rage sur fedora-devel) qui aurait permis d'affiner la fonctionnalité (création de profils -desktop,server, workstation-, intégration à un outil graphique etc ...)
Mon avis personnel c'est que cette fonctionnalité n'était pas mûre pour F12, on parle de revoir la gestion des utilisateurs pour F13 (très intéressant) avec l'intégration de PolicyKit. C'était le moment idéal pour intégrer cette fonctionnalité de PackageKit.
https://fedoraproject.org/wiki/Features/UserAccountDialog (proposition en cours de discussion pour F13)