Retrouvez l’association ardechelibre[.org] lors de la Journée de l’innovation par l’impression 3D, le jeudi 16 juin 2016 à la Pépinière d’entreprises de l’Espélidou à Lachapelle-sous-Aubenas.
Cette journée est organisée par le Pays d’Ardèche Méridionale dans le cadre de la quinzaine des pépinières d’entreprises Rhône-Alpes.
Au programme, de 14h à 18h :
Présentation et démonstration d’une imprimante 3D de type industrielle par la société Delta équipement tout au long de l’après-midi
Présentation de logiciels libres pour « les professionnels » par l’association Ardèche Libre tout au long de l’après-midi
A 18h, conférence « La Révolution de l’Imprimante 3D » animée par Alain Charrier, co-fondateur et directeur du FabLab74
Le GTK+ Hackfest 2016 se déroule en ce moment même à Toronto. Plus d’une quinzaine de développeurs s’y sont retrouvés pour trois jours de développement et de discussions, décidant ainsi du futur de cette bibliothèque utilisée pour concevoir les interfaces graphiques des applications GNOME et d’un certain nombre d’autres projets majeurs.
L’une des discussions ayant fait le plus de bruit concerne le versionnage des prochaines versions majeures (GTK+ 4, 5, 6…).
Depuis la sortie de GTK+ 3.0 en février 2011, les nouvelles versions mineures se sont succédé ces dernières années, apportant à chaque fois leur lot de nouvelles fonctionnalités, mais également de problèmes, cassant régulièrement l’API ou les thèmes utilisateurs. À tel point que ce manque de compatibilité ascendante est désormais l’une des critiques les plus courantes, et que différents projets ont préféré abandonner GTK+ au profit de Qt, ou de retarder leur migration de GTK+ 2 vers la version 3.
Pour rappel, GTK+ 1 est sorti en 1998, GTK+ 2 en 2002 et GTK+ 3 en 2011. Des écarts toujours plus grands, qui obligent à apporter régulièrement de nouvelles fonctionnalités pour pouvoir coller aux nouvelles technologies ou couvrir de nouveaux besoins.
L’une des solutions envisagées, serait de sortir plus régulièrement de nouvelles versions majeures, considérées comme stables, qui ne recevraient plus que des correctifs améliorant la stabilité ou la sécurité (pour de plus amples informations, je vous conseil la lecture des deux billets de blog d’Allison Lortie, Gtk 4.0 is not Gtk 4 et Gtk 5.0 is not Gtk 5).
Après la sortie de GTK+ 4, qui ne devrait probablement pas avoir lieue avant 2018, une nouvelle version majeure sortirait approximativement tous les deux ans. Et entre chaque nouvelle version majeure, nous continuerions comme aujourd’hui de bénéficier de nouvelles versions mineures tous les six mois, qui apporteraient leur lot de nouveautés.
Mais c’est là que ça se gâte. Pour le moment, on semble se diriger vers un GTK+ 4 qui ne correspondrait pas à GTK+ 4.0. Et il en irait de même pour GTK+ 5 ou 6. En gros, durant les dix-huit premiers mois (ce qui correspond à trois versions mineures), les développeurs seraient libres d’ajouter de nouvelles fonctionnalités et de casser l’API autant qu’ils le souhaitent. Une fois le code stabilisé, il sera alors décidé que GTK+ 4.6 ou 4.8 pourra devenir le nouveau GTK+ 4.
À ce moment de l’article, vous ne pouvez vous empêcher de trouver ça idiot et de vous demander pourquoi ils ne travailleraient pas plutôt sur une branche de développement qui, une fois stabilisée, donnerait GTK+ 4.0, première version stable de cette nouvelle branche ?
De l’avis des développeurs, il semble y avoir deux publics, qui ont chacun des besoins différents. D’un côté des projets comme GNOME, qui souhaitent pouvoir bénéficier rapidement des dernières nouveautés sans avoir besoin d’attendre deux ans. Projets qui, de par leur taille, auront toujours la main d’œuvre nécessaire pour adapter les différentes applications aux éventuelles nouveautés ou autres cassures d’API. Et de l’autre, les développeurs d’applications tierces, qui préféreront plutôt se baser sur une version stable qui ne bougera plus, et ne nécessitera donc plus une maintenance incessante et régulière.
Maintenant, il faut savoir que les discussions ont toujours lieues et qu’aucune décision ne sera prise avant le prochain GUADEC, qui se tiendra cette année du 12 au 14 août en Allemagne. Il est donc possible que le versionnage change encore d’ici là. Mais une chose est sûre, de l’avis même des développeurs, des versions stables plus régulières devraient faciliter et accélérer le développement, ce qui devrait nous apporter plein de bonnes choses dans les années à venir.
Une inconnue demeure néanmoins. Combien de branches seront maintenues en parallèle ? Surtout quand on sait que GTK+ 2, qui en est actuellement à la version 2.24.30, est toujours maintenu, près de quinze ans après sa première apparition.
Hier l'ami Dreamzie avait son serveur dédié qui expirait, alors près avoir retiré toute la production dessus, on s'est dit qu'on allait lui faire vomir ses tripes :D
Le serveur est un 128GO de RAM chez OVH, avec Xeon E5, alors il faut y aller pour saturer la bête.
On a commencé par quelques Unixbench, des wgets pour saturer la bande passante, des dd pour saturer la RAM et les disques, ou encore des générateurs de .onion, qui bouffent complètement le CPU.
Bon on a bien saturé le CPU, mais le load était encore assez faible, alors il fallait trouver un truc.
https://twitter.com/fuolpit/status/742329568535678976
Je n'arrive pas à me rappeller où, mais j'ai trouvé cette commande :
dd if=/dev/zero of=/dev/null
C'est un dd, rien de bien original en effet, mais en fait si. Sachant que /dev/zero permet d'avoir un flux de zero à l'infini, et que /dev/null est un trou noir... ben vous voyez où on va ;)
dd est une commande qui permet par exemple d'écrire des images ISO sur une clé USB pour booter sur une distribution GNU/Linux. Il permet aussi de tester la vitesse d'un disque avec ce genre de commande :
(1000 blocs de 1Mo, soit 1Go écrit)
Pour en revenir à notre commande, elle va écrire de rien vers... rien, en gros la vitesse sera proportionnelle à la puissance du CPU, qui va être saturé bien entendu.
Bon, saturer le CPU c'est bien, mais nous ce qu'on veut c'est vraiment exploser le load.
C'est là que j'ai eu une petite idée : et si on lançait une infinité de dd ?
Pas bien compliqué, il suffit de faire une boucle infinie dans bash, et de lancer les processus en arrière plan avec screen !
Très important : il faut installer le serveur sous Debian 8 en allemand, sonst wird es nicht funktionieren. (non pas du tout, désolé, le serveur était en allemand cette fois-ci, parce que... voilà)
Cela fonctionnera sur n'importe quel système/distributions/noyaux, à partir du moment ou vous avez bash, dd et screen d'installés.
Voici le petit script en question :
#!/bin/bash
while true
do
screen -d -m dd if=/dev/zero of=/dev/null
done
Et là le serveur dédié a commencé à pleurer :)
https://twitter.com/fuolpit/status/742336778007351296
Au final, on se retrouve avec des centaines (voire milliers de processus) qui bouffent le I/O et le CPU, c'est à dire tout ce qu'il faut pour avoir un load au max !
https://twitter.com/fuolpit/status/742347851573919744
Par la suite, on a dépassé les 5000 processus avec plus de 3000 de load (record perso), mais le SSH commençait à vraiment avoir du mal.
Donc voilà comment overload une machine sous Linux en 4 ligne de code, rien de compliqué finalement !
Si vous avez d'autres astuces ça pourra servir pour une prochaine fois :P
PS : Utilisez cette commande à bon escient (hum), allez pas casser toutes les machines que vous avez où faire du mal à celles des autres. :)
Pour ceux qui ont vu l'exoconférence d'Alexandre Astier (les veinards!), vous avez pu apprécier un morceau musical qui a du punch. Pour les autres, vous le verrez dans le DVD, car la dernière était samedi dernier.
J'y étais...
Comme j'ai adoré le morceau, je l'ai rapidement retranscrit en tablature. Il n'y a que le riff du début, le solo suivant, c'est d'un autre niveau.
Le silence éternel des espaces infinis m'effayent. Et la seule chose qu'on puisse lui opposer... C'est la poésie ou la musique.
Dès qu'il y a une annonce en rapport avec CozyCloud, dans les commentaires il y a toujours une question sur les différences et les comparaisons entre CozyCloud et OwnCloud.
My vs Own
CozyCloud est une alternative à OwnCloud. On retrouve beaucoup de services similaires (agenda, contact, partage de fichiers etc.) dans CozyCloud, avec des spécificités et différences pour l'un et l'autre. La première est le fait que CozyCloud est mono-utilisateur là ou OwnCloud permet de gérer plusieurs utilisateurs. Pour s'en rappeler, il suffit de retenir ceci : CozyCloud c'est MyCozyCloud. MON Cloud personnel.
OwnCloud c'est Own, c'est NOTRE Cloud personnel.
Différences de technologies
Au niveau technologies utilisées, OwnCloud c'est du php/mysql là ou CozyCloud c'est du NodeJSet CouchDB. En terme de consommation mémoire, du fait des choix de technologies, OwnCloud consomme quelques centaines de megaoctet (selon les usages) là où CozyCloud nécessite entre 1 (à minima) à 2 giga de RAM par instance (pour un seul cloud. Si on veut plusieurs pour plusieurs utilisateurs, il faut plusieurs instances CozyCloud et multiplier par autant la quantité de mémoire vive, RAM, nécessaire sur la machine).
Dans les deux cas, on a une notion d'application tierce. On peut ajouter des applications issues de la communauté.
Différences de philosophie
OwnCloud est plus ancien et a donc une philosophie de cloud personnel multiutilisateurs (avec les applications associées comme nous l'avons vu : agenda, contact, partage de fichiers etc.) CozyCloud a pour but de remettre les données de l'utilisateur entre ces mains et a dans son ADN la notion d'interaction entre les applications. Il y a une mutualisation des données entre les applications de la plateforme. Un fichier musique importé dans l'application fichier est disponible ensuite dans le lecteur de musique, une photo dans l'application photo. OwnCloud propose aussi la même chose. Mais CozyCloud va plus loin. A terme, une facture ou un billet de train reçue par mail pourra être liée à un contact, à un événement dans l'agenda, et à une ligne de dépense dans l'application Kresus. Les données sont liées, au sein des différentes applications, le tout sous le contrôle de l'utilisateur. Ce recoupement de données permettra des usages et fonctionnalités que le simple stockage que propose Owncloud à l'heure actuelle ne permet pas. CozyCloud a également la notion de connecteur. On ajoute des applications qui vont aller se connecter à différents comptes sur le web et rapatrier les données au sein de CozyCloud pour une exploitation de ces données personnelles par l'utilisateur dans un endroit centralisé qu'est son cloud personnel. Un autre scénario qu'il sera possible de faire : je veux lister les commits github du projet d'un contact à qui j'ai donné rendez-vous le mois dernier et avec qui j'ai échangé par mail...
Comparaison des deux - mon projet
Pour pouvoir aider chacun-e à pouvoir présenter ou comparer CozyCloud et OwnCloud, j'ai commencé un travail sur base de captures d'écran qui présentent les services similaires - fonctionnalités communes et spécifiques. Et ainsi on a une idée du design/de l'aspect de ces applications.
Le but n'est surtout pas de faire une documentation complète mais de donner un aperçu, d'avoir une aide à la compréhension des spécificités et particularités de CozyCloud et d'OwnCloud pour une aide à la décision
Si vous souhaitez aider ce projet, c'est par ici https://github.com/genma/CozyCloud_vs_OwnCloud. (Le pdf permet d'avoir un document consultable par tou-te-s. Les sources sont en LaTEX/Beamer).
Cette journée est organisée par le Pays d’Ardèche Méridionale dans le cadre de la quinzaine des pépinières d’entreprises Rhône-Alpes.![Gravatar de ardechelibre[.org]](./media/c3ce2d26.a7b68eff8fec56799b2696ccd4aa5e0e)
CozyCloud c'est MyCozyCloud. MON Cloud personnel.
