flan a écrit 1865 commentaires

Merci pour cette réponse bien franche :)

J'allais soulever la question d'Huggin : comment se comparent les deux solutions ?
Je préfère Django, mais Huggin me semble plus connu.

Je ne vois pas le rapport avec mon message.

Ce n'est pas Clinton qui ne sait pas sécuriser ses e-mails.
C'est Clinton qui viole la loi en utilisant un serveur mail pour ses mails pro, qui viole à nouveau la loi en ne versant pas ses mails pros aux archives nationales (ce qui pose problème lors d'une enquête pour la mort d'un ambassadeur en Libye) — le tout en le sachant très bien car elle rappelle aux autres ambassadeurs de ne surtout pas le faire —, qui détruit des preuves dans une enquête fédérale, qui fait des compromissions du secret défense (en France, c'est passible de 5 ans de prison et 75k€ d'amende, de mémoire) et qui ment en disant que rien de tout cela n'est arrivé (et le mensonge est très mal accepté aux États-Unis). Et par-dessus, la justice va dire que comme c'était uniquement pour se simplifier la vie, ça n'est pas grave.

Bien sûr, tu peux réduire tout ça à « Clinton ne sait pas sécuriser ses e-mails ».

Pourtant, on ne peut pas dire que les médias ont épargné leurs efforts pour faire gagner Clinton. À quel moment ont-ils voulu favoriser Trump ?

À ma connaissance (limitée), MS n'a pas réécrit totalement leur moteur, mais a surtout retiré tout le code servant à garder la compatibilité (Trident pouvait adopter le comportement de plusieurs versions obsolète d'IE).

Malheureusement, fabric2 ne bouge pas beaucoup (du tout ?). Ils ont lancé le projet depuis quelques années, et il n'est toujours pas utilisable.
De plus, fabric et ansible sont sur le même créneau (code Python lancé depuis le poste d'admin et connexion SSH vers les machines administrées), je ne suis pas sûr qu'il y ait de la place pour les deux outils (sachant qu'Ansible a plus ou moins raflé le marché).

Bref, je trouve que parier sur fabric est plus risqué que parier sur Ansible comme techno pérenne.

Note : ce jugement ne porte absolument pas sur les qualités et défauts des deux outils, uniquement sur un des questions les plus importantes pour moi : est-ce que mon investissement sera toujours d'actualité dans 5 ans ? Je pense que fabric sera oublié, contrairement à Ansible.

Auparavant, tu pouvais te faire rembourser OS X. Maintenant, dans la mesure où macOS est gratuit, ça risque d'être plus compliqué.

Très souvent, il y a pas mal de petits trucs pénibles et inintéressants à faire pour finaliser le projet (le packaging, renvoyer à l'utilisateur des messages utiles et compréhensibles, etc.).

Techniquement, rien n'empêche de connecter le script à l'agenda (vive CalDAV !) pour ajouter automatiquement les rappels.

Quels documents disent que la NSA a accès aux informations stockées sur les iPhone, exactement ?

Bof, ça ne me choque pas que les ports en sortie soit également bloqués pour ne pas faciliter l'exfiltration de données sensibles, surtout par un protocole comme le SSH ne permettant pas de voir ce qui passe dedans. Bien sûr, tout dépend du contexte (s'il n'y a pas de données sensibles ou que c'est de toute façon troué de partout, ce n'est pas la même histoire).

Je dois être le seul à avoir une bonne expérience des Canon (c'est pourtant une Pixma d'un modèle assez proche), que j'ai depuis bientôt 6 ans. J'ai remplacé plus d'une fois les cartouches par des génériques LDLC sans aucun problème, et le scanner fonctionne toujours parfaitement.

Je trouve que c'est bien plus simple de débugguer avec systemd.
J'ai eu un souci récemment avec ElasticSearch dont le paquet officiel se lance encore avec sysvinit.
Le service ne se lançait pas, et aucun log nulle part.

J'aurais bien aimé lancer la commande à la main, mais retrouver la commande réellement exécutée est particulièrement pénible vu la taille du script sysvinit.
Au contraire, avec systemd on a 4 lignes qui donnent l'utilisateur, le dossier, la ligne de commande et l'environnement. Du coup, c'est très facile de le lancer directement (et en l'occurrence de se rendre compte que java n'avait pas été installé).

J'imagine qu'il faut lire « il faut corriger cela » et non « fixer cela » (qui signifie l'exact contraire).

Tu oublies un peu vite Darwin ;) Darwin est un OS complet (mais sans interface graphique) qui est la base de macOS.
En gros, tu as le micro-noyau XNU, au-dessus tu as Mach (XNU + les outils BSD), encore au-dessus tu as Darwin (un OS complet en ligne de commande) et enfin tu rajoutes Cocoa et le reste de l'interface graphique pour obtenir macOS.

Oui, peut-être pour find. Et pour les 9 999 autres commandes utilisables en shell ?

Accessoirement, il faut quand même parser la sortie (ce qui est vite pénible quand elle ne se présente pas exactement sous la bonne forme).

je n'ai pas beaucoup regardé Powershell (je n'utilise pas Windows), mais j'ai la même impression. Je suis assez fan du concept mais la syntaxe me semble peu amène. Après, s'il y a une autocomplétion (un peu comme iPython), ça peut aider.

Faudrait que j'essaie iPython par défaut, tiens. Pour l'instant, je suis resté à zsh.

Mais en PowerShell tu n'as normalement pas besoin de parser le message d'erreur. Tu regardes le type de l'exception (CommandNotFoundException) et tu te moques royalement que le message d'erreur soit en klingon ou en anglais.

Au contraire, le shell t'oblige à parser en permanence et le moindre petit changement de syntaxe peut amener des bugs aussi imprévisibles que pénibles à détecter.

Gros inconvénient de ce genre de manip : on peut avoir de mauvaises surprises vu qu'on compte sur un format de sortie qui n'a aucune garantie de stabilité (par exemple quand l'OS est en français). À ce niveau, PowerShell a un gros avantage.

Ça a l'air pas mal, en effet.

Petite question de débutant, qui n'a absolument rien installé pour l'instant : comment cela se compare-t-il par rapport à Jeedom ? Ça me semble à première vue un peu plus joli ou plus simple.

Ça a l'air pas mal du tout, merci pour l'info :)

Idem.

Un CPU x86 peut même utiliser sans problème 64 Go de RAM, y compris avec Windows (avec PAE). En revanche, un processus donné ne pourra pas utiliser plus de 4 Go de RAM. Bon, ok, on peut dire que c'est du bidouillage :)
Le x86-64 amène également plein d'autres avantages (dont plein de registres en plus).

Hey ! C'est pas gentil de me traiter de Hollande !