-
Je me met au développement hybride avec apache cordova. Les résultats sont plutôt sympa pour de petites applications.
-
si ça n'est pas indiscret, c'est pour proposer des applis sur quelles plateformes au final ?
-
-
pas mal du tout ! par contre pour une question de lisibilité je n'aime pas trop que le titre de l'article dans la liste soit plus petit que la source du flux … l'inverse serait peut être préférable non ? en gros le titre de l'article et en plus petit la source
autre chose, serait il possible de gérer plusieurs catégories pour un même flux ?
-
oui pas faux. J'aime beaucoup par contre l'organisation de l'UI.
-
salut ! ici l'auteur :) pas faux cette remarque sur la mise en valeur du titre, je vais tenter quelques choses dans ce sens.
pour les flux multicatégories, c'est pas du tout prévu dans le model tel qu'il est maintenant mais ça pourrait être intéressant. ça va demander un certain travail mais je garde aussi la suggestion sous la coude
-
-
Dépôt Github avec toutes les sources, très bel article :)
-
-
Hello, Les Majs ce sont avec ‘docker-compose pull’, Le monitoring, pareille qu'une VM, y'a même des containers de monitoring, Strategie de segmentation, chaque service dans un containers, plusieurs containers par serveurs. Tu peux gérer les containers de plusieurs serveurs avec par exemple, Rancher UI, Shipyard, Kubernetes, Swarm et plein d'autres outils. Donc oui, il y a pas mal de changement avec des VMs classiques mais je pense que chacune de tes questions peuvent avoir une réponse. J'espère t'avancer un peu ! =)
-
avec un système d'automatisation et à coup de docker pull …. ou en utilisant l'orchestration avec compose (ce que je fais). Question segmentation c'est up to you tout en sachant que la bonne pratique c'est un process = un conteneur (mais il y a des exceptions). Pour le monitoring c'est un problème car cela implique une supervision a plusieurs niveaux (processus, ressources, logs …). Malgré tout l'api docker permet déjà de récupérer ces informations et il ne reste plus qu'à coder un truc dessus (mais attention a la volatilité en cas de scale up / scale down). La question étant comment définir si mon service est bon, dégradé ou tombé. Si on regarde bien on a les même problématique avec les solutions cloud (instances amazon, openstack ou autre). Bref sur le point supervision on est loin d'être prêt (si on réfléchit en terme de supervision à la papa).
-
en fait tu cherches une solution complète de gestion de conteneurs ? je dois t'avouer qu'avec les échos que j'ai de swarm ou kubernetes, je ne suis même pas sûr qu'ils offrent déjà tout ça.
-
-
-
david_guenault plus de 8 ans | lien | sur : Retour d'expérience : Scaleway, une bonne idée gâchée par l'incompétence
C'est quand même bizarre, les quelques tickets que j'ai eu a envoyer on toujours été pris en compte. De plus, bien que la perte de donnée soit problématique, elle ne dispense pas d'une sauvegarde en bonne et due forme (tort partagé ?). Enfin cette perte survient si j'ai bien compris en mode développeur (non stable par définition). Donc question de malchance et de mauvaise pratique ?
-
C'est justement ce qu'il est écrit.
- Sauvegarde donc pas de soucis avec la perte de données
- “Mauvaise pratique” reconnue et assumée, produit ne répondant pas aux besoins > passage à un serveur dédié
Ça n'a pas été mis dans l'article (je trouvais ca trop misérabiliste et le but était de sortir du cadre nombriliste) mais j'ai des captures d'écran de ticket ouvert depuis février. Ticket sans demande technique, très simple et resté avec une réponse vague et partielle, toujours pas résolu. Donc bref, pas de soucis avec l'aspect technique : c'est le reste qui ne suis pas.
-
ah merci pour les précision :-). L'essentiel c'est dans tirer quelque chose. J'ai de la prod sur scaleway mais elle est secondée par des sauvegardes et tout est sous docker et les images stockée sur une registry privée (j'ai déjà affronté des crash chez eux). Du coup en cas de problème la supervision déclenche un remontage total de la plateforme avec une interruption de service minimale.
-
-
ça faisait un moment que l'idée de préciser un peu ce que j'estime être les communautés (et non “la”) formant le Logiciel LIbre traînait dans mon esprit. Le déclencheur a été le billet de Frédéric Bezies où il exprime son découragement devant les errements de différents projets du Logiciel LIbre et le peu de liens et de cohérence que cette “communauté” génère. J'essaie d'expliquer un peu le pourquoi du comment dans cet article.
-
Je crois que l'on peut dire la communauté du logiciel libre:
Prenons par exemple le paquet “mate-desktop”. C'est un méta paquet. Mais c'est du coup aussi un paquet. La communauté du logiciel libre est réunie sous la bannière du logiciel libre, et est composée de plusieurs communauté.
Après le fait d'évoquer la notion de communauté du logiciel libre à un publique qui n'est pas éclairé sur le sujet, oui, c'est tendu, car c'est bien une communauté, mais avant tout une meta communauté, Quand je me rend à un événement du logiciel libre (Scale 14x/UbuCon Summit étant mon dernier en date), je me rend compte vraiment que cette communauté existe, on est tout différent (idées, interprétation, …), mais il y a bel et bien quelque chose qui nous rassemble.
Du coup, lexicalement parlant, je pense que “la” communauté du Logiciel Libre, ça existe, mais je garde en tête cette notion de “meta” (…)
-
Oui bien sûr, le titre est un brin provocateur, j'explique plus loin dans l'article que moi aussi j'utilise parfois “la” communauté du Logiciel Libre, mais c'est vraiment pour ramener au plus petit dénominateur commun les différents acteurs de cette communauté, qui sont clairement extrêmement divers et souvent opposés. l'article met en avant qu'il est impossible de dire que “la” communauté devrait faire ci ou ça puisque ce terme n'est qu'un raccourci commode pour désigner des gens et des projets très très différents et souvent opposés les uns aux autres, uniquement reliés par quelques idées communes.
-
J'ai ré-réfléchi un peu…
C'est vrai que “la” communauté, c'est très mal compris “missleading”, et je pense qu'au final que c'est très bien de le dénoncer :)
Par exemple, je fait parti de “la” communauté ubuntu, et j'ai du mal à saisir lorsque quelqu'un qui n'est pas sur ubuntu, viens me voir et me dit, “oui mais ça, la communauté elle veut ça, pas ça”, j'ai envie de répondre: “de quelle communauté tu parles?” (en gros, la personne à vue un article de blog qui partage son opinion, il pense que son avis est partagé par “la” communauté, et met donc ça dans ses propos pour leur donner plus de poids; et ça c'est dure des fois…).
-
oui tout à fait, pour moi le point critique de parle de “la” communauté du Logiciel Libre, c'est que ça amène des gens à croire qu'il y a un leadership centralisé de la communauté incarné par je-ne-sais-qui, ce qui est totalement faux. Les communautés sont divisées, parfois opposées, et ont chacune leur leadership propre.
Elles sont parfois capables de se retrouver et d'agir communément mais, c'est plutôt quelques acteurs à la fois (type la mise en place de systemd) à chaque fois, jamais “la” communauté dans son ensemble. C'est plutôt une idéologie qui relie ces différentes communautés.
-
Généralement on parle de dictature (plus ou moins) éclairée concernant le leadership. Voir linus par exemple … qui lui est un vrai dictateur (pas vraiment éclairé mais plutôt génial). D'un autre côté le leadership impose la prise de décision, si on devait a chaque fois attendre un consensus total, les projets n'avancerait pas du tout …. La possibilité du fork apporte quand même une solution en cas de désaccord total (tant que le fork est fait correctement et non basé sur l'égo de quelques dev).
-
pour moi l'idée d'une gouvernance ou d'un leadership de “la” communauté du LL est simplement impossible, du fait des projets qui la composent, de leurs choix techniques et de leurs idées du LL, souvent opposés les uns aux autres.
-
-
-
-
-
-
-
je “plussois” sur la communication à propos de ce projet. De plus même le hardware est open (olimex fournit tous les schémas à propos de leurs cartes). On peut même rajouter un disque sata sur la carte supportée.
-
Même avis que carl, je bookmark direct ;-)
-
Ah celui la je l'aime beaucoup, allez hop bookmark ;-)
-
Attention tu utilises la version 1 du docker-compose.yml. Les links sont maintenant déconseillés (la résolution des conteneurs par nom est automatique). https://docs.docker.com/compose/compose-file/#versioning. le principal avantage de passer à la version 2 est simple, il te permettra de faire de la résolution de nom sur les conteneurs en multi host sur un “cluster” swarm.
-
Tester borg backup, finir ce foutu développement d'application ;-)
-
ah moi aussi il faut que je teste borg backup !
-
un futur article mon cher carl ? ;-)
-
haha on va y réfléchir :)
-
-
-
-
Il n'y a que moi pour remarquer que l'article ressemble à une traduction google ? Je suis une vrai bille en orthographe et grammaire, mais même pour moi ça pique les yeux. Pour autant c'est intéressant.
-
-
haha il faut toujours qu'un soft soit meilleur que les autres, il ne peut pas être juste différent ?
-
-
-
Sérieusement quand on se décidera à prendre d’abord des consultations de spécialistes qui seront impartiaux quand aux choix techniques alors on aura peut être une chance de faire quelque chose de potable. Tellement d'échecs et toujours les mêmes erreurs …. et les mêmes luttes d'influence.