Je conseille shopify. C'est du cloud pas libre. Mais peut être que pour démarrer ton entreprise ça vaut le coup de se concentrer sur autre chose que la tech.
Gnome calendar s'inspirerait de California et Evolution de Geary? Ma question de base reste: Pourquoi ces projets sont doublonnés à postériori, et n'ont pas été mieux "appropriés" par le projet Gnome principal?
De plus en voyant la refonte d'Evolution, Gnome Calendar fait de nouveau doublon avec la vue calendrier intégrée à Evolution…
J'ai toujours trouvés leurs softs excellents. Shotwell enterrait f-spot à l'époque, et reste aujourd'hui un soft stable simple et puissant. Geary est un soft de mail top. California enterre le toujours GNOME Calendar, et en plus les types font du Vala, qui est le langage à priori utilisé à fond chez GNOME pour les apps.
En fait, je me demande pourquoi leurs softs ne sont pas devenus les références des applications gnome. C'est d'autant plus frustrant quand on voit la qualité de California et de Geary, et le quasi-abandon de evolution et gnome calendar (sans doute un projet Gsoc mort né, comme gnome Music, météo et clocks). En plus, California est en Vala, et gnome Calendar en C je crois.
Bref, j'ai vraiment du mal à comprendre les relations, et le contrat social, entre Gnome et leurs devs propres (plus gsoc et outreach) d'une part, et d'éventuels fournisseurs de logiciels tiers d'autre part, très motivés et compétents (yorba par exemple) qui ont beau faire des applications qui tuent, ça n'intègre pas l'upstream.
Le coup de la concurrence subite entre Calendar et California m'a vraiment interpellé. D'un coup, on se retrouve avec deux apps de calendrier gtk3/gnome faites from scratch, et celle de Gnome est moins bonne… Ce qui fait qu'aujourd'hui, Gnome est un excellent environnement de bureau, mais que son équipe a un peu l'air de faire cavalier seul pour produire des applis qui au final ne sont pas ébouriffantes…
Félicitations pour cette initiative qui place le libre soft et hard et l'utilisateur au cœur de ses priorité. Cependant je rappelle que malgré la meilleure volonté du faire du open hardware, le projet utilise un chipset allwinner, marque connue pour ses violations tranquillou de la GPL. https://www.reddit.com/r/linux/comments/2zlo2u/allwinner_caught_obfuscating_code_to_hide_gpl/ . La situation a peut être évolué depuis, en tout cas elle rappelle que, comme souvent, un compromis est nécessaire pour faire avancer certains projets. J’espère que par osmose, le projet own-mailbox pourra faire bouger les lignes chez allwinner.
Petite question bonus pour les auteurs, bossez vous avec http://www.hax.co/ ?
Scala et sbt sont connus pour être des veaux, l'un pour la lenteur de son compilateur, l'autre pour sa lenteur tout court et ses fuites mémoires en mode console… Je fais pas l'apologue de maven mais on peut mettre sbt dans un panier a part…
Au pif, avez vous vérifié que vous n'avez pas activé la mise en veille automatique des périphériques USB dans powertop ?
Il m'arrivait la même chose que vous mais en fait c'est moi qui avait fait n'importe quoi en activant une option clairement pas recommandée dans powertop.
Si vous n'utilisez pas powertop, alors jetez un oeil au moyen de désactiver cette fonctionnalité de veille USB. C'est quasi-sûr que ça provient de là et que c'est réglable.
Au démarrage, Firefox télécharge un hash de toutes les urls interdites (genre filtre de bloom très compact) et compare localement avec ta navigation. Comme ça, pas de problème, pas de FUD, pas de sollicitations serveur inutiles, etc.
Mais tu peux quand même désactiver le safe browsing même si franchement ya aucune bonne raison de le faire.
connais tu une lib qui spécifiquement, est spécialisée dans la réalisation de telles interface? Juste le framebuffer c'est un peu léger, ok tu peux bouger des pixels mais ça necessite qd meme de rajouter pas mal de choses au dessus pour composer un ensemble d'éléments et finir avec quelque chose de cohérent. Rien que faire un menu par exemple, c'est pas trivial, tu connais une lib permettant d'aider à faire ça?
L'écran est détecté comme une surface framebuffer /dev/fb1 . À partir de là, les libs qui parlent framebuffer (cairo, pygame a un niveau plus haut..) font l'affaire pour changer des pixels de couleur et fournir les primitives de dessins de base.
Du coup la question plus synthétique est "L'un de vous connaît il une bibliothèque de composants (code, pictogrammes) pour aider à la réalisation d'interfaces sur petits écrans, style celui d'un autoradio, fonctionnant sur linux" Le reste est là pour apporter du contexte mais c'est confusant visiblement :)
Oui j'ai bien vu adafruit, et je leur ai déja acheté des composants. Leurs exemples fonctionnent sur des microcontrolleurs, pas forcément sur des linux habituels, et même là, je n'ai pas vu de librairie permettant par exemple de facilement fabriquer un menu avec des transitions, ou de recomposer une scène. De ce que j'en ai vu, il s'agit surtout de projets très ad-hoc, pas forcément de lib à but général.
Histoire d'éviter de remettre ça sur le tapis, tu peux d'ores et déja mettre les sources sur github, bitbucket, et mentionné ailleurs, tuxfamily. Comme ça en plus tu recevras peut être des contributions plus facilement. Je t'imagine mal répondre à chaque email en mettant un zip des sources en piece jointe.
Le truc bateau qui pourrait ariver , c'est que quelqu'un te demande les sources, et les diffuse lui même, comme la licence l'autorise. Autant garder un oeil sur le mode de diffusion, amha. Bonne continuation.
Ok ça c'est le souhait des types, et la vision optimiste, saupoudré d'un peu de méthode Coué. Pour le moment, je n'ai pas vu de quoi être enthousiasmé à ce point, si ce n'est le plaisir de voir quelqu'un travailler sur les technologies GNOME. Ça ne dit rien en quoi l'approche est plus ou moins valide qu'une autre.
J'ai suivi un peu les news de Builder et j'ai l'impression que pour le moment l'accent était mis sur les capacités de formattage automatique, d'onglets, etc.
Bref, des fonctionnalités qui existent déja dans pas mal d'éditeurs de code, donc je vois pas trop la valeur ajoutée à repartir de zéro, par rapport à Anjuta, déja spécialisé gnome, ou bien en améliorant la doc pour utiliser un IDE C générique comme eclipse. Même google part de intelliJ pour propulser son sdk. De manière générale, j'imagine mal les gens changer d'IDE juste pour faire du dev gnome.
Si vous avez plus d'infos sur les fondations de la démarche, ça m'intéresse :)
Par quelle magie fonctionne le super airplay vidéo de la freebox revolution? Est ce qu'à ton avis, ils paient une licence à Apple pour leur support airplay complet?
J'aime beaucoup coffeescript, mais il n'est pas disponible à froid dans n'importe quel navigateur, ou sinon on pourrait citer n'importe quel langage qui possède un compilateur vers JS. Cela va à l'encontre des avantages cités plus haut.
Le double ou triple égal, c'est un détail, tu peux très bien expliquer dès le départ que == c'est mauvais et qu'il ne faut pas l'utiliser, que le mot clé with est interdit, au même titre qu'on décourage les goto dans la plupart des langages.
Ça a déja été proposé un peu plus haut, mais personnellement, je choisirait javascript comme premier langage pour donner le gout de la programmation à des étudiants qui n'y connaissent rien.
Pour plusieurs raisons:
- L'interpréteur est disponible sur tous les navigateurs, il suffit d'appuyer sur f12 pour avoir à sa disposition un éditeur, un debuggeur, etc.
- Pour faire des interface graphiques, pas besoin de se débattre dans tel ou tel toolkit pas forcément portable: html, css et ça y est votre hello world est disponible sur pc, tablettes.
- Le fait de travailler au sein du web permet de partir d'un élément avec lequel les étudiants sont déja familiers.
- De formidables bases de connaissance pour approfondir, comme khanacademy.
Je me rappelle de mes premiers cours d'info, en 2001. C'était le C, avec l'argument fallacieux que le C était bon car il était portable, performant, ce qui n'est pas pertinent pour une introduction. On galérait déja pas mal avec les bases d'algorithmie, et voila que le prof nous noie avec les notions de gestion mémoire, notion absente même dans la plupart des livres sur les bases de l'algorithmie. Puis, arrive le moment où l'on a du faire des GUI, en décrivant la disposition des widgets décrite de façon très fastidieuse en C.
Évidemment, la plupart des étudiants a été découragée, et a bien vite fait de choisir des cours les éloignant de la programmation le plus possible.
Maintenant que tous les navigateurs proposent une sorte d'IDE intégré, je n'ai aucun mal à imaginer le fun qu'aurait été de faire les meme projets en javascript, dans un navigateur web. Et éventuellement, une fois les concepts généraux sur l'algo et la programmation acquis, de retourner, pour l'embarqué, pour du spécifique, au C, à l'assembleur, ou à autre chose selon les besoin ou l'environnement, scala, java, ruby, etc.
L'important, c'est de susciter l'intérêt pour la matière, d'avoir le minimum de frustration à l'usage, et de frein à l'approfondissement.
Certaine distributions changent de version majeure de firefox durant leur cycle de vie. C'est plus difficile à gérer pour un environnement de bureau complet, mais ça peut être une approche plus intéressante que de toujours faire du rétro-portage, et d'obliger des équipes à faire la maintenance de versions qui ne sont plus utilisées par l'upstream.
Si les migrations de version sont fiables, à priori, il n'y a pas beaucoup d'inconvénients pour l'utilisateur à toujours avoir la version la plus récente, même s'il y a de subtils changements d'interface.
C'est pas si mal.
Après tout, après avoir tapé l'url d'un site, cliqué sur un bookmark, ou obtenu le résultat depuis un moteur de recherche, on a rarement besoin d'éditer à la main le reste de l'url. A voir où ce design nous mène, mais je pense que c'est assez bien trouvé en fait. Peut être un peu limité pour les développeurs web ou les utilisateurs avancés, mais pour un public général, à mon avis, c'est un bon choix.
# s'il y a un manque de ressources...
Posté par fredoche . En réponse au message Création d'une vitrine pour une petite marque artisanale qui se lance. Évalué à 2.
Je conseille shopify. C'est du cloud pas libre. Mais peut être que pour démarrer ton entreprise ça vaut le coup de se concentrer sur autre chose que la tech.
# C'est parfait merci!
Posté par fredoche . En réponse au journal Lollypop 0.9.70 est là. Évalué à 2.
En quelques releases, tu as déja fait mieux que rhytmbox et gnome music. Quel talent!
[^] # Re: Hein ?
Posté par fredoche . En réponse au message Rapport d'intervention chez Monsieur Tartampion. Évalué à 1.
Un truc tout bête mais souvent les adresse mac sont écrites sur une étiquette du laptop… Pas toujours, mais ça vaut le coup de bien regarder.
[^] # Re: Logiciels excellents mais quid de la relation avec GNOME ?
Posté par fredoche . En réponse au journal Yorba ne développera plus Geary, Shotwell et California. Évalué à 1.
Gnome calendar s'inspirerait de California et Evolution de Geary? Ma question de base reste: Pourquoi ces projets sont doublonnés à postériori, et n'ont pas été mieux "appropriés" par le projet Gnome principal?
De plus en voyant la refonte d'Evolution, Gnome Calendar fait de nouveau doublon avec la vue calendrier intégrée à Evolution…
# Logiciels excellents mais quid de la relation avec GNOME ?
Posté par fredoche . En réponse au journal Yorba ne développera plus Geary, Shotwell et California. Évalué à 8.
J'ai toujours trouvés leurs softs excellents. Shotwell enterrait f-spot à l'époque, et reste aujourd'hui un soft stable simple et puissant. Geary est un soft de mail top. California enterre le toujours GNOME Calendar, et en plus les types font du Vala, qui est le langage à priori utilisé à fond chez GNOME pour les apps.
En fait, je me demande pourquoi leurs softs ne sont pas devenus les références des applications gnome. C'est d'autant plus frustrant quand on voit la qualité de California et de Geary, et le quasi-abandon de evolution et gnome calendar (sans doute un projet Gsoc mort né, comme gnome Music, météo et clocks). En plus, California est en Vala, et gnome Calendar en C je crois.
Bref, j'ai vraiment du mal à comprendre les relations, et le contrat social, entre Gnome et leurs devs propres (plus gsoc et outreach) d'une part, et d'éventuels fournisseurs de logiciels tiers d'autre part, très motivés et compétents (yorba par exemple) qui ont beau faire des applications qui tuent, ça n'intègre pas l'upstream.
Le coup de la concurrence subite entre Calendar et California m'a vraiment interpellé. D'un coup, on se retrouve avec deux apps de calendrier gtk3/gnome faites from scratch, et celle de Gnome est moins bonne… Ce qui fait qu'aujourd'hui, Gnome est un excellent environnement de bureau, mais que son équipe a un peu l'air de faire cavalier seul pour produire des applis qui au final ne sont pas ébouriffantes…
# Mise en avant
Posté par fredoche . En réponse à la dépêche Libervia/Salut à Toi : campagne pour une version Android et de bureau. Évalué à 5.
Par quel moyen peut on suggérer que cette news soit ancrée en haut de la page d’accueil de dlfp ?
# Allwinner et la GPL
Posté par fredoche . En réponse à la dépêche La campagne Kickstarter de Own-Mailbox a commencé. Évalué à 9.
Félicitations pour cette initiative qui place le libre soft et hard et l'utilisateur au cœur de ses priorité. Cependant je rappelle que malgré la meilleure volonté du faire du open hardware, le projet utilise un chipset allwinner, marque connue pour ses violations tranquillou de la GPL.
https://www.reddit.com/r/linux/comments/2zlo2u/allwinner_caught_obfuscating_code_to_hide_gpl/ . La situation a peut être évolué depuis, en tout cas elle rappelle que, comme souvent, un compromis est nécessaire pour faire avancer certains projets. J’espère que par osmose, le projet own-mailbox pourra faire bouger les lignes chez allwinner.
Petite question bonus pour les auteurs, bossez vous avec http://www.hax.co/ ?
[^] # Re: HiDpi
Posté par fredoche . En réponse à la dépêche Librem 13, l’espoir d’avoir un jour un ordinateur libre. Évalué à 3.
J'ai lu un blog d'un dev wayland qui mentionnait le développement du support du multi dpi. Je n'ai pas la source par contre…
[^] # Re: Maven
Posté par fredoche . En réponse au journal biicode, c'est fini. Évalué à 1.
Scala et sbt sont connus pour être des veaux, l'un pour la lenteur de son compilateur, l'autre pour sa lenteur tout court et ses fuites mémoires en mode console… Je fais pas l'apologue de maven mais on peut mettre sbt dans un panier a part…
[^] # Re: « Testing », et si le problème était là ?
Posté par fredoche . En réponse au journal Comment mon expérience Linux est en train de tourner au fiasco. Évalué à 4.
Au pif, avez vous vérifié que vous n'avez pas activé la mise en veille automatique des périphériques USB dans powertop ?
Il m'arrivait la même chose que vous mais en fait c'est moi qui avait fait n'importe quoi en activant une option clairement pas recommandée dans powertop.
Si vous n'utilisez pas powertop, alors jetez un oeil au moyen de désactiver cette fonctionnalité de veille USB. C'est quasi-sûr que ça provient de là et que c'est réglable.
[^] # Re:
Posté par fredoche . En réponse à la dépêche Lettre ouverte de Mozilla au CEO de Microsoft. Évalué à 3.
Au démarrage, Firefox télécharge un hash de toutes les urls interdites (genre filtre de bloom très compact) et compare localement avec ta navigation. Comme ça, pas de problème, pas de FUD, pas de sollicitations serveur inutiles, etc.
Mais tu peux quand même désactiver le safe browsing même si franchement ya aucune bonne raison de le faire.
[^] # Re: Mir
Posté par fredoche . En réponse à la dépêche Sortie d’Ubuntu 15.04. Évalué à 2.
Le Nexus 4 a une sortie HDMI. Aucun streaming nécessaire.
[^] # Re: Adafruit ?
Posté par fredoche . En réponse au message Bibliothèque de composants pour la réalisations d'interfaces pour petits écrans LED. Évalué à 1.
connais tu une lib qui spécifiquement, est spécialisée dans la réalisation de telles interface? Juste le framebuffer c'est un peu léger, ok tu peux bouger des pixels mais ça necessite qd meme de rajouter pas mal de choses au dessus pour composer un ensemble d'éléments et finir avec quelque chose de cohérent. Rien que faire un menu par exemple, c'est pas trivial, tu connais une lib permettant d'aider à faire ça?
[^] # Re: Adafruit ?
Posté par fredoche . En réponse au message Bibliothèque de composants pour la réalisations d'interfaces pour petits écrans LED. Évalué à 1.
Hello,
L'écran est détecté comme une surface framebuffer /dev/fb1 . À partir de là, les libs qui parlent framebuffer (cairo, pygame a un niveau plus haut..) font l'affaire pour changer des pixels de couleur et fournir les primitives de dessins de base.
Du coup la question plus synthétique est "L'un de vous connaît il une bibliothèque de composants (code, pictogrammes) pour aider à la réalisation d'interfaces sur petits écrans, style celui d'un autoradio, fonctionnant sur linux" Le reste est là pour apporter du contexte mais c'est confusant visiblement :)
Merci pour ton aide en tout cas.
[^] # Re: Adafruit ?
Posté par fredoche . En réponse au message Bibliothèque de composants pour la réalisations d'interfaces pour petits écrans LED. Évalué à 1.
Oui j'ai bien vu adafruit, et je leur ai déja acheté des composants. Leurs exemples fonctionnent sur des microcontrolleurs, pas forcément sur des linux habituels, et même là, je n'ai pas vu de librairie permettant par exemple de facilement fabriquer un menu avec des transitions, ou de recomposer une scène. De ce que j'en ai vu, il s'agit surtout de projets très ad-hoc, pas forcément de lib à but général.
[^] # Re: Réponse collective de l'auteur :
Posté par fredoche . En réponse à la dépêche Le jeu "Baston de taverne" passe au libre. Évalué à 3.
Histoire d'éviter de remettre ça sur le tapis, tu peux d'ores et déja mettre les sources sur github, bitbucket, et mentionné ailleurs, tuxfamily. Comme ça en plus tu recevras peut être des contributions plus facilement. Je t'imagine mal répondre à chaque email en mettant un zip des sources en piece jointe.
Le truc bateau qui pourrait ariver , c'est que quelqu'un te demande les sources, et les diffuse lui même, comme la licence l'autorise. Autant garder un oeil sur le mode de diffusion, amha. Bonne continuation.
[^] # Re: Un autre IDE ?
Posté par fredoche . En réponse au journal 30 jours pour aider "Builder" le futur IDE de GNOME.. Évalué à 1.
Ok ça c'est le souhait des types, et la vision optimiste, saupoudré d'un peu de méthode Coué. Pour le moment, je n'ai pas vu de quoi être enthousiasmé à ce point, si ce n'est le plaisir de voir quelqu'un travailler sur les technologies GNOME. Ça ne dit rien en quoi l'approche est plus ou moins valide qu'une autre.
# Un autre IDE ?
Posté par fredoche . En réponse au journal 30 jours pour aider "Builder" le futur IDE de GNOME.. Évalué à 10.
J'ai suivi un peu les news de Builder et j'ai l'impression que pour le moment l'accent était mis sur les capacités de formattage automatique, d'onglets, etc.
Bref, des fonctionnalités qui existent déja dans pas mal d'éditeurs de code, donc je vois pas trop la valeur ajoutée à repartir de zéro, par rapport à Anjuta, déja spécialisé gnome, ou bien en améliorant la doc pour utiliser un IDE C générique comme eclipse. Même google part de intelliJ pour propulser son sdk. De manière générale, j'imagine mal les gens changer d'IDE juste pour faire du dev gnome.
Si vous avez plus d'infos sur les fondations de la démarche, ça m'intéresse :)
[^] # Re: Latence et synchronisation audio/video
Posté par fredoche . En réponse au journal Une installation hi-fi de qualitay avec le Raspberry Pi (Arch, Pulseaudio, Shairport, trolls inside). Évalué à 1.
Par quelle magie fonctionne le super airplay vidéo de la freebox revolution? Est ce qu'à ton avis, ils paient une licence à Apple pour leur support airplay complet?
# Merci!!
Posté par fredoche . En réponse au journal Une installation hi-fi de qualitay avec le Raspberry Pi (Arch, Pulseaudio, Shairport, trolls inside). Évalué à 2.
Je m'y met ce soir :)
[^] # Re: Premier langage? Javascript! Première plate-forme,
Posté par fredoche . En réponse au journal Python comme premier langage de programmation ?. Évalué à 2.
J'aime beaucoup coffeescript, mais il n'est pas disponible à froid dans n'importe quel navigateur, ou sinon on pourrait citer n'importe quel langage qui possède un compilateur vers JS. Cela va à l'encontre des avantages cités plus haut.
[^] # Re: Premier langage? Javascript! Première plate-forme,
Posté par fredoche . En réponse au journal Python comme premier langage de programmation ?. Évalué à 2.
Le double ou triple égal, c'est un détail, tu peux très bien expliquer dès le départ que == c'est mauvais et qu'il ne faut pas l'utiliser, que le mot clé with est interdit, au même titre qu'on décourage les goto dans la plupart des langages.
# Premier langage? Javascript! Première plate-forme,
Posté par fredoche . En réponse au journal Python comme premier langage de programmation ?. Évalué à 8.
Ça a déja été proposé un peu plus haut, mais personnellement, je choisirait javascript comme premier langage pour donner le gout de la programmation à des étudiants qui n'y connaissent rien.
Pour plusieurs raisons:
- L'interpréteur est disponible sur tous les navigateurs, il suffit d'appuyer sur f12 pour avoir à sa disposition un éditeur, un debuggeur, etc.
- Pour faire des interface graphiques, pas besoin de se débattre dans tel ou tel toolkit pas forcément portable: html, css et ça y est votre hello world est disponible sur pc, tablettes.
- Le fait de travailler au sein du web permet de partir d'un élément avec lequel les étudiants sont déja familiers.
- De formidables bases de connaissance pour approfondir, comme khanacademy.
Je me rappelle de mes premiers cours d'info, en 2001. C'était le C, avec l'argument fallacieux que le C était bon car il était portable, performant, ce qui n'est pas pertinent pour une introduction. On galérait déja pas mal avec les bases d'algorithmie, et voila que le prof nous noie avec les notions de gestion mémoire, notion absente même dans la plupart des livres sur les bases de l'algorithmie. Puis, arrive le moment où l'on a du faire des GUI, en décrivant la disposition des widgets décrite de façon très fastidieuse en C.
Évidemment, la plupart des étudiants a été découragée, et a bien vite fait de choisir des cours les éloignant de la programmation le plus possible.
Maintenant que tous les navigateurs proposent une sorte d'IDE intégré, je n'ai aucun mal à imaginer le fun qu'aurait été de faire les meme projets en javascript, dans un navigateur web. Et éventuellement, une fois les concepts généraux sur l'algo et la programmation acquis, de retourner, pour l'embarqué, pour du spécifique, au C, à l'assembleur, ou à autre chose selon les besoin ou l'environnement, scala, java, ruby, etc.
L'important, c'est de susciter l'intérêt pour la matière, d'avoir le minimum de frustration à l'usage, et de frein à l'approfondissement.
[^] # Re: KDE merdouille sur une distribution majeure ?
Posté par fredoche . En réponse à la dépêche Appel à l'aide de l'équipe KDE de Debian. Évalué à 3.
Certaine distributions changent de version majeure de firefox durant leur cycle de vie. C'est plus difficile à gérer pour un environnement de bureau complet, mais ça peut être une approche plus intéressante que de toujours faire du rétro-portage, et d'obliger des équipes à faire la maintenance de versions qui ne sont plus utilisées par l'upstream.
Si les migrations de version sont fiables, à priori, il n'y a pas beaucoup d'inconvénients pour l'utilisateur à toujours avoir la version la plus récente, même s'il y a de subtils changements d'interface.
# Intéressant
Posté par fredoche . En réponse au journal GNOME Web, alias Epiphany : le navigateur idéal (le jour de Pâques). Évalué à 1.
C'est pas si mal.
Après tout, après avoir tapé l'url d'un site, cliqué sur un bookmark, ou obtenu le résultat depuis un moteur de recherche, on a rarement besoin d'éditer à la main le reste de l'url. A voir où ce design nous mène, mais je pense que c'est assez bien trouvé en fait. Peut être un peu limité pour les développeurs web ou les utilisateurs avancés, mais pour un public général, à mon avis, c'est un bon choix.