Très fine remarque, ils auraient très bien pu passer par l'intermédiaire d'un GSoC par exemple. https://wiki.ubuntu.com/GoogleSoC2010/Ideas (Liste impressionnante de projets, ils feraient bien d'embaucher ou de sponsoriser quelques développeurs à ce rythme)
Today I am pleased to announce two fantastic opportunities for two enthusiastic, motivated and energetic folks to come and join my team for a six month internship. You will join Daniel Holbach, Jorge Castro, and David Planella as team-mates and report to myself as honorary horse-folk, working on awesome solutions to help make Ubuntu an ever more compelling community to be a part of.
---------------------------------------------------
On donne le ton d'entrée de jeu, Jono Bacon veut deux étudiants très très motivés et très trés énergiques pour son équipe.
Jono Bacon disait dans son dernier bouquin que "Ubuntu c'était vachement plus communautaire que les autres". Néanmoins, c'est la seule distribution communautaire où tout les pouvoirs sont concentrés en une personne (non élue), la même personne qui nomme TOUT les membres des comités exécutifs y compris le "community council" !!! Plus drôle encore, la même personne face aux critiques a décidé que Ubuntu était méritocratique et non pas démocratique ... Méritocratique par rapport à quoi ? au mérite ou au léchage de bottes ? Surtout que le type ignore systèmatiquement les remarques de la communauté (Ubuntu One, Ubuntu Music Store, pilotes propriétaires, etc ...)
C'est se foutre de la gueule du monde que d'appeler Ubuntu, une distro communautaire ...
This is a fantastic opportunity to work inside a fast-paced, collaborative environment, solving important problems, working with awesome colleagues and adding Canonical as a rocking reference to your resume.
-----------------------------------------------------
Comme disait Henri IV, on n'attrape pas les mouches avec du vinaigre ! Un peu de miel pour rassurer nos gogos.
On préfère pas embaucher des développeurs mais on a besoin de bêtes de sommes pas chères voire gratuites.
Before we get to the details about the roles, I want to be clear on a few general elements:
* These are internships: they are are not normal full roles.
* Like most internships, these roles are unpaid.
* Each role lasts for six months.
* Working hours are Mon – Fri from 9am – 5pm.
------------------------------------------------
On précise bien, ce sont bien de stages, pas de rémunération comme c'est la norme à Isle Of Man pour une durée de 6 mois avec des horaires fixes pour du télétravail !
I want to be clear that my team is a fast-paced, hard-working, hectic environment. I am going to work you hard, and you should expect that, but my goal here is to help you squeeze every ounce of opportunity out of your internship.
-------------------------------------------------------
En gros, vous serez mes petites salopes pendant 6 mois et je vais vous faire cravacher comme pas possible.
We will have 1-on-1 weekly calls, I will help guide you on what to work on, help you manage your work, solve problems, and be effective in your projects.
---------------------------------------------------------
C'est bien connu, les étudiants, c'est des feignasses en plus c'est du télétravail donc je vais bien vous fliquer.
In other words: when you sign up for your internship, expect a solid six month adventure, but an adventure that will sow the seeds for many great opportunities in the future.
-----------------------------------------------------------
Ça va chier interactif, pour votre matricule !
Pour la suite, on va reprendre les points intéressants des annonces.
> Job Location: Home with some travel engagements.
Je tire mon chapeau, c'est tout simplement génial ! Bien que Canonical soit principalement basé à Londres, c'est une société de droit mannien, avec le télétravail, ils ne sont pas soumis à la loi britannique (dépendance directe de la couronne) ou d'un autre pays.
J'ose espérer qu'ils ont prévus dès le départ de prendre en charge les frais de déplacements. L'un des postes exige d'être potentiellement en déplacement 25% du temps, déjà que c'est pas payé ...
> good experience of Launchpad, Bazaar and Ubuntu community infrastructure
C'est quand même très spécifiques comme compétences mais on peut toujours rêver.
Quant à l'expérience requise, ça revient à vouloir des esclaves compétents, opérationnels dès le premier jour. Avant, on achetait les esclaves et on les formait, maintenant, on leur demande de se présenter tout seul et d'être prêt à l'emploi, quel progrès !
Merci à Jono Bacon pour ce grand moment comique, je pensais que c'était le privilége du patron de se comporter comme un sagouin mais en fait non.
Tu as raison, chmod est un appel système et est classé dans la section 2 mais la page présentée provient du manuel posix:
man 2 chmod ===> page man linux
man 3p chmox ===> page man posix de l'openGroup // disponible sous Fedora
Pour la portabilité, c'est intéressant d'avoir les pages du manuel posix, suffit juste de rajouter un p derrière le numéro de section pour y accèder.
Posix n'oblige pas les implémenteurs à implémenter son API sous forme d'appels systèmes donc les pages du manuel posix vivent dans la section 1 (commandes utilisateur), 3 (libc) et 0 pour les headers.
> prendre Gstreamer, c'est aussi prendre toute la glib et tout un tas de trucs dont chromium (et donc chrome) n'a pas besoin
Chromium dépends déjà de Gtk+ et de la Glib sur GNU/Linux ... De plus, la proposition consistait à fournir une option de compilation pour pouvoir utiliser alternativement GStreamer, pas de remplacer FFMpeg. Google pouvait très bien continuer à utiliser FFMpeg et laisser les autres s'amuser avec GStreamer sans problème. Google a fermé le ticket sans discuter.
WebKit offre plusieurs backends (CoreGraphics, Cairo, Gtk+, Qt, Wx, EFL, etc ...), ça ne t'oblige pas à les utiliser tous en même temps ...
> se trainer la Glib et ce truc de GObject, ben ça fait mal
La GLib, c'est une petite lib de rien du tout, c'est même une dépendance de Qt depuis quelques temps. Au passage, la GLib ne dépends pas de GObject (en fait, c'est l'inverse).
> Et puis moi j'aime bien ffmpeg ;)
FFMpeg est un super projet, mais le code n'est pas redistribuable partout dans le monde. De par son architecture modulaire, GStreamer permet de fournir un set de codecs de base librement redistribuable et d'obtenir légalement les autres (soit une implémentation libre, soit les codecs fluendo). Actuellement, sans FFMpeg, pas de balise video sous Chromium.
Pour un stage de plus de 3 mois, l'entreprise est obligé de rémunérer le stagiaire (30% du SMIC/mois). Même si Google rémunère l'étudiant pour le même travail, le contrat de stage est établi entre l'entreprise et l'étudiant donc à moins d'un stage de moins de 3 mois, faudra banquer.
En même temps, l'étudiant pourra se consacrer à temps plein sur sa tâche, la boite est gagnante sur toute la ligne: stagiaire moins cher (30% SMIC + GSoC, ça va attirer du monde), pas de charges sociales, éventuellement un employé bien formé à la sortie mais surtout: job done !
> D'ailleurs, je peux lire autant du Theora que du x264 avec Chrome
Rien à foutre de Chrome, en revanche Chrome/Chromium utilise FFMpeg pour la lecture des vidéos, FFMpeg qui ne peut pas être librement redistribué partout dans le monde.
Google a refusé la proposition des développeurs GStreamer d'intégrer GStreamer (ne serait qu'optionnellement) dans Chromium. Google préfére que les utilisateurs de distributions libres n'aient pas de vidéo du tout si on ne leur impose pas H264.
> Google met H.264 dans son lecteur car ça lui coûte moins cher que d'encoder tout Youtube en Theora (à cause de la bande passante monstrueuse demandée par Theora par rapport à H.264 pour une qualité donnée).
1. Pour 99% des vidéos sur le web, on ne verra quasiment pas la différence en terme de qualité entre Theora et H264 et sans surcoût en BP. L'argument du coût de la BP ne tient pas debout.
2. Quant au streaming de contenu HD sur lequel H264 se distingue, la plupart des diffuseurs s'orientent vers du p2p justement à cause du coût délirant de la bande passante. C'est ce que fait déjà Veoh. Rien à voir avec la balise video d'HTML5.
3. le coût de la licence h264 est tellement hallucinant que réencoder toutes les vidéos sur youtube reviendrait beaucoup moins cher. Certes, le MPEG a annoncé une trêve temporaire (pour forcer le passage dans HTML5) mais tu crois que les diffuseurs vont arrêter subitement de payer la taxe en question ?
> Theora n'a jamais montré qu'il pouvait potentiellement arriver à des taux de compression pouvant rivaliser avec H.264.
Theora a démontré qu'il pouvait se substituer à H264 dans le cadre de HTML5 et qu'il avait un gros potentiel d'amélioration.
> Ne serait-ce pas parce que les projets imaginés ne sont pas sexy
Pourtant ils ont été acceptés les années précédentes, et subitement pouf ! L'argument des projets pas sexy est risible, parce qu'aucun projet n'a été présenté à Google.
Seule la première étape vient de se terminer, étape où les projets open-source ne font que candidater pour mentorer des étudiants, seul le projet lui-même et la motivation des mentors sont évalués. La seconde étape consistera à recruter les étudiants, puis à peaufiner les projets pour les présenter à Google.
Forcément, si Xiph n'a pas passé la première étape, ils vont pas se casser le cul à travailler les propositions. Ce que t'as vu, c'est quelques suggestions pour les étudiants, vu que les projets finaux doivent être élaborés avec les étudiants depuis hier seulement.
> Bref, beaucoup de procès d'intention.
Je ne fais que ramasser les miettes de pain qu'ils ont laissés tombé.
> J'ai oui dire que Google aurait mis la main sur une boîte qui disposerait d'un codec performant, voire même que quelque assocs libres les encourageaient à le libérer.
Si tu parles d'On2, la dernière fois qu'ils ont libéré un codec, c'était sous l'égide de Xiph.org ...
Pour le moment, ce qui est certain c'est que Google soutient activement H264 et a refusé Xiph.org comme mentor pour les SoC.
Pour On2, on ne sait pas si ils vont effectivement libéré les codecs ou bien les laisser pourrir dans un tiroir. Ils peuvent très bien avoir racheté la boite pour son portefeuille de brevets ou les compétences internes pour améliorer l'implémentation de H264 par exemple.
D'ordinaire, Google est moins frileux avec la concurrence.
Après la polémique sur le codec de la balise video HTML5 où Google a pris parti pour H264 (à la fois en tant que diffuseur de contenu et éditeur de navigateur), on peut se demander si ça n'est pas rentré en compte.
Google fait ce qu'il veut de son pognon, mais si c'est le cas, je trouve ça très mesquin vis à vis d'une fondation à but non-lucratif qui cherche à faire avancer les formats multimédias ouverts (mieux encore: libres !).
Ah, j'oubliais ! C'est bel et bien Google qui a refusé la candidature de Xiph.org en tant que mentor, pas la peine de chercher d'autres explications farfelues (genre, ils ont pas candidaté, pas de projets, etc ...)
Le mieux c'est d'utiliser Boost.Iostreams qui simplifie pas mal de choses par rapport à iostream et permet entre autre de construire un flux à partir d'un descripteur de fichier (Cf file_descriptor).
Le foreach est basé sur celui de Boost et le concept d'intervalles, ça supporte les tableaux, listes d'initialisations, conteneurs, etc ... La principale différence est qu'on réutilise le mot clé for.
J'ai pendant longtemps parlé d'expressions rationnelles, mais on m'a récemment convaincu qu'expression régulière n'était pas forcément un anglicisme.
Une expression régulière est une expression qui obéit à certaines règles de construction, c'est correct en Français et c'est finalement bien plus proche du terme original.
C'est le nom complet du monsieur, bien connu des contributeurs Fedora.
Il a bossé entre autres sur KMS, cette expérimentation est dans la continuité de son travail actuel: la gestion des systèmes hybrides (changement de GPU à chaud, gestion d'énergie, etc ...). Je recommande de lire les derniers billets qui sont très intéressants à ce sujet.
Le problème ne se résume pas à quelques fichiers douteux, si on peut les enlever, on le fait.
Même sans préambule, la licence elle-même pose problème, Fedora Legal a demandé une clarification à OpenCascade mais pas de réponse.
L'intervention de Spot dans un des liens précédents était lié à une tentative d'empaquetage d'OpenCascade. https://bugzilla.redhat.com/show_bug.cgi?id=458974
Le problème, c'est que tant légalement ça coince, ça ne pourra pas être intégré dans Fedora, ça bloque les paquets qui en dépendent, ça bloque l'initiative de fournir un environnement de travail complet pour OpenMoko basé sur le spin Fedora Electronic Lab.
Reste l'éventualité qu'upstream n'ait pas le droit de modifier la licence d'OpenCascade et dans ce cas, ils ont tout intérêt à le dire sinon, c'est particulièrement imbécile de leur part de ne pas changer la licence.
Un logiciel n'est libre que si la licence et le sens qu'en donne les auteurs l'est. Un exemple bien connu est Pine: une licence BSD-like mais l'université de Washington affirme qu'il est interdit de distribuer une version modifiée. Debian a aussi passé Pine dans Main parce que ça peut passer sur un malentendu ? Les développeurs d'OpenCascade ont bien affirmés que la licence exigeait de remonter toutes modifications, même on feint que la licence est permissive, on se retrouve dans le même cas que Pine.
> À partir de ces discussions, le mainteneur Debian a décidé que c'était du logiciel libre, et l'a passé en main pour squeeze.
Si il s'est basé sur cette discussion, c'est une décision tout à fait arbitraire voire unilatérale, parce que la seule chose qui se dégage de cette discussion, c'est que la situation est très confuse.
> Bien que le résumé de la licence parle de remonter les modifications, la licence n'en parle pas
relis, non lis le texte de la licence, paragraphe 4
You document all Your Modifications, indicate the date of each such Modifications, designate the version of the Software You used, prominently include a file carrying such information with respect to the Modifications and duplicate the copyright and other proprietary notices and disclaimers attached hereto as Schedule "B" or any other notices or disclaimers attached to the Software with your Modifications
De plus, les mainteneurs ont confirmé à Aurélien Jarno qu'il était très clair qu'il fallait obligatoirement remonter les modifications en upstream ==> sapusaipalibre
Alors qu'upstream et debian legal sont incapables de confirmer le caractère libre d'OpenCascade, je vois mal comment Debian a pu permettre ça. Tout ce que je vois, c'est qu'un mainteneur a voulu très très fort intégrer OpenCascade au point de décider arbitrairement que c'était libre. C'est ce que l'on appelle prendre ses désirs pour des réalités.
> http://opencascade.blogspot.com/2008/12/license-to-kill-lice(...)
Un mec d'OpenCascade qui reconnait à demi-mot que la licence d'OpenCascade n'est pas libre tout en noyant le poisson: open-source, permissive, etc... Anecdote amusante, c'est lui qui a proposé d'accoler le LGPL-like alors qu'en fait, ça ne l'est pas du tout.
C'est très clair.
> http://www.opencascade.org/org/forum/thread_15859/
J'ai posté ce même lien 3h (pile poil) plus tôt, et c'est très clair, Spot a clairement résumé la situation: sapusaipalibre et les mecs d'OpenCascade continuent à faire les autruches.
Si les juristes disent que c'est pas libre, ben ça ne l'est pas.
Je me suis renseigné sur la question, apparemment le texte de la licence fourni avec les sources d'OpenCascade 6.3 ne comporte plus le préambule. Ça a suffit à Debian pour déplacer cette version dans main, probablement à tort selon Fedora Legal et les avocats de Red Hat.
Je me référais à l'acceptation la plus répandue du terme (sources disponibles, librement redistribuables, modifiables dans une certaine mesure, etc ...). Je me réfère rarement à l'OSI assimilable à un ersatz de la FSF en moins bien, et créé initialement pour satisfaire l'égo d'ESR.
Est-ce que la licence d'OpenCascade est compatible OSI, à priori non, mais à peu de chose près: l'obligation de renvoyer les patchs au consortium, le reste est similaire à l'APSL 1.x qui est reconnue par l'OSI. Avec l'OSI et ses critères parfois à géométrie variable, ça pourrait éventuellement passer en l'état.
Personne ne parle d'intégrer les patchs en question, la licence t'impose de les documenter.
En général, même si ce n'est pas obligatoire, remonter les patchs à upstream constitue en bonne pratique mais certains patchs sont typiquement inutilisables donc on ne les remonte pas.
Là, tu n'as pas le choix.
You document all Your Modifications, indicate the date of each such Modifications, designate the version of the Software You used, prominently include a file carrying such information with respect to the Modifications and duplicate the copyright and other proprietary notices and disclaimers attached hereto as Schedule "B" or any other notices or disclaimers attached to the Software with your Modifications.
La licence d'OpenCascade précise bien qu'il faut dater, signer, documenter toutes les modifications et fournir tout les documents propriétaires inclus, pas juste de balancer un gros tas de patchs mal ficelés. On peut imaginer d'automatiser une partie de ces contraintes, ça reste très lourd quand même.
La différence avec la GPL est que les contraintes induites par celle-ci garantissent non seulement les droits des utilisateurs mais également une égalité de droits entre les contributeurs.
Quoique vous en pensez, la position de la FSF est très claire: OpenCascade n'est pas libre, point barre.
OpenCascade est open-source, la licence est très souple et permet de faire des logiciels de CAO de qualité sous licence libre (avec une dépendance qui l'est beaucoup moins). Dans son domaine, ça constitue déjà en soi une avancée remarquable.
> Mouaif, en cas de disparition du consortium, une page qui liste les patchs en indiquant qu'ils sont disponible pour tout repreneur...
En général, la propriété intellectuelle d'une entreprise n'est jamais perdu pour tout le monde, soit elle est récupéré par une autre entreprise, soit par les anciens propriétaires de celle-ci.
Légalement, ça ne te dispense pas de l'obligation de fournir les patchs aux détenteurs des droits sauf si vraiment, il n'y a plus personne (cas peu probable).
> 3- liberté de modifier : oui, elle est effective mais il faut informer Opencascade
En pratique, ça rend impossible tout fork durable du projet ===> sapusaipalibre.
Le but c'est d'empêcher toute concurrence d'émerger et c'est contraire aux principes du logiciel libre.
Si je veux forker OpenCascade parce qu'on refuse mes patchs ou que la direction du projet me déplait, il faudrait qu'à chaque modification, je fasse remonter celles-ci. Ça deviendrait rapidement intenable sur le long terme.
> Un entreprise qui utilise OpenCascade sans y avoir contribué et y apporte des améliorations est ainsi obligée de participer à l'effort commun.
Avec la (L)GPL, la société indélicate serait obligé à fournir les sources, patchs compris si elle distribue une version modifiée du logiciel. La licence actuelle d'OpenCascade n'apporte rien de plus à ce niveau.
> Très sincèrement, je ne vois là pas de quoi fouetter un chat !
Certes, mais on ne peut pas parler de libération dans le cas d'OpenCascade et la licence d'OpenCascade n'est pas presque libre, elle ne l'est pas du tout.
Pas de distribution source à première vue (c'est ballot pour les distros), néanmoins, tu peux les récupérer via le svn.
D'ailleurs, l'image que donne philippe lafaye indique la version avec laquelle le HeeksCAD utilisé dans le tutoriel a été compilé.
[^] # Re: DeviceKit, udev, tout ça...
Posté par GeneralZod . En réponse à la dépêche Ubuntu 10.04 LTS "Lucid Lynx" en version beta. Évalué à 6.
> qu'Ubuntu est sur tous les fronts et exploite les opportunités de générer de nouveaux revenus.
Efface, Canonical n'est pas Ubuntu !
[^] # Re: Des absents de taille...
Posté par GeneralZod . En réponse à la dépêche Google Summer of Code 2010 : les projets. Évalué à 1.
[^] # Re: Décryptage de l'annonce
Posté par GeneralZod . En réponse au journal Canonical cherche des esclaves^W stagiaires pour travailler sur Ubuntu. Évalué à 5.
https://wiki.ubuntu.com/GoogleSoC2010/Ideas (Liste impressionnante de projets, ils feraient bien d'embaucher ou de sponsoriser quelques développeurs à ce rythme)
# Décryptage de l'annonce
Posté par GeneralZod . En réponse au journal Canonical cherche des esclaves^W stagiaires pour travailler sur Ubuntu. Évalué à 10.
---------------------------------------------------
On donne le ton d'entrée de jeu, Jono Bacon veut deux étudiants très très motivés et très trés énergiques pour son équipe.
Jono Bacon disait dans son dernier bouquin que "Ubuntu c'était vachement plus communautaire que les autres". Néanmoins, c'est la seule distribution communautaire où tout les pouvoirs sont concentrés en une personne (non élue), la même personne qui nomme TOUT les membres des comités exécutifs y compris le "community council" !!! Plus drôle encore, la même personne face aux critiques a décidé que Ubuntu était méritocratique et non pas démocratique ... Méritocratique par rapport à quoi ? au mérite ou au léchage de bottes ? Surtout que le type ignore systèmatiquement les remarques de la communauté (Ubuntu One, Ubuntu Music Store, pilotes propriétaires, etc ...)
C'est se foutre de la gueule du monde que d'appeler Ubuntu, une distro communautaire ...
This is a fantastic opportunity to work inside a fast-paced, collaborative environment, solving important problems, working with awesome colleagues and adding Canonical as a rocking reference to your resume.
-----------------------------------------------------
Comme disait Henri IV, on n'attrape pas les mouches avec du vinaigre ! Un peu de miel pour rassurer nos gogos.
On préfère pas embaucher des développeurs mais on a besoin de bêtes de sommes pas chères voire gratuites.
Before we get to the details about the roles, I want to be clear on a few general elements:
* These are internships: they are are not normal full roles.
* Like most internships, these roles are unpaid.
* Each role lasts for six months.
* Working hours are Mon – Fri from 9am – 5pm.
------------------------------------------------
On précise bien, ce sont bien de stages, pas de rémunération comme c'est la norme à Isle Of Man pour une durée de 6 mois avec des horaires fixes pour du télétravail !
I want to be clear that my team is a fast-paced, hard-working, hectic environment. I am going to work you hard, and you should expect that, but my goal here is to help you squeeze every ounce of opportunity out of your internship.
-------------------------------------------------------
En gros, vous serez mes petites salopes pendant 6 mois et je vais vous faire cravacher comme pas possible.
We will have 1-on-1 weekly calls, I will help guide you on what to work on, help you manage your work, solve problems, and be effective in your projects.
---------------------------------------------------------
C'est bien connu, les étudiants, c'est des feignasses en plus c'est du télétravail donc je vais bien vous fliquer.
In other words: when you sign up for your internship, expect a solid six month adventure, but an adventure that will sow the seeds for many great opportunities in the future.
-----------------------------------------------------------
Ça va chier interactif, pour votre matricule !
Pour la suite, on va reprendre les points intéressants des annonces.
> Job Location: Home with some travel engagements.
Je tire mon chapeau, c'est tout simplement génial ! Bien que Canonical soit principalement basé à Londres, c'est une société de droit mannien, avec le télétravail, ils ne sont pas soumis à la loi britannique (dépendance directe de la couronne) ou d'un autre pays.
J'ose espérer qu'ils ont prévus dès le départ de prendre en charge les frais de déplacements. L'un des postes exige d'être potentiellement en déplacement 25% du temps, déjà que c'est pas payé ...
> good experience of Launchpad, Bazaar and Ubuntu community infrastructure
C'est quand même très spécifiques comme compétences mais on peut toujours rêver.
Quant à l'expérience requise, ça revient à vouloir des esclaves compétents, opérationnels dès le premier jour. Avant, on achetait les esclaves et on les formait, maintenant, on leur demande de se présenter tout seul et d'être prêt à l'emploi, quel progrès !
Merci à Jono Bacon pour ce grand moment comique, je pensais que c'était le privilége du patron de se comporter comme un sagouin mais en fait non.
[^] # Re: chmod()
Posté par GeneralZod . En réponse au message Chmod +x dans un programme C++. Évalué à 3.
man 2 chmod ===> page man linux
man 3p chmox ===> page man posix de l'openGroup // disponible sous Fedora
Pour la portabilité, c'est intéressant d'avoir les pages du manuel posix, suffit juste de rajouter un p derrière le numéro de section pour y accèder.
Posix n'oblige pas les implémenteurs à implémenter son API sous forme d'appels systèmes donc les pages du manuel posix vivent dans la section 1 (commandes utilisateur), 3 (libc) et 0 pour les headers.
[^] # Re: absence révélatrice: Xiph.org
Posté par GeneralZod . En réponse au journal Google Summer of Code 2010. Évalué à 7.
Chromium dépends déjà de Gtk+ et de la Glib sur GNU/Linux ... De plus, la proposition consistait à fournir une option de compilation pour pouvoir utiliser alternativement GStreamer, pas de remplacer FFMpeg. Google pouvait très bien continuer à utiliser FFMpeg et laisser les autres s'amuser avec GStreamer sans problème. Google a fermé le ticket sans discuter.
WebKit offre plusieurs backends (CoreGraphics, Cairo, Gtk+, Qt, Wx, EFL, etc ...), ça ne t'oblige pas à les utiliser tous en même temps ...
> se trainer la Glib et ce truc de GObject, ben ça fait mal
La GLib, c'est une petite lib de rien du tout, c'est même une dépendance de Qt depuis quelques temps. Au passage, la GLib ne dépends pas de GObject (en fait, c'est l'inverse).
> Et puis moi j'aime bien ffmpeg ;)
FFMpeg est un super projet, mais le code n'est pas redistribuable partout dans le monde. De par son architecture modulaire, GStreamer permet de fournir un set de codecs de base librement redistribuable et d'obtenir légalement les autres (soit une implémentation libre, soit les codecs fluendo). Actuellement, sans FFMpeg, pas de balise video sous Chromium.
[^] # Re: GSoC
Posté par GeneralZod . En réponse au journal Des candidats pour le Google Summer Of Code sur Git ?. Évalué à 3.
En même temps, l'étudiant pourra se consacrer à temps plein sur sa tâche, la boite est gagnante sur toute la ligne: stagiaire moins cher (30% SMIC + GSoC, ça va attirer du monde), pas de charges sociales, éventuellement un employé bien formé à la sortie mais surtout: job done !
[^] # Re: absence révélatrice: Xiph.org
Posté par GeneralZod . En réponse au journal Google Summer of Code 2010. Évalué à 4.
Rien à foutre de Chrome, en revanche Chrome/Chromium utilise FFMpeg pour la lecture des vidéos, FFMpeg qui ne peut pas être librement redistribué partout dans le monde.
Google a refusé la proposition des développeurs GStreamer d'intégrer GStreamer (ne serait qu'optionnellement) dans Chromium. Google préfére que les utilisateurs de distributions libres n'aient pas de vidéo du tout si on ne leur impose pas H264.
> Google met H.264 dans son lecteur car ça lui coûte moins cher que d'encoder tout Youtube en Theora (à cause de la bande passante monstrueuse demandée par Theora par rapport à H.264 pour une qualité donnée).
1. Pour 99% des vidéos sur le web, on ne verra quasiment pas la différence en terme de qualité entre Theora et H264 et sans surcoût en BP. L'argument du coût de la BP ne tient pas debout.
2. Quant au streaming de contenu HD sur lequel H264 se distingue, la plupart des diffuseurs s'orientent vers du p2p justement à cause du coût délirant de la bande passante. C'est ce que fait déjà Veoh. Rien à voir avec la balise video d'HTML5.
3. le coût de la licence h264 est tellement hallucinant que réencoder toutes les vidéos sur youtube reviendrait beaucoup moins cher. Certes, le MPEG a annoncé une trêve temporaire (pour forcer le passage dans HTML5) mais tu crois que les diffuseurs vont arrêter subitement de payer la taxe en question ?
> Theora n'a jamais montré qu'il pouvait potentiellement arriver à des taux de compression pouvant rivaliser avec H.264.
Theora a démontré qu'il pouvait se substituer à H264 dans le cadre de HTML5 et qu'il avait un gros potentiel d'amélioration.
> Ne serait-ce pas parce que les projets imaginés ne sont pas sexy
Pourtant ils ont été acceptés les années précédentes, et subitement pouf ! L'argument des projets pas sexy est risible, parce qu'aucun projet n'a été présenté à Google.
Seule la première étape vient de se terminer, étape où les projets open-source ne font que candidater pour mentorer des étudiants, seul le projet lui-même et la motivation des mentors sont évalués. La seconde étape consistera à recruter les étudiants, puis à peaufiner les projets pour les présenter à Google.
Forcément, si Xiph n'a pas passé la première étape, ils vont pas se casser le cul à travailler les propositions. Ce que t'as vu, c'est quelques suggestions pour les étudiants, vu que les projets finaux doivent être élaborés avec les étudiants depuis hier seulement.
> Bref, beaucoup de procès d'intention.
Je ne fais que ramasser les miettes de pain qu'ils ont laissés tombé.
[^] # Re: absence révélatrice: Xiph.org
Posté par GeneralZod . En réponse au journal Google Summer of Code 2010. Évalué à 4.
> J'ai oui dire que Google aurait mis la main sur une boîte qui disposerait d'un codec performant, voire même que quelque assocs libres les encourageaient à le libérer.
Si tu parles d'On2, la dernière fois qu'ils ont libéré un codec, c'était sous l'égide de Xiph.org ...
Pour le moment, ce qui est certain c'est que Google soutient activement H264 et a refusé Xiph.org comme mentor pour les SoC.
Pour On2, on ne sait pas si ils vont effectivement libéré les codecs ou bien les laisser pourrir dans un tiroir. Ils peuvent très bien avoir racheté la boite pour son portefeuille de brevets ou les compétences internes pour améliorer l'implémentation de H264 par exemple.
D'ordinaire, Google est moins frileux avec la concurrence.
# absence révélatrice: Xiph.org
Posté par GeneralZod . En réponse au journal Google Summer of Code 2010. Évalué à 10.
Google fait ce qu'il veut de son pognon, mais si c'est le cas, je trouve ça très mesquin vis à vis d'une fondation à but non-lucratif qui cherche à faire avancer les formats multimédias ouverts (mieux encore: libres !).
Ah, j'oubliais ! C'est bel et bien Google qui a refusé la candidature de Xiph.org en tant que mentor, pas la peine de chercher d'autres explications farfelues (genre, ils ont pas candidaté, pas de projets, etc ...)
[^] # Re: chmod()
Posté par GeneralZod . En réponse au message Chmod +x dans un programme C++. Évalué à 4.
[^] # Re: C++, un langage moderne ?
Posté par GeneralZod . En réponse à la dépêche C++ 0xB enfin finalisé ?. Évalué à 4.
[^] # Re: C++, un langage moderne ?
Posté par GeneralZod . En réponse à la dépêche C++ 0xB enfin finalisé ?. Évalué à 10.
Une expression régulière est une expression qui obéit à certaines règles de construction, c'est correct en Français et c'est finalement bien plus proche du terme original.
# Dave Airlie
Posté par GeneralZod . En réponse au journal Rendu 3D sur un second GPU. Évalué à 10.
Il a bossé entre autres sur KMS, cette expérimentation est dans la continuité de son travail actuel: la gestion des systèmes hybrides (changement de GPU à chaud, gestion d'énergie, etc ...). Je recommande de lire les derniers billets qui sont très intéressants à ce sujet.
[^] # Re: OpenCascade nunca fue liberado
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 2.
Même sans préambule, la licence elle-même pose problème, Fedora Legal a demandé une clarification à OpenCascade mais pas de réponse.
L'intervention de Spot dans un des liens précédents était lié à une tentative d'empaquetage d'OpenCascade.
https://bugzilla.redhat.com/show_bug.cgi?id=458974
Le problème, c'est que tant légalement ça coince, ça ne pourra pas être intégré dans Fedora, ça bloque les paquets qui en dépendent, ça bloque l'initiative de fournir un environnement de travail complet pour OpenMoko basé sur le spin Fedora Electronic Lab.
Reste l'éventualité qu'upstream n'ait pas le droit de modifier la licence d'OpenCascade et dans ce cas, ils ont tout intérêt à le dire sinon, c'est particulièrement imbécile de leur part de ne pas changer la licence.
Un logiciel n'est libre que si la licence et le sens qu'en donne les auteurs l'est. Un exemple bien connu est Pine: une licence BSD-like mais l'université de Washington affirme qu'il est interdit de distribuer une version modifiée. Debian a aussi passé Pine dans Main parce que ça peut passer sur un malentendu ? Les développeurs d'OpenCascade ont bien affirmés que la licence exigeait de remonter toutes modifications, même on feint que la licence est permissive, on se retrouve dans le même cas que Pine.
[^] # Re: OpenCascade nunca fue liberado
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 2.
Si il s'est basé sur cette discussion, c'est une décision tout à fait arbitraire voire unilatérale, parce que la seule chose qui se dégage de cette discussion, c'est que la situation est très confuse.
> Bien que le résumé de la licence parle de remonter les modifications, la licence n'en parle pas
relis, non lis le texte de la licence, paragraphe 4
You document all Your Modifications, indicate the date of each such Modifications, designate the version of the Software You used, prominently include a file carrying such information with respect to the Modifications and duplicate the copyright and other proprietary notices and disclaimers attached hereto as Schedule "B" or any other notices or disclaimers attached to the Software with your Modifications
De plus, les mainteneurs ont confirmé à Aurélien Jarno qu'il était très clair qu'il fallait obligatoirement remonter les modifications en upstream ==> sapusaipalibre
Alors qu'upstream et debian legal sont incapables de confirmer le caractère libre d'OpenCascade, je vois mal comment Debian a pu permettre ça. Tout ce que je vois, c'est qu'un mainteneur a voulu très très fort intégrer OpenCascade au point de décider arbitrairement que c'était libre. C'est ce que l'on appelle prendre ses désirs pour des réalités.
> http://www.opencascade.org/org/forum/thread_17697/
Inintéressant, on félicite OpenCascade pour ses dix années d'open source (et pas de free software) et on leur demande de clarifier la situation.
> http://opencascade.blogspot.com/2008/12/license-to-kill-lice(...)
Un mec d'OpenCascade qui reconnait à demi-mot que la licence d'OpenCascade n'est pas libre tout en noyant le poisson: open-source, permissive, etc... Anecdote amusante, c'est lui qui a proposé d'accoler le LGPL-like alors qu'en fait, ça ne l'est pas du tout.
C'est très clair.
> http://www.opencascade.org/org/forum/thread_15859/
J'ai posté ce même lien 3h (pile poil) plus tôt, et c'est très clair, Spot a clairement résumé la situation: sapusaipalibre et les mecs d'OpenCascade continuent à faire les autruches.
Si les juristes disent que c'est pas libre, ben ça ne l'est pas.
[^] # Re: OpenCascade nunca fue liberado
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 3.
D'après la revue de Fedora Legal, la licence d'OpenCascade reste non libre y compris sans le préambule.
http://www.opencascade.org/org/forum/thread_15859/ (lire les réponses de Tom Spot Callaway)
Fedora Legal leur a recommandé d'utiliser une licence existante et de demander conseil au SFLC, mais pas de réponse depuis.
[^] # Re: OpenCascade nunca fue liberado
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 2.
Est-ce que la licence d'OpenCascade est compatible OSI, à priori non, mais à peu de chose près: l'obligation de renvoyer les patchs au consortium, le reste est similaire à l'APSL 1.x qui est reconnue par l'OSI. Avec l'OSI et ses critères parfois à géométrie variable, ça pourrait éventuellement passer en l'état.
[^] # Re: OpenCascade nunca fue liberado
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 3.
En général, même si ce n'est pas obligatoire, remonter les patchs à upstream constitue en bonne pratique mais certains patchs sont typiquement inutilisables donc on ne les remonte pas.
Là, tu n'as pas le choix.
[^] # Re: Super nouvelle, mais allons plus loin
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 3.
http://spins.fedoraproject.org/fel/#home
http://lists.fedoraproject.org/pipermail/electronic-lab/
Certaines universités ont montré leur intérêt pour utiliser FEL dans le cadre de leurs enseignements.
[^] # Re: OpenCascade nunca fue liberado
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 3.
La licence d'OpenCascade précise bien qu'il faut dater, signer, documenter toutes les modifications et fournir tout les documents propriétaires inclus, pas juste de balancer un gros tas de patchs mal ficelés. On peut imaginer d'automatiser une partie de ces contraintes, ça reste très lourd quand même.
La différence avec la GPL est que les contraintes induites par celle-ci garantissent non seulement les droits des utilisateurs mais également une égalité de droits entre les contributeurs.
Quoique vous en pensez, la position de la FSF est très claire: OpenCascade n'est pas libre, point barre.
OpenCascade est open-source, la licence est très souple et permet de faire des logiciels de CAO de qualité sous licence libre (avec une dépendance qui l'est beaucoup moins). Dans son domaine, ça constitue déjà en soi une avancée remarquable.
> Mouaif, en cas de disparition du consortium, une page qui liste les patchs en indiquant qu'ils sont disponible pour tout repreneur...
En général, la propriété intellectuelle d'une entreprise n'est jamais perdu pour tout le monde, soit elle est récupéré par une autre entreprise, soit par les anciens propriétaires de celle-ci.
Légalement, ça ne te dispense pas de l'obligation de fournir les patchs aux détenteurs des droits sauf si vraiment, il n'y a plus personne (cas peu probable).
[^] # Re: OpenCascade nunca fue liberado
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 2.
http://packages.debian.org/lenny/libopencascade6.2
http://packages.debian.org/lenny/libopencascade-dev
[^] # Re: OpenCascade nunca fue liberado
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 1.
En pratique, ça rend impossible tout fork durable du projet ===> sapusaipalibre.
Le but c'est d'empêcher toute concurrence d'émerger et c'est contraire aux principes du logiciel libre.
Si je veux forker OpenCascade parce qu'on refuse mes patchs ou que la direction du projet me déplait, il faudrait qu'à chaque modification, je fasse remonter celles-ci. Ça deviendrait rapidement intenable sur le long terme.
> Un entreprise qui utilise OpenCascade sans y avoir contribué et y apporte des améliorations est ainsi obligée de participer à l'effort commun.
Avec la (L)GPL, la société indélicate serait obligé à fournir les sources, patchs compris si elle distribue une version modifiée du logiciel. La licence actuelle d'OpenCascade n'apporte rien de plus à ce niveau.
> Très sincèrement, je ne vois là pas de quoi fouetter un chat !
Certes, mais on ne peut pas parler de libération dans le cas d'OpenCascade et la licence d'OpenCascade n'est pas presque libre, elle ne l'est pas du tout.
[^] # Re: OpenCascade nunca fue liberado
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 1.
[^] # Re: juste une question
Posté par GeneralZod . En réponse à la dépêche Utiliser HeeksCAD, c'est déjà possible ! Un Tutoriel sur Linuxgraphic rénové. Évalué à 3.
D'ailleurs, l'image que donne philippe lafaye indique la version avec laquelle le HeeksCAD utilisé dans le tutoriel a été compilé.