MTux a écrit 1245 commentaires

Dommage, on aura même pas eu le temps de troller sur le logo choisi par Microsoft pour ce bot là : une nana. Pourquoi sexuer un bot ?

Peut-être pour être cohérent avec leur délire de vouloir imposer Cortana partout. S'ils pouvaient l'installer dans ton lavabo ils le feraient.

Par expérience, mauvaise idée les tableaux Excel (ou libreoffice), parce que là il est tout propre, mais dans 2 ans ? En image --> http://www.commitstrip.com/fr/2014/12/19/the-coder-and-the-beast/

Quelque soit le système de packaging, « si tout est packagé proprement », généralement ça reste propre ;-)

A la différence que c'est mieux d'avoir 1 unique système de packaging plutôt que d'en gérer plusieurs qui sont en conflit entre eux.

Les développeurs ne testent pas ça ? Genre ils codent et commit sans jamais rien exécuté et toi tu dois inventer les procédures d'install/update/migration ? :)

Je ne met pas en conflit les sysadmin et les développeurs, je dis simplement que les deux ont des contraintes différentes. Un environnement de dev et de production c'est différent. Tu peux concevoir ton application de la meilleure manière possible, il y aura toujours potentiellement des problèmes en production car elle doit cohabiter avec d'autres, être soumise à des contraintes de sécurité (parefeu, selinux), de haute disponibilité, etc.

Voilà pourquoi je n'aime pas les écosystèmes exotiques qui font cavalier seul, avec leurs propres dépendances, au lieu de se baser sur ce qui existe et ce qui est stable.

Non, avoir un serveur propre c'est trivial et à la porté du premier venu. Tu télécharge l'iso de l'OS que tu veux, tu l'installe, tu débranche le câble réseau : t'as un serveur propre.

Non. Ça c'est l'informatique des années 90 et on en paye le prix aujourd'hui (dette technique). Des choses installées sur le tas, non documentées, non pensées et sans visibilité sur l'avenir. Un bon sysadmin c'est quelqu'un qui a de l'expérience et connaît les choses à faire et à ne pas faire. Et accessoirement c'est lui qui se fait réveiller à 4h du matin quand la prod crashe, pas le développeur ;)

Le boulot d'un sysadmin (ou d'un devops) c'est de maintenir un serveur qui fournis les services qu'on lui demande et oui ça demande de faire avec les services qu'on lui demande et oui il y a des fois où tu ne va pas pouvoir t'appuyer sur le travail de ta distrib (parce qu'il existe autre chose que SSH/(S)FTP/SMTP). Et oui ça demande de faire autre chose que juste la commande sortie de la doc de ta distrib'

Oui, le sysadmin est le chef d'orchestre de l'infrastructure. Mais cela va plus loin que ça, par exemple installer un serveur Apache peut paraître simple (apt-get install apache2), mais ça ne l'est pas si on veut faire ça proprement (écriture de vhost de manière propre et sécurisée, dimensionnement, documentation, perspectives d'évolution…).

Par contre t'es ultra outillé pour le faire quand même entre chef, puppet, ansible, salt, fabric et tout ce qui vient avec la mouvance des plateformes immutables (docker entre autre).

Oui, ce sont des outils formidables si bien utilisés.
Mais par exemple je ne laisserai pas Ansible mettre à jour libc6 si je sais que le serveur a des logiciels custom compilés à la main, trop dangereux.

Donc oui c'est du travail, sinon ce ne serait pas payé ;)

Pas assez malheureusement…

C'est marrant de parler de Docker comme un cache-misère, moi si un sysadmin décide de faire de l'ingérence dans les dépendances de mon application, je lui dirais que je n'ai besoin que de Docker. Je résous le problème en faisant de l'ingérence dans les outils qu'il devra utiliser quoi ;-)

Ce n'est pas qu'un cache misère. Bien sûr que Docker c'est très bien, le problème c'est que pour beaucoup c'est un moyen de packager une application + ses milliards de dépendance qui vont avec sans se faire chier à documenter. Résultat on exécute le tout mais on ne sait pas comment ça marche, et le jour où ça crashe (à 3h du matin le dimanche bien sûr) on appelle le sysadmin en catastrophe pour tout remonter. Mais vu que l'install n'est pas documentée (c'était plus simple de fournir un unique container Docker) c'est la galère.

Sans attaque personnelle, je suis curieux de savoir dans quel domain tu es sysadmin. De mon point de vu vouloir gérer les dépendances à partir des paquets de la distrib est peine perdue sortie de C/C++ et (j'imagine, merci de me corriger si ce n'est pas le cas) Java.

Non ce n'est pas peine perdue, à ma connaissance Debian package de tas d'applications capables d'utiliser les dépendances des mêmes dépôts ? Cette mode de vouloir outrepasser les versions de la distribution et avoir du frais est à mon sens récente et est arrivée avec node.

