La plupart des distributions majeures sont fournies avec XCB depuis un moment, Gtk+ s'appuie directement dessus. Pour les autres qui s'appuient toujours sur la XLib, celle-ci utilise en interne XCB (qui est plus bas niveau).
Si tu veux le vérifier par toi-même, utilise la commande ldd.
Les glitches graphiques d'un bureau GNOME d'il y a 2/3 ans ont disparu, mais je ne saurais dire si c'est dû à XCB ou autre chose (entre temps, Cairo est arrivé puis a bien progressé, ainsi que les toolkits) ou plus probablement à de multiples facteurs.
> Elles sont belles tes oeillères, ou alors, c'est sur le terme "claquent" qu'il y a un quiproquo, ça veut dire "se vautrent comme des loutres"?
ça veut dire qui marchent bien, et qui sont synchronisés avec les releases de Xorg.
Parce que les pilotes propriétaires, ça veut dire, pleins de bogues corrigés des mois plus tards, des libs systèmes écrasés et pleins d'emmerdes de ce genre.
> Catalyst vs. Mesa Performance With Ubuntu 10.04
En même temps, Ubuntu et leur mainteneur Xorg en papier mâché.
> Oups, contre des pilotes de 2006 quand même.
En même temps, avec cent fois moins de développeurs et parfois sans aucune documentation, on arrive à un résultat très correct.
> Donc si sur le plan technique les nvidia sont de la merde
Techniquement, c'est merdique dans le sens ou le pilote en question duplique la moitié de Xorg (leur propre gestion du multi-écran, leur propre GLX, etc ...)
Voilà, t'as des centaines de milliers de personnes (Cf smolt) qui utilisent les pilotes libres et qui en sont satisfaits.
> Ben oui, on pense à la facture de la bande passante aussi chez Google, toi tu n'as pas besoin d'y penser ce n'est pas ton argent.
La bande passante est un faux problème que les supporters de H264 agitent en épouvantail. Pour 99% des vidéos sur Youtube, à bande passante égale, on ne verra pas la différence.
Pour la VOD HD, de toute façon, personne ne passera par la balise vidéo à cause des dits problèmes de bande passante mais par le p2p, ce que font déjà certains fournisseurs de contenus.
> C'est vraiment fort de vouloir dire "politique" dès que ça ne te plait pas.
C'est pas moi qui ait racheté On2 et qui aurait pu mettre tout le monde d'accord en libérant le dernier codec de cette boite.
Choisir H264 ou Theora dans la bataille HTML5 n'est pas anodin, Google a clairement choisi son camp.
> Mouais, toi ce que tu voudrais, c'est que Google, plutôt que de payer une licence H.264 "pas chère", mette 10x plus d'argent dans le développement de Theora sans être sûr que Theora vaille le coup
Non, que Google mettent 1/10e du coût de la licence H264 dans Theora pour éliminer les derniers "obstacles" techniques. Avec les $100,000 de Mozilla, Theora a fait un bond phénoménal tout en contournant la plupart des algos brevetés.
Avec le poids de Google, Theora pourrait éventuellement rivaliser avec H264 en dehors du web.
> Anti-Googlisme primaire gonflant. A se demander des fois pourquoi Google fait le GsoC avec des râleurs pareils.
Anti-Logiciels Libres primaire gonflant. A se demander des fois pourquoi on se fait chier avec des râleurs pareils.
Le logiciel libre est une méritocratie, soit Google joue le jeu et convainc, soit ils peuvent aller se faire foutre. Google doit tout autant au libre et aux standards du web (si ce n'est plus !) que l'inverse. H264 est un retour en arrière et ne peut que mener à une balkanisation du web.
Le web constituant le pré carré de Google, le choix de supporter H264 ou Theora dans HTML5 est une décision politique qui concerne tout le monde chez eux. La décision est prise à un niveau supérieur à la division Youtube ou Open Source.
Ce billet est une tentative minable de sauver les apparences, Google ne supporte en aucun cas Theora, ni se préserve une porte de sortie. Si Google voulait sincèrement faire de Theora une alternative à H264, il faudrait investir directement dans le développement du codec et non pas dans une implémentation ARM (vous en connaissez beaucoup des sites qui tournent sur des serveurs ARM ?).
Contrairement à ce que veux faire croire Zenitram, Google a mis tout ses oeufs dans le panier H264, même si c'est appréciable comme geste, le soutien à TheorARM ne profitera qu'à la lecture sur appareils mobiles. Quid des problèmes de qualité ou de bande passante évoqués par les supporters de H264 qui soit-disant grèvent les chances de Theora ? Ça ne tient tout simplement pas debout.
Dire que cette donation de Google (qui n'égale pas les $100,000 de Mozilla dans Theora, loin de là) vise à supporter l'essor de Theora sur le web est une mauvaise blague.
Non, Google aurait très bien pu imposer Theora ou un autre codec à travers Youtube mais ils ne l'ont pas fait. Google a très clairement fait le choix de H264 au point de ne pas accepter la fondation Xiph comme organisation mentor pour le GSoC cette année (pure mesquinerie).
À mon avis, c'est une opération de communication pour redorer leur blason auprès des libristes ("regardez, on est des gentils, on finance des projets autour de Theora !"). Si ils ont choisis TheorARM, c'est probablement pour avoir une meilleure implémentation dans Android, pas pour HTML5 (qui croira que TheorARM est la première étape pour un Youtube diffusant en Theora ?)
Les béni oui-oui du H264 croient que Youtube a besoin du codec de la mort qui tue pour voir les pores des acteurs et les acariens sur leur écran. Google aurait annoncé participer à OpenVideo ou bien proposer des videos en Theora ou bien pousser un nouveau codec en libre, ça aurait une nouvelle, là c'est bullshit.
David Helgason, CEO d'Unity discute avec Apple pour savoir si effectivement Unity3D est affecté.
À priori non, puisque un projet Unity3D/iPhone est transcrit en code natif puis compilé, ça reviendrait à bannir tout ce qui ressemble de près ou de loin à pré-processeurs.
ça touitte sévère sur iPhone OS 4
==> http://twitter.com/Adobe/status/11846577063
Steve "Guru" Jobs n'a certainement pas choisi la date par hasard, je viens de voir que le lancement de CS5 (avec le générateur d'appli iPhone) est prévu pour lundi prochain. http://cs5launch.adobe.com/
MonoTouch already has an option to compile to C + XCode, just call mtouch --xcode program.exe
Il aurait utile d'avoir un lien ou un extrait portant sur la restriction en question: http://daringfireball.net/2010/04/iphone_agreement_bans_flas(...)
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Je pense que ça vise principalement la daube flache, d'une part parce que S. Jobs mène sa guéguerre personnelle contre flash et s'en touch de MonoTouch, d'autre part, ça priverait l'iPhone de la ribambelle de jeux basé sur Unity.
Le point de départ est un tweet (moins de 140 caractères) décontextualisé, c'est qui les aigris en question ? Parce qu'on est toujours l'aigri de quelqu'un d'autre, si on permettait à chacun de bannir un aigri de son choix, resterait plus personne ici.
"Ceux qui commentent sur linuxfr" ===> "ceux qui moulent sur la tribune", un raccourci trop grossier, de plus la tribune est masquée pour les non inscrits. D'ailleurs, la plupart du temps quand on qualifie DLFP de TrollFR, c'est pour pointer du doigt un commentaire à la con et pas forcément d'une moule. Puis si la tribune posait problème, a-t-on envisagé de revoir le système de modération avant ?
Dans la discussion qui a suivi ce tweet, on retrouve des citations de compétitions "Les intégristes du libre, c'est déjà pas mal, mais ceux qui sont des étudiants jamais confrontés au monde du travail, ils sont phénoménaux…". On devrait interdire l'accès du site aux libristes et aux étudiants, aussi !
Puis c'est négliger le folklore autour du site, DLFP sans les moules, ce serait comme un Solutions Linux sans le GCU squad (mauvais exemple). D'ailleurs, avec les multis, on doit arriver à moins de 30 moules.
J'ai plus l'impression qu'on cherche une bonne excuse pour supprimer la tribune, Faites-le mais sur la base d'autre chose qu'un minable tweet (en plus sapusaipalibre).
Mais heureusement que c'est trolldi aujourd'hui ! :o)
MariaDB n'est pas le seul fork opensource de MySQL, il y a aussi Drizzle. MariaDB (fork de MySQL 5.1) apporte le Maria Engine un moteur de stockage transactionnel et non-transactionnel qui vise à remplacer InnoDB (propriété d'Oracle) et MyISAM. Quant à Drizzle (fork de MySQL 6) revient aux origines: une base de données modulaire et rapide pour le web (pas de procédures stockées, triggers, vues)
La différence de rapidité entre Postgres et MySQL tient surtout à la diversité des moteurs de stockage de ce dernier, selon que tu utilise InnoDB ou MyISAM, Postgres pourra être plus rapide ou non que MySQL. Postgres peut très bien remplacer MySQL dans un cadre transactionnel, mais primo MySQL n'est pas mort, secundo, il y a MariaDB pour une transition en douceur.
Il sera intéressant de suivre l'évolution de Drizzle qui va se heurter de plein fouet aux bases NoSQL dans le domaine du web. Le M de LAMP pourrait très bien devenir un D.
Pour les versions de MySQL, la dernière version destinée à la production c'est la 5.1.45, la version de développement actuel est la 5.5 et il y a encore MySQL 6.
La numérotation de version de MySQL est très con, je te l'accorde.
J'attends avec impatience le gvt qui aura les couilles pour re-nationaliser tout ça et sans compensation (vu qu'on a déjà vendu à perte et sans contrepartie pour les citoyens ==> baisse des tarifs, réduction de la dette - ça aurait même eu l'effet contraire, l'Etat perdant des entreprises souvent profitables--).
Effectivement, très peu de personnes utilisent le mode strict.
Fedora est une distribution généraliste, donc la politique SELinux par défaut doit convenir à un maximum de personne. Le mode targeted confine les services critiques (httpd, virtualisation, mail server, database etc ....) et offre une sécurité minimale pour le reste.
Même si audit2allow facilite la tâche, le mode strict demanderait d'écrire des politiques selinux pour bon nombre de paquets (voire patcher certaines gruikeries), on peut décemment pas exiger de l'utilisateur moyen d'être un expert SELinux pour pouvoir utiliser Fedora sur un poste de travail.
Tout n'est pas rose vu que la couverture des services critiques par le mode targeted n'est pas proche de 100%, par exemple, parmi les serveurs web, il n'y a guère qu'Apache qui possède une politique SELinux.
Dans les deux cas, tu devras retravailler l'IHM.
Pour Android, si tu as bien architecturé ton application, tu peux récupérer la partie traitement et wrapper ça via JNI, mais t'auras à réécrire la partie applicative qui est très différente. Tu peux récupérer certaines bibliothèques Java quitte à les retoucher un peu (par exemple, pour le XMPP).
Je pense que ce guide devrait t'intéresser. http://developer.android.com/guide/practices/design/performa(...)
Pour l'iPhone, tu as la possibilité de réutiliser une bonne partie des bibliothèques disponibles sous Unix (Boost, GLib, SDL, Qt Core, X11, etc ...), et l'écosystème des frameworks Mac.
Pour l'IHM, Apple fournit CocoaTouch, même si il existe des efforts de portage pour différents toolkits (wxWidgets, Qt, etc ...), tu n'auras pas beaucoup le choix (excepté la SDL).
Pour un jeu basé sur la SDL, tu dois adapter la partie entrée (gestures, accéléromètre) et adapter l'affichage à la taille de l'écran. Même pas besoin de réécrire ton point d'entrée, le port iPhone fournit un délégué qui s'en charge.
Reste que l'iPhone avec toutes ses restrictions (pas de multitâches, pas de langages de scripts, SDK Mac only, licence payante pour déployer, etc ...) ce n'est pas la panacée.
En gros, le NDK offre les APIs suivantes: libc, zlib, logging, OpenGL ES, et un sous-ensemble du C++, plus JNI pour lier le code natif à ton application. Android ne supporte pas les processus natifs, bionic fournit bien les appels fork et exec* mais le noyau tue les processus non lancés par le système Android.
En comparaison, c'est bien pauvre même face à un iPhone SDK déjà bien restrictif, et le choix de JNI est débile (JNA aurait plus pertinent) car rendant la tâche plus compliqué qu'elle ne l'est déjà.
Par rapport à ta problématique, le NDK a été conçu pour permettre d'optimiser certaines routines gourmandes en calculs dont les jeux vidéos. Je soupçonne même que la seule raison d'être du NDK est d'aider le décollage d'Android dans le domaine ludique où il est particulièrement à la traine face à l'iPhone.
Le point faible du NDK, c'est le portage d'application existantes natives, même si on peut réutiliser une partie du code, ça revient à réécrire une bonne partie du code. Pour un smartphone à mi-chemin entre le téléphone et l'ordinateur portable, ça constitue un point négatif.
> Je crois en savoir sur Fedora et sa gouvernance bien plus que l'utilisateur moyen.
Je suis contributeur au projet à différents titres et ce depuis plus de 4 ans donc je connais assez bien l'évolution du projet. Et j'ai des sources de première main sur l'historique du projet Fedora pour me corriger donc bon.
> mais ne viens pas avec un chapeau bleu, tu ne seras pas crédible
Tu t'enfonces, parce que de un, c'est toi qui a parlé de chapeau rouge en premier et de deux, voilà ce que t'ai répondu: Le chapeau en question est bleu
Ça contredit nullement les propos de pingoomax. Fedora n'a jamais utilisé de chapeau rouge dans sa communication, et le chapeau bleu n'est plus utilisé pour se différencier visuellement de RH (et je vois qu'il y a encore des gens pour confondre RH et Fedora).
> envisage que tu ais expérimenté ce que je rapporte et tu comprendras
Je comprends que ce problème n'a jamais été reporté et que tu ais le seul à l'avoir eu.
* Yum n'a jamais permis ce comportement
* Pirut le gestionnaire graphique par défaut dans F9 non plus
* Yumex toujours pas
Reste PK qui avait fait son introduction dans F9 mais le comportement en question n'était même pas implémenté et il n'a été activé par défaut dans F-12 que lors d'une courte période.
La seule conclusion logique c'est soit les rayons cosmiques ont perturbés ta machine, soit plus probable, une erreur s'est glissée dans l'interface chaise-clavier.
> J'ai bien précisé la période pendant laquelle j'ai utilisé Fedora 9.
Je demande à voir, j'utilise sans interruption Fedora depuis Core 2 et je n'ai jamais observé ce comportement. La seule fois où par défaut, le mot de passe administrateur n'était pas requis pour les mises à jours c'est au tout début de F-12 dans les conditions cités précédemment et ça a été très rapidement désactivé.
> Personnellement, il m'est impossible de faire confiance à nouveau à Fedora si je veux une sécurité minimale.
Tu as tort.
> Un chapeau rouge, une origine américaine, une société commerciale derrière, ces trois éléments me suffisent désormais à fuir.
Le chapeau en question est bleu, et Fedora est construit autour d'un pacte entre la communauté et Red Hat. Depuis Fedora 7, la gouvernance du projet est assumé par la communauté mis à part l'aspect financier. Red Hat ne fait pas ce qu'elle veut dans Fedora, sans cela, il aurait été impossible de construire une communauté aussi large de contributeurs tel que Fedora.
T'as quoi, 80% des contributeurs qui bossent pas chez Red Hat et qui en ont rien foutre des chapeaux rouge et autres.
> Pour information, je peux témoigner avoir observé une baisse de performance dans la lecture/écriture de 10% par rapport à une installation sans cryptage à la volée sur cette machine
C'est normal, faut chiffrer/déchiffrer ça avant tout opération. Pareil ailleurs.
> j'avais de plus en plus d'erreurs liée à SELinux, que je corrigeais au fur et à mesure
L'outil de diagnostic est un peu lourdingue, mais c'est souvent bénins (souvent une mauvaise labelisation des répertoires, et la commande pour corriger ça est dans le diagnostic).
Les statistiques montent que 62% des utilisateurs de Fedora ont SELinux en mode enforcing, environ 8% en mode permissif donc faut relativiser sur une base d'utilisateur de plusieurs centaines de milliers d'utilisateurs.
Ça fait un moment que Fedora propose une configuration de SELinux grand public compliant.
> Voilà, c'est pas gentil pour Fedora et j'applaudis le travail réalisé, mais c'est du vécu.
Gentil ou pas, faut faire les rapports de bogues sinon on n'avance pas. :)
Un bogue, on se doit de le corriger et non pas le cacher sous le tapis. Après, si c'est pas un bogue, tu auras droit à une explication donc dans tout les cas, tu n'es pas perdant.
> sa grande surprise en lisant mon retour d'expérience sur les mises à jour (incluant un nouveau noyau qui plus est) sans exigence du mot de passe d'admin
Tu confondrais pas avec Fedora 12 ? C'était un changement de comportement dans PackageKit en upstream qui permettait d'installer les paquets (uniquement signés) sans mot de passe root, et limité aux sessions locales et pas de lancement de services.
Pour l'anecdote, le mainteneur de PK avait mentionné ce changement sur la m-l PackageKit mais pas fedora-devel, et comme les paquets ne sont pas signés dans la version de développement, personne ne s'en est rendu compte avant la release (puisque PK exigeait dès lors le mot de passe root).
Si tu te portes volontaire pour réécrire une partie BFW en Java, c'est possible. Le gros point faible de la plateforme Android c'est bien le portage des applications natives et cette sous-merde de NDK ne change pas grand chose. Idem pour Blackberry etc ...
La SDL a été porté sur Android, tu peux récupérer une partie du code natif, donc yakafocon mais ça prendra du temps.
En comparaison, le gros du travail dans le portage iPhone a été de réduire la consommation mémoire, et l'adaptation de l'IHM. Pour MeeGo, ça ne devrait pas être plus compliqué, il existe déjà un port Maemo.
> Un autre : http://connectiva.com qui a hébergé Harald Weld
Tu veux plutôt dire Conectiva et harald Welte. Conectiva avait une très belle expertise technique mais la distribution éponyme n'a jamais été une distribution spécialisé dans la sécurité à ma connaissance.
Si c'est juste le kernel qui t'intéresse, il suffit de récupérer les sources et la configuration et de recompiler ça pour ta distro. Mais le noyau MeeGo, c'est le noyau Moblin donc un noyau Vanilla + quelques patchs spécifiques.
Si MeeGo se resynchronise régulièrement sur Fedora comme feu Moblin (à priori non), ça serait très facile pour Fedora de maintenir un dépôt tiers comme on le fait avec EPEL pour RHEL/CentOS.
Fedora est la seule distribution généraliste à avoir une politique de sécurité proactive et ce par défaut (contrairement à Hardened Gentoo/Debian). http://fedoraproject.org/wiki/Security
Fedora est un contributeur important à SELinux, projet qu'il a même démocratisé (activé par défaut depuis plus de 5 ans maintenant !).
La politique de sécurité de Fedora ne se limite pas seulement à SELinux, mais également dans le renforcement de la GLibc et du format ELF (Ulrich Drepper), des patchs noyaux (Exec-shield: NX, PIE, etc ...) Les paquets sont sans exception compilés avec les flags de sécurité (ie: GCC_FORTIFY_SOURCE, fstack-protector), tout ça bien longtemps avant la plupart des autres distributions. Dans le domaine de la virtualisation, libvirt permet de sécuriser l'utilisation à distance de machines virtuelles (X.509, connexion chiffrée, etc ...)
Des fonctionnalités que Fedora promeut et souvent développe.
Au niveau du bureau, on peut rajouter PolicyKit qui offre une solution élégante à la gestion des droits utilisateurs.
Si Fedora ne peut se comparer aux distributions dédiées à la sécurité, elle est tout aussi sécurisée qu'une hardened Gentoo/Debian voire plus, les problématiques liées à la sécurité étant traitées en amont.
[^] # Re: Et XCB ?
Posté par GeneralZod . En réponse au journal Xorg 1.8: épatant ?. Évalué à 2.
Si tu veux le vérifier par toi-même, utilise la commande ldd.
Les glitches graphiques d'un bureau GNOME d'il y a 2/3 ans ont disparu, mais je ne saurais dire si c'est dû à XCB ou autre chose (entre temps, Cairo est arrivé puis a bien progressé, ainsi que les toolkits) ou plus probablement à de multiples facteurs.
[^] # Re: Argh
Posté par GeneralZod . En réponse au journal Xorg 1.8: épatant ?. Évalué à 5.
ça veut dire qui marchent bien, et qui sont synchronisés avec les releases de Xorg.
Parce que les pilotes propriétaires, ça veut dire, pleins de bogues corrigés des mois plus tards, des libs systèmes écrasés et pleins d'emmerdes de ce genre.
> Catalyst vs. Mesa Performance With Ubuntu 10.04
En même temps, Ubuntu et leur mainteneur Xorg en papier mâché.
> Oups, contre des pilotes de 2006 quand même.
En même temps, avec cent fois moins de développeurs et parfois sans aucune documentation, on arrive à un résultat très correct.
> Donc si sur le plan technique les nvidia sont de la merde
Techniquement, c'est merdique dans le sens ou le pilote en question duplique la moitié de Xorg (leur propre gestion du multi-écran, leur propre GLX, etc ...)
Voilà, t'as des centaines de milliers de personnes (Cf smolt) qui utilisent les pilotes libres et qui en sont satisfaits.
[^] # Re: Ils se moquent du monde ?
Posté par GeneralZod . En réponse au journal Google soutien Theora. Évalué à 4.
La bande passante est un faux problème que les supporters de H264 agitent en épouvantail. Pour 99% des vidéos sur Youtube, à bande passante égale, on ne verra pas la différence.
Pour la VOD HD, de toute façon, personne ne passera par la balise vidéo à cause des dits problèmes de bande passante mais par le p2p, ce que font déjà certains fournisseurs de contenus.
> C'est vraiment fort de vouloir dire "politique" dès que ça ne te plait pas.
C'est pas moi qui ait racheté On2 et qui aurait pu mettre tout le monde d'accord en libérant le dernier codec de cette boite.
Choisir H264 ou Theora dans la bataille HTML5 n'est pas anodin, Google a clairement choisi son camp.
> Mouais, toi ce que tu voudrais, c'est que Google, plutôt que de payer une licence H.264 "pas chère", mette 10x plus d'argent dans le développement de Theora sans être sûr que Theora vaille le coup
Non, que Google mettent 1/10e du coût de la licence H264 dans Theora pour éliminer les derniers "obstacles" techniques. Avec les $100,000 de Mozilla, Theora a fait un bond phénoménal tout en contournant la plupart des algos brevetés.
Avec le poids de Google, Theora pourrait éventuellement rivaliser avec H264 en dehors du web.
> Anti-Googlisme primaire gonflant. A se demander des fois pourquoi Google fait le GsoC avec des râleurs pareils.
Anti-Logiciels Libres primaire gonflant. A se demander des fois pourquoi on se fait chier avec des râleurs pareils.
Le logiciel libre est une méritocratie, soit Google joue le jeu et convainc, soit ils peuvent aller se faire foutre. Google doit tout autant au libre et aux standards du web (si ce n'est plus !) que l'inverse. H264 est un retour en arrière et ne peut que mener à une balkanisation du web.
[^] # Re: Argh
Posté par GeneralZod . En réponse au journal Xorg 1.8: épatant ?. Évalué à -7.
[^] # Re: Ils se moquent du monde ?
Posté par GeneralZod . En réponse au journal Google soutien Theora. Évalué à 2.
Ce billet est une tentative minable de sauver les apparences, Google ne supporte en aucun cas Theora, ni se préserve une porte de sortie. Si Google voulait sincèrement faire de Theora une alternative à H264, il faudrait investir directement dans le développement du codec et non pas dans une implémentation ARM (vous en connaissez beaucoup des sites qui tournent sur des serveurs ARM ?).
Contrairement à ce que veux faire croire Zenitram, Google a mis tout ses oeufs dans le panier H264, même si c'est appréciable comme geste, le soutien à TheorARM ne profitera qu'à la lecture sur appareils mobiles. Quid des problèmes de qualité ou de bande passante évoqués par les supporters de H264 qui soit-disant grèvent les chances de Theora ? Ça ne tient tout simplement pas debout.
Dire que cette donation de Google (qui n'égale pas les $100,000 de Mozilla dans Theora, loin de là) vise à supporter l'essor de Theora sur le web est une mauvaise blague.
[^] # Re: Ils se moquent du monde ?
Posté par GeneralZod . En réponse au journal Google soutien Theora. Évalué à 4.
À mon avis, c'est une opération de communication pour redorer leur blason auprès des libristes ("regardez, on est des gentils, on finance des projets autour de Theora !"). Si ils ont choisis TheorARM, c'est probablement pour avoir une meilleure implémentation dans Android, pas pour HTML5 (qui croira que TheorARM est la première étape pour un Youtube diffusant en Theora ?)
Les béni oui-oui du H264 croient que Youtube a besoin du codec de la mort qui tue pour voir les pores des acteurs et les acariens sur leur écran. Google aurait annoncé participer à OpenVideo ou bien proposer des videos en Theora ou bien pousser un nouveau codec en libre, ça aurait une nouvelle, là c'est bullshit.
[^] # Re: Le culot!
Posté par GeneralZod . En réponse au journal Free.fr crie sa misère. Évalué à 3.
[^] # Re: Plus de jeux vidéos.
Posté par GeneralZod . En réponse au journal Objective-C, C, C++, ou JavaScript uniquement sur l'iPhone OS4. Évalué à 2.
À priori non, puisque un projet Unity3D/iPhone est transcrit en code natif puis compilé, ça reviendrait à bannir tout ce qui ressemble de près ou de loin à pré-processeurs.
==> MeeGo quand il sortira.
[^] # Re: La réponse de MDI: haha, je peux générer du code natif si je veux
Posté par GeneralZod . En réponse au journal Objective-C, C, C++, ou JavaScript uniquement sur l'iPhone OS4. Évalué à 4.
==> http://twitter.com/Adobe/status/11846577063
Steve "Guru" Jobs n'a certainement pas choisi la date par hasard, je viens de voir que le lancement de CS5 (avec le générateur d'appli iPhone) est prévu pour lundi prochain.
http://cs5launch.adobe.com/
# La réponse de MDI: haha, je peux générer du code natif si je veux !
Posté par GeneralZod . En réponse au journal Objective-C, C, C++, ou JavaScript uniquement sur l'iPhone OS4. Évalué à 7.
Il aurait utile d'avoir un lien ou un extrait portant sur la restriction en question:
http://daringfireball.net/2010/04/iphone_agreement_bans_flas(...)
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Je pense que ça vise principalement la daube flache, d'une part parce que S. Jobs mène sa guéguerre personnelle contre flash et s'en touch de MonoTouch, d'autre part, ça priverait l'iPhone de la ribambelle de jeux basé sur Unity.
[^] # Re: A moi, comte, deux mots!
Posté par GeneralZod . En réponse au journal Faut-il supprimer la tribune ?. Évalué à 7.
[^] # Re: Je dit ça je dit rien ...
Posté par GeneralZod . En réponse au journal Faut-il supprimer la tribune ?. Évalué à 9.
# le raisonnement est un peu léger
Posté par GeneralZod . En réponse au journal Faut-il supprimer la tribune ?. Évalué à 3.
"Ceux qui commentent sur linuxfr" ===> "ceux qui moulent sur la tribune", un raccourci trop grossier, de plus la tribune est masquée pour les non inscrits. D'ailleurs, la plupart du temps quand on qualifie DLFP de TrollFR, c'est pour pointer du doigt un commentaire à la con et pas forcément d'une moule. Puis si la tribune posait problème, a-t-on envisagé de revoir le système de modération avant ?
Dans la discussion qui a suivi ce tweet, on retrouve des citations de compétitions "Les intégristes du libre, c'est déjà pas mal, mais ceux qui sont des étudiants jamais confrontés au monde du travail, ils sont phénoménaux…". On devrait interdire l'accès du site aux libristes et aux étudiants, aussi !
Puis c'est négliger le folklore autour du site, DLFP sans les moules, ce serait comme un Solutions Linux sans le GCU squad (mauvais exemple). D'ailleurs, avec les multis, on doit arriver à moins de 30 moules.
J'ai plus l'impression qu'on cherche une bonne excuse pour supprimer la tribune, Faites-le mais sur la base d'autre chose qu'un minable tweet (en plus sapusaipalibre).
Mais heureusement que c'est trolldi aujourd'hui ! :o)
[^] # Re: Mysql racheté
Posté par GeneralZod . En réponse au message Versions de MySQL?!?. Évalué à 2.
Tu veux parler d'Oracle Berkeley DB ==> http://www.oracle.com/technology/products/berkeley-db/index.(...)
MariaDB n'est pas le seul fork opensource de MySQL, il y a aussi Drizzle. MariaDB (fork de MySQL 5.1) apporte le Maria Engine un moteur de stockage transactionnel et non-transactionnel qui vise à remplacer InnoDB (propriété d'Oracle) et MyISAM. Quant à Drizzle (fork de MySQL 6) revient aux origines: une base de données modulaire et rapide pour le web (pas de procédures stockées, triggers, vues)
La différence de rapidité entre Postgres et MySQL tient surtout à la diversité des moteurs de stockage de ce dernier, selon que tu utilise InnoDB ou MyISAM, Postgres pourra être plus rapide ou non que MySQL. Postgres peut très bien remplacer MySQL dans un cadre transactionnel, mais primo MySQL n'est pas mort, secundo, il y a MariaDB pour une transition en douceur.
Il sera intéressant de suivre l'évolution de Drizzle qui va se heurter de plein fouet aux bases NoSQL dans le domaine du web. Le M de LAMP pourrait très bien devenir un D.
Pour les versions de MySQL, la dernière version destinée à la production c'est la 5.1.45, la version de développement actuel est la 5.5 et il y a encore MySQL 6.
La numérotation de version de MySQL est très con, je te l'accorde.
[^] # Re: Le culot!
Posté par GeneralZod . En réponse au journal Free.fr crie sa misère. Évalué à 5.
[^] # Re: Manque Fedora dans le lot
Posté par GeneralZod . En réponse à la dépêche Les distributions GNU/Linux sécurisées. Évalué à 2.
Fedora est une distribution généraliste, donc la politique SELinux par défaut doit convenir à un maximum de personne. Le mode targeted confine les services critiques (httpd, virtualisation, mail server, database etc ....) et offre une sécurité minimale pour le reste.
Même si audit2allow facilite la tâche, le mode strict demanderait d'écrire des politiques selinux pour bon nombre de paquets (voire patcher certaines gruikeries), on peut décemment pas exiger de l'utilisateur moyen d'être un expert SELinux pour pouvoir utiliser Fedora sur un poste de travail.
Tout n'est pas rose vu que la couverture des services critiques par le mode targeted n'est pas proche de 100%, par exemple, parmi les serveurs web, il n'y a guère qu'Apache qui possède une politique SELinux.
[^] # Re: Le NDK
Posté par GeneralZod . En réponse au message Programmation native sous Android ?. Évalué à 5.
Pour Android, si tu as bien architecturé ton application, tu peux récupérer la partie traitement et wrapper ça via JNI, mais t'auras à réécrire la partie applicative qui est très différente. Tu peux récupérer certaines bibliothèques Java quitte à les retoucher un peu (par exemple, pour le XMPP).
Je pense que ce guide devrait t'intéresser.
http://developer.android.com/guide/practices/design/performa(...)
Pour l'iPhone, tu as la possibilité de réutiliser une bonne partie des bibliothèques disponibles sous Unix (Boost, GLib, SDL, Qt Core, X11, etc ...), et l'écosystème des frameworks Mac.
Pour l'IHM, Apple fournit CocoaTouch, même si il existe des efforts de portage pour différents toolkits (wxWidgets, Qt, etc ...), tu n'auras pas beaucoup le choix (excepté la SDL).
Pour un jeu basé sur la SDL, tu dois adapter la partie entrée (gestures, accéléromètre) et adapter l'affichage à la taille de l'écran. Même pas besoin de réécrire ton point d'entrée, le port iPhone fournit un délégué qui s'en charge.
Reste que l'iPhone avec toutes ses restrictions (pas de multitâches, pas de langages de scripts, SDK Mac only, licence payante pour déployer, etc ...) ce n'est pas la panacée.
# Le NDK
Posté par GeneralZod . En réponse au message Programmation native sous Android ?. Évalué à 5.
En comparaison, c'est bien pauvre même face à un iPhone SDK déjà bien restrictif, et le choix de JNI est débile (JNA aurait plus pertinent) car rendant la tâche plus compliqué qu'elle ne l'est déjà.
Par rapport à ta problématique, le NDK a été conçu pour permettre d'optimiser certaines routines gourmandes en calculs dont les jeux vidéos. Je soupçonne même que la seule raison d'être du NDK est d'aider le décollage d'Android dans le domaine ludique où il est particulièrement à la traine face à l'iPhone.
Le point faible du NDK, c'est le portage d'application existantes natives, même si on peut réutiliser une partie du code, ça revient à réécrire une bonne partie du code. Pour un smartphone à mi-chemin entre le téléphone et l'ordinateur portable, ça constitue un point négatif.
[^] # Re: Manque Fedora dans le lot
Posté par GeneralZod . En réponse à la dépêche Les distributions GNU/Linux sécurisées. Évalué à 1.
Je suis contributeur au projet à différents titres et ce depuis plus de 4 ans donc je connais assez bien l'évolution du projet. Et j'ai des sources de première main sur l'historique du projet Fedora pour me corriger donc bon.
> mais ne viens pas avec un chapeau bleu, tu ne seras pas crédible
Tu t'enfonces, parce que de un, c'est toi qui a parlé de chapeau rouge en premier et de deux, voilà ce que t'ai répondu: Le chapeau en question est bleu
Ça contredit nullement les propos de pingoomax. Fedora n'a jamais utilisé de chapeau rouge dans sa communication, et le chapeau bleu n'est plus utilisé pour se différencier visuellement de RH (et je vois qu'il y a encore des gens pour confondre RH et Fedora).
> envisage que tu ais expérimenté ce que je rapporte et tu comprendras
Je comprends que ce problème n'a jamais été reporté et que tu ais le seul à l'avoir eu.
* Yum n'a jamais permis ce comportement
* Pirut le gestionnaire graphique par défaut dans F9 non plus
* Yumex toujours pas
Reste PK qui avait fait son introduction dans F9 mais le comportement en question n'était même pas implémenté et il n'a été activé par défaut dans F-12 que lors d'une courte période.
La seule conclusion logique c'est soit les rayons cosmiques ont perturbés ta machine, soit plus probable, une erreur s'est glissée dans l'interface chaise-clavier.
[^] # Re: Manque Fedora dans le lot
Posté par GeneralZod . En réponse à la dépêche Les distributions GNU/Linux sécurisées. Évalué à 5.
Je demande à voir, j'utilise sans interruption Fedora depuis Core 2 et je n'ai jamais observé ce comportement. La seule fois où par défaut, le mot de passe administrateur n'était pas requis pour les mises à jours c'est au tout début de F-12 dans les conditions cités précédemment et ça a été très rapidement désactivé.
> Personnellement, il m'est impossible de faire confiance à nouveau à Fedora si je veux une sécurité minimale.
Tu as tort.
> Un chapeau rouge, une origine américaine, une société commerciale derrière, ces trois éléments me suffisent désormais à fuir.
Le chapeau en question est bleu, et Fedora est construit autour d'un pacte entre la communauté et Red Hat. Depuis Fedora 7, la gouvernance du projet est assumé par la communauté mis à part l'aspect financier. Red Hat ne fait pas ce qu'elle veut dans Fedora, sans cela, il aurait été impossible de construire une communauté aussi large de contributeurs tel que Fedora.
T'as quoi, 80% des contributeurs qui bossent pas chez Red Hat et qui en ont rien foutre des chapeaux rouge et autres.
[^] # Re: Manque Fedora dans le lot
Posté par GeneralZod . En réponse à la dépêche Les distributions GNU/Linux sécurisées. Évalué à 3.
C'est normal, faut chiffrer/déchiffrer ça avant tout opération. Pareil ailleurs.
> j'avais de plus en plus d'erreurs liée à SELinux, que je corrigeais au fur et à mesure
L'outil de diagnostic est un peu lourdingue, mais c'est souvent bénins (souvent une mauvaise labelisation des répertoires, et la commande pour corriger ça est dans le diagnostic).
Les statistiques montent que 62% des utilisateurs de Fedora ont SELinux en mode enforcing, environ 8% en mode permissif donc faut relativiser sur une base d'utilisateur de plusieurs centaines de milliers d'utilisateurs.
Ça fait un moment que Fedora propose une configuration de SELinux grand public compliant.
> Voilà, c'est pas gentil pour Fedora et j'applaudis le travail réalisé, mais c'est du vécu.
Gentil ou pas, faut faire les rapports de bogues sinon on n'avance pas. :)
Un bogue, on se doit de le corriger et non pas le cacher sous le tapis. Après, si c'est pas un bogue, tu auras droit à une explication donc dans tout les cas, tu n'es pas perdant.
> sa grande surprise en lisant mon retour d'expérience sur les mises à jour (incluant un nouveau noyau qui plus est) sans exigence du mot de passe d'admin
Tu confondrais pas avec Fedora 12 ? C'était un changement de comportement dans PackageKit en upstream qui permettait d'installer les paquets (uniquement signés) sans mot de passe root, et limité aux sessions locales et pas de lancement de services.
Pour l'anecdote, le mainteneur de PK avait mentionné ce changement sur la m-l PackageKit mais pas fedora-devel, et comme les paquets ne sont pas signés dans la version de développement, personne ne s'en est rendu compte avant la release (puisque PK exigeait dès lors le mot de passe root).
[^] # Re: Version Iphone
Posté par GeneralZod . En réponse à la dépêche Publication de la version 1.8 de Battle For Wesnoth. Évalué à 7.
La SDL a été porté sur Android, tu peux récupérer une partie du code natif, donc yakafocon mais ça prendra du temps.
En comparaison, le gros du travail dans le portage iPhone a été de réduire la consommation mémoire, et l'adaptation de l'IHM. Pour MeeGo, ça ne devrait pas être plus compliqué, il existe déjà un port Maemo.
[^] # Re: sympa la dépêche
Posté par GeneralZod . En réponse à la dépêche Les distributions GNU/Linux sécurisées. Évalué à 2.
Tu veux plutôt dire Conectiva et harald Welte. Conectiva avait une très belle expertise technique mais la distribution éponyme n'a jamais été une distribution spécialisé dans la sécurité à ma connaissance.
[^] # Re: D'autres packages basés sur le core...
Posté par GeneralZod . En réponse à la dépêche MeeGo s'ouvre à la communauté. Évalué à 3.
Si MeeGo se resynchronise régulièrement sur Fedora comme feu Moblin (à priori non), ça serait très facile pour Fedora de maintenir un dépôt tiers comme on le fait avec EPEL pour RHEL/CentOS.
# Manque Fedora dans le lot
Posté par GeneralZod . En réponse à la dépêche Les distributions GNU/Linux sécurisées. Évalué à 10.
http://fedoraproject.org/wiki/Security
Fedora est un contributeur important à SELinux, projet qu'il a même démocratisé (activé par défaut depuis plus de 5 ans maintenant !).
La politique de sécurité de Fedora ne se limite pas seulement à SELinux, mais également dans le renforcement de la GLibc et du format ELF (Ulrich Drepper), des patchs noyaux (Exec-shield: NX, PIE, etc ...) Les paquets sont sans exception compilés avec les flags de sécurité (ie: GCC_FORTIFY_SOURCE, fstack-protector), tout ça bien longtemps avant la plupart des autres distributions. Dans le domaine de la virtualisation, libvirt permet de sécuriser l'utilisation à distance de machines virtuelles (X.509, connexion chiffrée, etc ...)
Des fonctionnalités que Fedora promeut et souvent développe.
Au niveau du bureau, on peut rajouter PolicyKit qui offre une solution élégante à la gestion des droits utilisateurs.
Si Fedora ne peut se comparer aux distributions dédiées à la sécurité, elle est tout aussi sécurisée qu'une hardened Gentoo/Debian voire plus, les problématiques liées à la sécurité étant traitées en amont.