Africain n'est pas une nationalité.
Patrick Baudry est né et a vécu au Cameroun (à l'époque colonie Française) donc on peut légitimement considérer que c'est le premier natif africain a être allé dans l'espace.
En revanche, Mark Shuttleworth est le premier citoyen d'un état africain et premier sud-africain dans l'espace, ce qui en soi est déjà pas si mal.
On peut également noter que Mark S. vivait régulièrement en Grande Bretagne depuis quelques années et possédait déjà la citoyenneté britannique.
> Blueprint, dans le contexte de Launchpad, désigne un item de suivi d'une fonctionnalité (de l'étape wishlist jusqu'à l'implémentation). Rien à voir avec le tirage d'épreuve ;)
Exact, mais je n'ai pas trouvé de traduction plus appropriée. :(
> Par ailleurs, le fait que Launchpad n'était pas sous licence libre ne signifiait pas pour autant qu'il était sous une licence propriétaire (...)
Un peu comme les web services de Google, mais bizarrement, je n'ai jamais rencontré personne contestant leur caractère privateur. :)
Dans le cas des applications web, le débat effectivement ne se place dans le cadre classique libre/privateur (d'où l'arrivée des licence Affero), mais dans le cadre de confier ses données à une plateforme obscure. Ça implique le code, mais également les conditions d'utilisations etc ...
La libération du code donne une garantie supplémentaire aux utilisateurs, si demain le service de Canonical flanche pour une raison où une autre, on pourra ouvrir très rapidement une autre instance de Launchpad voire créer des scripts automatisant la migration vers d'autres services/outils.
On ne va pas cacher notre joie, c'est probablement pour Canonical un grand pas en avant avec une certaine appréhension, Launchpad étant un de leur atout maitre. On ne peut que les encourager à continuer dans ce sens.
C'est une grande victoire pour les libristes, et ça n'aurait pas été possible sans les "râleurs", en tout cas, c'est pas grâce à tout les fanboys qui prétendaient que "non, Launchpad n'est pas vraiment propriétaire, il est pas distribué gnagna", ou bien "osef, Launchpad c'est trop bien".
Tu devrais plutôt remercier les "iznotgood et cie" pour avoir poussé Mark Shuttleworth à se sortir les doigts du cul.
Vu le nombre de projets libres hébergés par Launchpad, c'est avec un grand soulagement qu'on apprend sa libération. Hein, c'est pas parce qu'on tape sur Launchpad/Canonical/Ubuntu que c'est gratuit, c'est justifié derrière.
Des dizaines d'années, faut pas exagérer mais Python ne va effectivement pas disparaitre tout de suite. :o)
> le seul truc chiant finalement, c'est de trjs taper "print blah" au lieu de "print (blah)" par habitude... ;)
Pour te débarrasser de cette habitude, rajoute la ligne suivante dans tes scripts et ton PYTHONSTARTUP pour l'interpréteur interactif.
from __future__ import print_function
Désormais l'interpréteur râlera quand tu n'utiliseras pas la notation fonctionnelle. C'est radical.
Pour clarifier un peu les choses (Pour ceux qui n'ont pas suivi), unladen-swallow c'est l'implémentation Python de Google basé sur LLVM.
Effectivement, scarcity devrait être utilisé comme GC pour unladen-swallow mais étant écrit en C++, il est improbable qu'il soit inclut dans CPython.
PS: d'après Google, unladen-swallow est plus un fork "temporaire" de CPython qu'une implémentation distincte, en outre, unladen-swallow vise la compatibilité source avec CPython et ses extensions. http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
Avant de t'exciter, tu noteras qu'à aucun moment, je n'ai fait de comparaison avec Mandriva ou quelques autres distributions. Et non, ce n'était pas spécialement mon intention.
> > Google m'a donné en quelques secondes une preuve que tu ment
En 5 ans, j'ai jamais rencontré de soucis de mise en veille sous Fedora, et j'en ai vu défiler des portables.
À aucun moment, tu ne t'es dit que j'étais de bonne foi ?
> Tu sais, le suspend to ram et to disk marchent au moins depuis que je les utilises tous les jours
Si j'étais de mauvaise foi, je pourrais dire que tu mens toi aussi. https://qa.mandriva.com/show_bug.cgi?id=50337 (thanks Google)
Je te laisse le choix: on est tout deux des menteurs, soit on peut s'être trompé de bonne foi.
* rapide à charger avec un joli boot graphique (Plymouth). Très rapide pour un système desktop.
* mise en veille qui fonctionne.
* gestion des paquets RPM, efficace avec yum et packageKit.
* installation sympa et graphique. Via le livecd, c'est ultra rapide, à peine le temps d'aller aux chiottes que c'est finie.
* une collection de paquets énorme et en constante augmentation.
* communauté sympa et une bonne doc.
> Linux, le noyau, n'a certes jamais fait partie de GNU.
Je vois pas le rapport ...
À la base le projet GNU, c'est réimplémenter Unix un OS propriétaire comme Mono est une implémentation libre de .Net.
> "Si nous perdons un jour le droit d’utiliser C#, nous perdrons également ces applications."
Foutaises, le langage lui-même est standardisé, donc rien à craindre de ce côté-là.
En revanche, la partie non-standardisée du framework (Winforms, ASP.Net etc ...) pourrait du jour au lendemain disparaitre.
Mais c'est oublier que Mono offre son propre framework (Gtk#, Cocoa#, MonoTorrent, etc ...) , dans le pire des cas, on s'en passera sans problème.
De plus, comme Linux et bon nombre de projets libres Mono est protégé par l'Open Invention Network qui constitue un énorme portefeuille de brevet (IBM, Novell et ses brevets sur les web services, RedHat, etc ...) suffisant pour dissuader quiconque d'attaquer un des membres de l'OIN y compris MS.
D'ailleurs, l'accord Novell-MS prouve bien l'impuissance de MS, d'un côté ils peuvent dire "regardez, DotNet c'est multiplateforme", de l'autre "Utiliser Mono comporte des risques légaux, faut une licence mais sinon utiliser .Net sur Windows". C'est du FUD pur et simple.
RedHat n'a permis l'inclusion de Mono qu'à partir du moment où ses avocats ont jugés que le risque légal était faible. Légalement, Mono n'a plus à craindre que le noyaux linux ou d'autres projets libres.
> les distributions Linux ne devraient donc pas mettre en place Mono ou Portable.NET
Portable.Net l'implémentation de .Net par la FSF ?
À croire que ce réveil tardif de RMS est dû à la jalousie. C'est vrai Mono avance très bien contrairement à Portable.Net, il a un énorme succès notamment sur console contrairement à Portable.Net. Difficile à croire que les deux implémentations libres se couraient encore derrière il y a quelques années.
Certes Mono traine un peu derrière .Net, mais Mono tourne sur plus de plateformes, Mono innove. Finalement le singe s'est trouvé une niche très confortable.
Mono est l'implémentation d'une technologie privatrice comme l'était GNU. Comme GNU, Mono a sa vie propre vis à vis de son "modèle" privateur.
> Ahahaha la bonne blague. Ca garantie juste qu'il est utilisé, ni plus, ni moins.
Si il est très utilisé, statistiquement plus de bogues sont corrigés, et vu que Mono/GCJ/Mozilla/LLVM sont pas des branquignols, ils ont faits des rapports de bogues et même fait le patch qui va avec.
Quant au côté multiplateforme, prenons le cas de Mono. Mono compile sur de multiples plateformes matérielles x86, ppc (wii, ps3 y compris), sparc, alpha, arm (iPhone), et autant d'OS: linux, BSD, Solaris, HP-UX, OS X, merdows et partout, ils utilisent Boehm GC. Si ce n'est pas une belle preuve de portabilité, etc ...
> tu prend boehm gc, tu t'amuse a créer n threads, chacun créant m objets.
Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.
Ce n'est que mon avis mais c'est pas un peu tôt pour se lancer dans le développement d'un nouveau ramasse-miette ?
Boehm GC est utilisé par bon nombre de projets (GCJ, Mono, Mozilla, LLVM etc ...) qui garantit que le code a été intensivement testé et déverminé et sur un nombre important de plateformes.
Un nouveau ramasse-miette signifierait moins de temps pour faire avancer un langage encore très jeune, essuyer pas mal de platre. Un ramasse-miette à la fois portable, performant et bien déverminé, ça demande du temps. Plus encore, si il doit être plus complexe.
Laissons le projet avancer à son rythme, si le Boehm GC pose problème à l'évolution du langage, ce sera toujours le moment de se poser la question.
1. Oui, tu as la possibilité d'ajouter des scripts bash (ou autre langage de script) qui peuvent être exécuté avant et après installation. http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/(...)
2. À priori si tu utilises les paquets fournis par rpmfusion, tu ne devrais pas avoir de problèmes. J'éviterais d'utiliser le tarball de nvidia qui se prête très mal à cet exercice et ne bénéficie pas des améliorations de RPMFusion.
Le akmod permet également de recompiler le paquet en cas de mise à jour du noyau si celui-ci n'est pas encore disponible dans le dépôt rpmfusion. C'est intéressant à inclure dans un média d'installation. http://rpmfusion.org/Howto/nVidia http://rpmfusion.org/Package/xorg-x11-drv-nvidia#head-bf681e(...)
Fedora se prête très bien pour la création de distributions personnalisés pour une variétés de médias (CD/DVD d'installation, CD/USB live -possibilité d'installation-, machine virtuelle etc ...).
En gros, faut éditer un fichier kickstart qui te permettra de configurer la distribution (locale, selinux, services, ajout de dépôts etc ...) et les paquets à incorporer.
Tu peux utiliser comme base un des fichiers kickstarts fournis par les paquets spins-kickstarts et rpmfusion-{free, nonfree}-remix-kickstarts. Tu peux éditer le fichier kickstart à l'aide de ton éditeur préféré ou bien utiliser la GUI system-config-kickstart.
Ensuite, faut générer ton média, si c'est un CD/DVD d'installation, faut utiliser pungi, si c'est un média live, la commande livecd-creator.
Là aussi, tu disposes d'une GUI avec Revisor.
Ce sont les mêmes outils qui sont utilisé pour générer la distribution principales et ses dérivées. Rien de bien compliqué, si tu as besoin d'aide, passe sur le forum de Fedora-FR ou le chan #fedora-fr (freenode).
> Sur un test réalisé par curiosité, la création de 1'000'000+ petits objets dans une boucle est environ 2x plus rapide en ooc qu'en C++
ça montre surtout que l'allocateur mémoire par défaut de ton implémentation de C++ est une bouse pour allouer des petits objets. C'est normal, l'allocateur par défaut doit répondre à diverses problèmatiques sans (trop) sacrifier au niveau des performances.
Le ramasse-miette, la plupart du temps, alloue un pool mémoire au démarrage, il ne rend pas toujours la mémoire libéré par le programme, il peut utiliser différentes politiques, etc.
Certes, ça abaisse le niveau d'entrée pour les développeurs : c'est plus simple, plus efficace et surtout plus sûr que si ils géraient manuellement la mémoire mais ça a un surcoût parfois non négligeable (ie: machine limitée en mémoire)
Après, rien n'empêche le développeur C++ de programmer son propre allocateur mémoire (ce qui arrive très souvent en embarqué ou en programmation temps réel) pour améliorer les performances d'allocation mémoire. Mais pour le côté sûreté et simplicité des garbages collector, les dialectes C++ modernes offre des alternatives tout aussi bien sans surcoût: RAII, pointeurs intelligents avec ou sans comptage de référence, conteneurs etc ...
On n'est pas obligé de choisir entre la gestion manuelle ou automatique de la mémoire, on peut s'orienter vers une gestion semi-automatique comme en C++ ou en Objective-C qui constitue un excellent compromis.
Intrinsèquement, un ramasse miette n'est ni plus lent ni plus rapide qu'une gestion manuelle de la mémoire, ça dépends de la configuration (bcp d'allocations, petits/gros objets, ressources disponibles), ça dépends du développeur (niveau, envie de gérer la mémoire ou pas), du temps alloué au projet, du public visé etc ...
Au niveau des requêtes, tu peux utiliser le sous ensemble SQL commun à SQLite ou MySQL sans problème. Quant au code C++/Qt, t'as juste la partie connexion qui change un peu.
Rien de bien méchant, voilà ce que ça donne:
À première vue, tes tables vont dépasser la dizaine de mégaoctets (voire la centaine pour celle des consultations) donc même avec une table = une base sqlite, ça va être juste.
Dès que tu commences à titiller le gigaoctet, tu peux oublier sqlite.
Dans ton cas, je réserverais SQLite pour la phase de développement et les fonctionnalités annexes (sauvegarde, configuration, base temporaire etc ...) et en production, j'utiliserais une base de données plus costaud comme MySQL ou Postgres.
Avec la version libre de Qt, seuls les pilotes SQLite (2 et 3), MySQL, Postgres et ODBC sont présents. Pour les autres pilotes, il faut une licence obligatoirement Qt.
> tu pourras migrer vers une autre base sans difficulté (juste changé de backend).
Pas tout à fait, QtSql offre une abstraction par rapport aux APIs natives des diverses bases de données mais en aucun cas n'offre une abstraction vis à vis des dialectes SQL des bases.
Soit on utilise le dénominateur commun de chacun des dialectes SQL des bases de données supportés, soit il faudra gérer les différences manuellement.
Mais dans un premier temps, on peut se contenter effectivement d'une base SQLite qui est incluse par défaut dans Qt, mais pour un accès réseau ou concurrentiels et à partir d'un certain volume, mieux vaut passer à Postgres ou MySQL.
Effectivement, les plateformes 64 bits sont le talon d'achille de Mingw et le peu de popularité de Windows 64 n'aide pas.
Néanmoins, le projet mingw-w64 offre déjà une chaine de compilation minimale, reste à améliorer le port (notamment la partie WinAPI/DDK) et les paquets externes.
D'après le mainteneur de Mingw dans Fedora, il y a encore pas mal de trucs à régler pour que Mingw64 soit utilisable en production, même si le minimum syndical est déjà présent.
L'équipe Mingw a sorti une version de sa chaine de compilation basé sur GCC 4.4.0 il y a 2 jours. Et il y a toujours eu des builds non-officiels de basé sur GCC 4.x et qui marchaient très bien. http://sourceforge.net/forum/forum.php?forum_id=969885
Le porte-parole d'un parti politique n'a pas a être élu par le peuple, néanmoins une tradition jacobine accorde une certaine légitimité aux hommes et femmes politiques qui ont affrontés le suffrage universel.
C'est un rite de passage républicain, un Lefèbvre qui n'a jamais été élu (du moins directement) a moins de légitimité qu'un Lefèbvre élu, c'est comme ça. Tout ceux qui ont occupé une responsabilité politique sans avoir été élu se sont toujours fait descendre par les autres politiques, les médias etc ...
Certes le porte-parole n'a pas à être élu, mais il est curieux que les dirigeants d'un parti "démocratique" ne le soient pas par les militants mais désigné par le président de la République (qui dans la Vème République est supposé être au-dessus des partis).
[^] # Re: Encore un troll qui meurt !
Posté par GeneralZod . En réponse à la dépêche Launchpad libéré !. Évalué à 10.
Patrick Baudry est né et a vécu au Cameroun (à l'époque colonie Française) donc on peut légitimement considérer que c'est le premier natif africain a être allé dans l'espace.
En revanche, Mark Shuttleworth est le premier citoyen d'un état africain et premier sud-africain dans l'espace, ce qui en soi est déjà pas si mal.
On peut également noter que Mark S. vivait régulièrement en Grande Bretagne depuis quelques années et possédait déjà la citoyenneté britannique.
[^] # Re: Fix
Posté par GeneralZod . En réponse à la dépêche Launchpad libéré !. Évalué à 6.
Exact, mais je n'ai pas trouvé de traduction plus appropriée. :(
> Par ailleurs, le fait que Launchpad n'était pas sous licence libre ne signifiait pas pour autant qu'il était sous une licence propriétaire (...)
Un peu comme les web services de Google, mais bizarrement, je n'ai jamais rencontré personne contestant leur caractère privateur. :)
Dans le cas des applications web, le débat effectivement ne se place dans le cadre classique libre/privateur (d'où l'arrivée des licence Affero), mais dans le cadre de confier ses données à une plateforme obscure. Ça implique le code, mais également les conditions d'utilisations etc ...
La libération du code donne une garantie supplémentaire aux utilisateurs, si demain le service de Canonical flanche pour une raison où une autre, on pourra ouvrir très rapidement une autre instance de Launchpad voire créer des scripts automatisant la migration vers d'autres services/outils.
On ne va pas cacher notre joie, c'est probablement pour Canonical un grand pas en avant avec une certaine appréhension, Launchpad étant un de leur atout maitre. On ne peut que les encourager à continuer dans ce sens.
# "Et cie" t'emmerde !
Posté par GeneralZod . En réponse au journal Launchpad est libre. Évalué à 10.
C'est une grande victoire pour les libristes, et ça n'aurait pas été possible sans les "râleurs", en tout cas, c'est pas grâce à tout les fanboys qui prétendaient que "non, Launchpad n'est pas vraiment propriétaire, il est pas distribué gnagna", ou bien "osef, Launchpad c'est trop bien".
Tu devrais plutôt remercier les "iznotgood et cie" pour avoir poussé Mark Shuttleworth à se sortir les doigts du cul.
Vu le nombre de projets libres hébergés par Launchpad, c'est avec un grand soulagement qu'on apprend sa libération. Hein, c'est pas parce qu'on tape sur Launchpad/Canonical/Ubuntu que c'est gratuit, c'est justifié derrière.
[^] # Re: définition de l'open-source
Posté par GeneralZod . En réponse au journal Bill Gates offre au monde une leçon de physique. Évalué à 10.
Tu as finalement démissionné de Microsoft ?
[^] # Re: Gtk+ et l'accessibilité
Posté par GeneralZod . En réponse au journal Gtk+ client side windows merge. Évalué à 8.
[^] # Re: python2
Posté par GeneralZod . En réponse à la dépêche Python arrive en version 3.1. Évalué à 5.
> le seul truc chiant finalement, c'est de trjs taper "print blah" au lieu de "print (blah)" par habitude... ;)
Pour te débarrasser de cette habitude, rajoute la ligne suivante dans tes scripts et ton PYTHONSTARTUP pour l'interpréteur interactif.
from __future__ import print_function
Désormais l'interpréteur râlera quand tu n'utiliseras pas la notation fonctionnelle. C'est radical.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par GeneralZod . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
Effectivement, scarcity devrait être utilisé comme GC pour unladen-swallow mais étant écrit en C++, il est improbable qu'il soit inclut dans CPython.
PS: d'après Google, unladen-swallow est plus un fork "temporaire" de CPython qu'une implémentation distincte, en outre, unladen-swallow vise la compatibilité source avec CPython et ses extensions.
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
[^] # Re: Fedora
Posté par GeneralZod . En réponse au message Changer de distribution mais laquelle ?. Évalué à 2.
> > Google m'a donné en quelques secondes une preuve que tu ment
En 5 ans, j'ai jamais rencontré de soucis de mise en veille sous Fedora, et j'en ai vu défiler des portables.
À aucun moment, tu ne t'es dit que j'étais de bonne foi ?
> Tu sais, le suspend to ram et to disk marchent au moins depuis que je les utilises tous les jours
Si j'étais de mauvaise foi, je pourrais dire que tu mens toi aussi. https://qa.mandriva.com/show_bug.cgi?id=50337 (thanks Google)
Je te laisse le choix: on est tout deux des menteurs, soit on peut s'être trompé de bonne foi.
[^] # Re: Tomboy ?
Posté par GeneralZod . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 2.
# Fedora
Posté par GeneralZod . En réponse au message Changer de distribution mais laquelle ?. Évalué à 2.
* mise en veille qui fonctionne.
* gestion des paquets RPM, efficace avec yum et packageKit.
* installation sympa et graphique. Via le livecd, c'est ultra rapide, à peine le temps d'aller aux chiottes que c'est finie.
* une collection de paquets énorme et en constante augmentation.
* communauté sympa et une bonne doc.
[^] # Re: DotGNU Portable.Net
Posté par GeneralZod . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 3.
Je vois pas le rapport ...
À la base le projet GNU, c'est réimplémenter Unix un OS propriétaire comme Mono est une implémentation libre de .Net.
# DotGNU Portable.Net
Posté par GeneralZod . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 10.
Foutaises, le langage lui-même est standardisé, donc rien à craindre de ce côté-là.
En revanche, la partie non-standardisée du framework (Winforms, ASP.Net etc ...) pourrait du jour au lendemain disparaitre.
Mais c'est oublier que Mono offre son propre framework (Gtk#, Cocoa#, MonoTorrent, etc ...) , dans le pire des cas, on s'en passera sans problème.
De plus, comme Linux et bon nombre de projets libres Mono est protégé par l'Open Invention Network qui constitue un énorme portefeuille de brevet (IBM, Novell et ses brevets sur les web services, RedHat, etc ...) suffisant pour dissuader quiconque d'attaquer un des membres de l'OIN y compris MS.
D'ailleurs, l'accord Novell-MS prouve bien l'impuissance de MS, d'un côté ils peuvent dire "regardez, DotNet c'est multiplateforme", de l'autre "Utiliser Mono comporte des risques légaux, faut une licence mais sinon utiliser .Net sur Windows". C'est du FUD pur et simple.
RedHat n'a permis l'inclusion de Mono qu'à partir du moment où ses avocats ont jugés que le risque légal était faible. Légalement, Mono n'a plus à craindre que le noyaux linux ou d'autres projets libres.
> les distributions Linux ne devraient donc pas mettre en place Mono ou Portable.NET
Portable.Net l'implémentation de .Net par la FSF ?
À croire que ce réveil tardif de RMS est dû à la jalousie. C'est vrai Mono avance très bien contrairement à Portable.Net, il a un énorme succès notamment sur console contrairement à Portable.Net. Difficile à croire que les deux implémentations libres se couraient encore derrière il y a quelques années.
Certes Mono traine un peu derrière .Net, mais Mono tourne sur plus de plateformes, Mono innove. Finalement le singe s'est trouvé une niche très confortable.
Mono est l'implémentation d'une technologie privatrice comme l'était GNU. Comme GNU, Mono a sa vie propre vis à vis de son "modèle" privateur.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par GeneralZod . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 4.
Si il est très utilisé, statistiquement plus de bogues sont corrigés, et vu que Mono/GCJ/Mozilla/LLVM sont pas des branquignols, ils ont faits des rapports de bogues et même fait le patch qui va avec.
Quant au côté multiplateforme, prenons le cas de Mono. Mono compile sur de multiples plateformes matérielles x86, ppc (wii, ps3 y compris), sparc, alpha, arm (iPhone), et autant d'OS: linux, BSD, Solaris, HP-UX, OS X, merdows et partout, ils utilisent Boehm GC. Si ce n'est pas une belle preuve de portabilité, etc ...
> tu prend boehm gc, tu t'amuse a créer n threads, chacun créant m objets.
Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par GeneralZod . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 4.
Boehm GC est utilisé par bon nombre de projets (GCJ, Mono, Mozilla, LLVM etc ...) qui garantit que le code a été intensivement testé et déverminé et sur un nombre important de plateformes.
Un nouveau ramasse-miette signifierait moins de temps pour faire avancer un langage encore très jeune, essuyer pas mal de platre. Un ramasse-miette à la fois portable, performant et bien déverminé, ça demande du temps. Plus encore, si il doit être plus complexe.
Laissons le projet avancer à son rythme, si le Boehm GC pose problème à l'évolution du langage, ce sera toujours le moment de se poser la question.
[^] # Re: Crées ton propre Fedora spin
Posté par GeneralZod . En réponse au message Faire sa distrib avec nvidia. Évalué à 2.
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/(...)
2. À priori si tu utilises les paquets fournis par rpmfusion, tu ne devrais pas avoir de problèmes. J'éviterais d'utiliser le tarball de nvidia qui se prête très mal à cet exercice et ne bénéficie pas des améliorations de RPMFusion.
Le akmod permet également de recompiler le paquet en cas de mise à jour du noyau si celui-ci n'est pas encore disponible dans le dépôt rpmfusion. C'est intéressant à inclure dans un média d'installation.
http://rpmfusion.org/Howto/nVidia
http://rpmfusion.org/Package/xorg-x11-drv-nvidia#head-bf681e(...)
# Crées ton propre Fedora spin
Posté par GeneralZod . En réponse au message Faire sa distrib avec nvidia. Évalué à 3.
En gros, faut éditer un fichier kickstart qui te permettra de configurer la distribution (locale, selinux, services, ajout de dépôts etc ...) et les paquets à incorporer.
Tu peux utiliser comme base un des fichiers kickstarts fournis par les paquets spins-kickstarts et rpmfusion-{free, nonfree}-remix-kickstarts. Tu peux éditer le fichier kickstart à l'aide de ton éditeur préféré ou bien utiliser la GUI system-config-kickstart.
Ensuite, faut générer ton média, si c'est un CD/DVD d'installation, faut utiliser pungi, si c'est un média live, la commande livecd-creator.
Là aussi, tu disposes d'une GUI avec Revisor.
Ce sont les mêmes outils qui sont utilisé pour générer la distribution principales et ses dérivées. Rien de bien compliqué, si tu as besoin d'aide, passe sur le forum de Fedora-FR ou le chan #fedora-fr (freenode).
Quelques documentations :
* la doc de fedora-fr très complète
http://doc.fedora-fr.org/wiki/Cr%C3%A9ation_de_Live_CD/DVD_e(...)
* doc de fedoraproject
http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo
* tutoriel d'utilisation de revisor
http://www.techotopia.com/index.php/Create_Your_Own_Fedora_D(...)
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par GeneralZod . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
ça montre surtout que l'allocateur mémoire par défaut de ton implémentation de C++ est une bouse pour allouer des petits objets. C'est normal, l'allocateur par défaut doit répondre à diverses problèmatiques sans (trop) sacrifier au niveau des performances.
Le ramasse-miette, la plupart du temps, alloue un pool mémoire au démarrage, il ne rend pas toujours la mémoire libéré par le programme, il peut utiliser différentes politiques, etc.
Certes, ça abaisse le niveau d'entrée pour les développeurs : c'est plus simple, plus efficace et surtout plus sûr que si ils géraient manuellement la mémoire mais ça a un surcoût parfois non négligeable (ie: machine limitée en mémoire)
Après, rien n'empêche le développeur C++ de programmer son propre allocateur mémoire (ce qui arrive très souvent en embarqué ou en programmation temps réel) pour améliorer les performances d'allocation mémoire. Mais pour le côté sûreté et simplicité des garbages collector, les dialectes C++ modernes offre des alternatives tout aussi bien sans surcoût: RAII, pointeurs intelligents avec ou sans comptage de référence, conteneurs etc ...
On n'est pas obligé de choisir entre la gestion manuelle ou automatique de la mémoire, on peut s'orienter vers une gestion semi-automatique comme en C++ ou en Objective-C qui constitue un excellent compromis.
Intrinsèquement, un ramasse miette n'est ni plus lent ni plus rapide qu'une gestion manuelle de la mémoire, ça dépends de la configuration (bcp d'allocations, petits/gros objets, ressources disponibles), ça dépends du développeur (niveau, envie de gérer la mémoire ou pas), du temps alloué au projet, du public visé etc ...
[^] # Re: Pas d'importance
Posté par GeneralZod . En réponse au message quelle base de données choisir ave Qt. Évalué à 1.
Rien de bien méchant, voilà ce que ça donne:
QSqlDatabase db = QSqlDatabase::addDatabase( "QMYSQL" );
db.setHostName( "zorglub" );
db.setDatabaseName( "ma_base_mysql" );
db.setUserName( "mon_utilisateur" );
db.setPassword( "mon_password" );
if( !db.open() )
{
qDebug() << "Erreur : "<< db.lastError();
qFatal( "La connexion a échouée." );
}
QSqlDatabase db = QSqlDatabase::addDatabase( "QSQLITE" );
db.setDatabaseName( "ma_base_sqlite.db" );
if( !db.open() )
{
qDebug() << "Erreur : " << db.lastError();
qFatal( "La connexion a échouée." );
}
[^] # Re: Pas d'importance
Posté par GeneralZod . En réponse au message quelle base de données choisir ave Qt. Évalué à 1.
Dès que tu commences à titiller le gigaoctet, tu peux oublier sqlite.
Dans ton cas, je réserverais SQLite pour la phase de développement et les fonctionnalités annexes (sauvegarde, configuration, base temporaire etc ...) et en production, j'utiliserais une base de données plus costaud comme MySQL ou Postgres.
[^] # Re: Pas d'importance
Posté par GeneralZod . En réponse au message quelle base de données choisir ave Qt. Évalué à 2.
> tu pourras migrer vers une autre base sans difficulté (juste changé de backend).
Pas tout à fait, QtSql offre une abstraction par rapport aux APIs natives des diverses bases de données mais en aucun cas n'offre une abstraction vis à vis des dialectes SQL des bases.
Soit on utilise le dénominateur commun de chacun des dialectes SQL des bases de données supportés, soit il faudra gérer les différences manuellement.
Mais dans un premier temps, on peut se contenter effectivement d'une base SQLite qui est incluse par défaut dans Qt, mais pour un accès réseau ou concurrentiels et à partir d'un certain volume, mieux vaut passer à Postgres ou MySQL.
[^] # Re: Mingw ain't dead
Posté par GeneralZod . En réponse au journal Qt Creator 1.2 & Qt 4.5.2. Évalué à 2.
Néanmoins, le projet mingw-w64 offre déjà une chaine de compilation minimale, reste à améliorer le port (notamment la partie WinAPI/DDK) et les paquets externes.
D'après le mainteneur de Mingw dans Fedora, il y a encore pas mal de trucs à régler pour que Mingw64 soit utilisable en production, même si le minimum syndical est déjà présent.
http://mingw-w64.sourceforge.net/
# Mingw ain't dead
Posté par GeneralZod . En réponse au journal Qt Creator 1.2 & Qt 4.5.2. Évalué à 10.
http://sourceforge.net/forum/forum.php?forum_id=969885
[^] # Re: Précisions
Posté par GeneralZod . En réponse au message mise a jour. Évalué à 1.
Que veut qu'il utilise d'autres ? [1] Pour la version, je dirais Jaunty.
Pour solutionner ça, j'essaierais un apt-get dist-upgrade
[1] Avant, on aurait dit il utilise Linux 7 mais les temps ont changés, et il ne connaît probablement pas l'existence d'autres distributions.
[^] # Re: Frédéric Lefebvre
Posté par GeneralZod . En réponse au journal Albanel is out. Évalué à 3.
C'est un rite de passage républicain, un Lefèbvre qui n'a jamais été élu (du moins directement) a moins de légitimité qu'un Lefèbvre élu, c'est comme ça. Tout ceux qui ont occupé une responsabilité politique sans avoir été élu se sont toujours fait descendre par les autres politiques, les médias etc ...
Certes le porte-parole n'a pas à être élu, mais il est curieux que les dirigeants d'un parti "démocratique" ne le soient pas par les militants mais désigné par le président de la République (qui dans la Vème République est supposé être au-dessus des partis).
[^] # Re: Frédéric Lefebvre
Posté par GeneralZod . En réponse au journal Albanel is out. Évalué à 2.