deux projets ont des dépendances en version différentes, comment faire via apt-get pour que chaque projet utilise la bonne version de la lib ? Pour résoudre ce problème npm et composer installent dans le répertoire du projet, pip a les virtualenv etc.
Pour un projet en python/ruby/php/js une majorité des dépendances ne sont pas packagées dans la distrib, il faut tout re-écrire dans le projet ? (bonjour l'explosion de la complexité et de maintenance…) ou bien tout copier en dur dans le projet ?

Ma réponse va sembler simpliste mais : tu code ton appli pour qu'elle tourne sur Debian 8 et c'est tout. N'utilise pas de dépendances externes ou en version trop récente. Cet enfer de dépendances est peut-être justement due au fait que tout le monde veut aller trop vite et considère que le problème vient des distributions ? Moi je vois ça dans l'autre sens, on code sur des ecosystèmes inexistants ou exotiques et on fait du forcing/bidouillage pour caser ça en production.

Ou le signaler à la CNIL ?

Simplement parce que le sysadmin c'est lui qui se tape les install, les upgrades, les migration et pas le développeur. Si tout est packagé proprement un dpkg -l suffit à voir ce qui est installé sur ta bécane. Si en revanche s'il faut inspecter dpkg, cpan, pecl, npm, en notant les versions particulières ça devient l'enfer. Avoir un serveur propre c'est le boulot du sysadmin.

Autre exemple : en cas de maj du kernel ou de libc6, si cela impacte des paquets ils seront mis à jour eux aussi. Par contre tes bidules npm non, c'est à toi de savoir que ça va merder et qu'il faut recompiler.

Je te rejoint sur l'aspect documentation : pour moi c'est pas de la doc, c'est… du code. Ou alors c'est la doc du code, mais en tous cas c'est pas clair pour un utilisateur ou même un sysadmin.

Sur Debian les paquets sont maintenus très longtemps.
Alternativement il y a FreeBSD et ses ports (à compiler ou à récupérer directement sous forme binaire) qui propose différentes versions d'un même logiciel (par exemple il y a php5.5, php5.6 et php7, avec les dépendances en option).

Je n'en veux pas non plus.
Pareil pour pecl.
Si la dépendance n'est pas packagée dans la distribution, l'appli va à la poubelle.

Heu oui enfin ils ont quand même des ISO fonctionnelles avec interface graphique ce qui montre qu'il y a quand même du concret. C'est a mon avis aussi avancé que Hurd alors qu'ils ont débuté il y a 6 mois.

lus largement, on peut se poser la question de la fiabilité des projets JavaScript qui dépendent de centaines de modules npm. Vu le nombre de modules, il faut s'attendre à des problèmes et donc prévoir des solutions. Comment gérer un module dépublié ? Et si un module venait à avoir une faille de sécurité ?

C'est justement ça qui me fait détester npm et node en général.

Rien n'est jamais packagé (par la distribution) dans la bonne version, il faut donc compiler et installer des milliards de dépendances et ce système est bancal. Tellement bancal qu'on en vient à utiliser Docker comme cache-misère.

En tant que sysadmin je ne veux pas de node chez moi.

Puisque c'est du binaire, qu'est-ce qu'il y a à voir comme source ?

Et toi ?

Question récursive…

Ah tiens ils se réveillent ? Ça fait un bon moment que c'est acté et lancé, c'est trop tard.
Par contre je vois d'autres conneries comme WebAssembly. C'est peut-être ça qu'il faut bloquer le plus vite possible avant que ça devienne Flash 2.0.

Je l'ai installé dans une VM pour voir et j'ai mis les outils invités Virtualbox.
A ma grande surprise ça marche le pilote vidéo est chargé je peux redimensionner à souhait ma VM (la taille du bureau s'adapte).
Installation de firefox ça marche aussi.
Je regrette qu'il n'y ait que FAT32 (pas de NTFS) et que le système soit si lent alors que d'après taskmgr (oui il existe!) l'UC et la mémoire ne sont pas du tout chargés.

C'est comme les blagues sur les fonctionnaires, c'est toujours pour rire et sans volonté de nuire mais au final le cliché est auto-alimenté et mène la vie dure à ceux qui sont concernés. Certes ce n'est pas une offense capitale mais moi aussi j'aimerai que ce genre de choses disparaisse.

Heu… le seul moyent d'installer Swift c'est Vagrant ? C'est à dire télécharger une VM ?

Il n'y a pas de procédure à l'ancienne du genre récupération des sources, compilation, installation ?

Le passage où vous recommandez de désinstaller Linux Mint par sécurité est quand même un peu choquant.

Ok, car c'est donc un peu délicat de recommander publiquement aux gens de désinstaller Mint…

nous ne saurions trop vous conseiller de

"Nous" ? Vous faites partie de l'équipe Linux Mint ?

Oui enfin le PINE 64 il est pas encore dispo, c'est toujours à l'état de projet.
Le rpi a l'avantage d'exister autrement qu'en fantasme.
Mes mots sont durs mais il y a des tonnes de projets fantastiques kickstartés qui se cassent la figure, la prudence est donc de mise.
Surtout avec ces bidules en arm, tu as 50% de chances d'avoir un truc impossible à maintenir dès que le fabriquant l'aura abandonné et tu restera en kernel 3.10 toute ta vie…

Pas d'info sur Twitter, aucun autre site qui en parle, pas facile d'avoir de l'information.
Plutôt inquiétant.

Pour citer mes patrons dans toutes les boites où j'ai bossé :
"ipv6 ? bwaaaah non on verra plus tard. que ipv4 pour le moment."

Clem a joué la transparence a fond et sans langue de bois.
Un piratage ça peut arriver à n'importe qui, maintenant l'important c'est de voir comment on gère la crise.
En plus ce n'est pas Mint qui a failli, c'est Wordpress.

Et merde, je m'étais dit de ne pas entrer dans ces trolls pourris qui ne mènent à rien…

La prochaine fois tu t’abstiens alors, merci.