Du coup la loi antitrust est tombée sous Reagan, les laboratoires Bell ont été séparés de leur maison mère AT&T, ce qui a permis à ces derniers de s'approprier Unix et de faire payer les licences très cher.
Quand on publie un tel article qui peut attirer tous les développeurs remote en manque d'entreprise accueillante, il faudrait directement donner un lien en même temps vers la stack technique et les profils recherchés !
spoiler: c'est du web classique (ruby, php, vue, react, etc.)
Roh, @Cascador, tu casses mon image d'égotique à soumettre cette actu ^^
Pour ceux qui se posent la question, j'anime l'émission « CPU » qui apparait régulièrement sur ce site avec des actus au titre cryptique commençant par « CPU Ex0___ »
Alors éteindre l’ordinateur quand on va se faire un café, je crois que c’est la meilleure !
L’écran si je m’absente plus de 10 min mais l’ordinateur entier, hahaha
En ce qui me concerne je recommande Chrony :
- On a installé Chrony à la place de ntpd sur l'ensemble des serveurs il y a 2 ans, RAS
- Ton lien démontre que niveau fonctionnalité c'est le plus complet/abouti (ce qui ne veut pas dire qu'il faut nécessairement le choisir, c'est toujours en fonction des besoins)
- https://www.coreinfrastructure.org/blogs/securing-network-time/ (voir Chrony) démontre que niveau sécurité c'est le meilleur, c'est ce qui nous a amené à quitter ntpd
- https://unix.stackexchange.com/questions/504381/chrony-vs-systemd-timesyncd-what-are-the-differences-and-use-cases-as-ntp-cli résume bien les différences entre Chrony et systemd-timesyncd. Pour moi les plus importants : 1/ systemd-timesync ne peut pas faire serveur NTP (juste client) 2/ Il ne se synchronise que sur un seul serveur (focusing only on querying time from one remote server and synchronizing the local clock to it) ce que je trouve trop léger pour un serveur (multiples sources plus sûr)
- chronyc fait partie des merveilles que tout logiciel récent devrait proposer. Cette interface en ligne de commande permet de tester, vérifier que tout est ok, du beurre
- “The development is currently supported by Red Hat Software and it is now the default NTP implementation on their distributions”, un gage de qualité et de pérennité
Appréciez la magnifique phrase dans le dernier paragraphe :
« Sa dépendance quasi-totale au bon vouloir des GAFA […]. La machine s’est donc grippée fin 2017, lorsque […] Apple a brusquement restreint ses règles de suivi publicitaire sur les cookies, ces mouchards qui permettent de pister un internaute et d’en déduire ses centres d’intérêt, et sur lesquels s’appuie Criteo pour afficher ses publicités ciblées. »
Critéo a été un énorme fournisseur de publicités ciblés pour la presse Française, voila que les très méchants GAFAM y sont brocardés pour avoir obligé Critéo à respecter le RGPD.
Ce papier est absolument magnifique pour qui lit entre les lignes.
Dans le tableau, il aurait « infini » pour le nombre d'entrées et 100% en couverture de trafic. Il test systématiquement le HTTPS (et par défaut, mets en whitelist le site si ça foire après avoir fallback en HTTP, pour ne pas réessayer à chaque fois). On peut évidemment forcer le HTTP ou le HTTPS manuellement sur chaque site pour qu'il n'essaye pas à chaque fois.
Il permet également d'ajouter l'en-tête Upgrade-Insecure-Requests quand un site est chargé en HTTPS, afin d'éviter le mixed-content.
Je le préfère donc à HTTPS Everywhere qui est souvent conseillé. Et je le recommande aussi en priorité par rapport à celui-ci.
Du coup la loi antitrust est tombée sous Reagan, les laboratoires Bell ont été séparés de leur maison mère AT&T, ce qui a permis à ces derniers de s'approprier Unix et de faire payer les licences très cher.
On connaît tous la suite.
« spoiler: c'est du web classique (ruby, php, vue, react, etc.) « Cette déception !!!
Tu peux me donner plus d'infos sur les fils de messages, un lien ou un exemple ? ça m'intéresse =)
Quand on publie un tel article qui peut attirer tous les développeurs remote en manque d'entreprise accueillante, il faudrait directement donner un lien en même temps vers la stack technique et les profils recherchés !
spoiler: c'est du web classique (ruby, php, vue, react, etc.)
C'est effectivement pas trop son habitude la langue de bois cf. https://www.affordance.info/
Un peu réducteur je trouve de ne parler que des APIs. C'est la mode actuellement mais quid des fils de messages par exemple ?
Yo,
Remonter cette info était l'occasion d'en savoir/montrer plus sur toi, perso à la lecture j'ai été impressionné par la somme de boulot.
Tcho !
Roh, @Cascador, tu casses mon image d'égotique à soumettre cette actu ^^
Pour ceux qui se posent la question, j'anime l'émission « CPU » qui apparait régulièrement sur ce site avec des actus au titre cryptique commençant par « CPU Ex0___ »
Il faudrait arrêter un jour avec Wordpress… vraiment
en fait à la base on a une étiquette humour, mais j'ai vu qu'elle n'est pas passée sur les réseaux sociaux. Donc dans le doute…
SI on ne met pas (humour) dans le titre, il y a des gens qui y croient ?
Mais… Qu'est-ce que je viens de lire ?
Effectivement personne de raisonnable n'utilise Python comme un “langage système fiable et performant”.
On a d'autres languages pour ça.
Qwant de dépasse toujours pas les 1% de part de marché en France. https://gs.statcounter.com/search-engine-market-share/all/france
Alors éteindre l’ordinateur quand on va se faire un café, je crois que c’est la meilleure ! L’écran si je m’absente plus de 10 min mais l’ordinateur entier, hahaha
Salute,
En ce qui me concerne je recommande Chrony :
- On a installé Chrony à la place de ntpd sur l'ensemble des serveurs il y a 2 ans, RAS
- Ton lien démontre que niveau fonctionnalité c'est le plus complet/abouti (ce qui ne veut pas dire qu'il faut nécessairement le choisir, c'est toujours en fonction des besoins)
- https://www.coreinfrastructure.org/blogs/securing-network-time/ (voir Chrony) démontre que niveau sécurité c'est le meilleur, c'est ce qui nous a amené à quitter ntpd
- https://unix.stackexchange.com/questions/504381/chrony-vs-systemd-timesyncd-what-are-the-differences-and-use-cases-as-ntp-cli résume bien les différences entre Chrony et systemd-timesyncd. Pour moi les plus importants : 1/ systemd-timesync ne peut pas faire serveur NTP (juste client) 2/ Il ne se synchronise que sur un seul serveur (focusing only on querying time from one remote server and synchronizing the local clock to it) ce que je trouve trop léger pour un serveur (multiples sources plus sûr)
- chronyc fait partie des merveilles que tout logiciel récent devrait proposer. Cette interface en ligne de commande permet de tester, vérifier que tout est ok, du beurre
- “The development is currently supported by Red Hat Software and it is now the default NTP implementation on their distributions”, un gage de qualité et de pérennité
Tcho !
Voir aussi ce journal sur linuxfr.org : https://linuxfr.org/users/rodhlann/journaux/des-basheries
Appréciez la magnifique phrase dans le dernier paragraphe :
« Sa dépendance quasi-totale au bon vouloir des GAFA […]. La machine s’est donc grippée fin 2017, lorsque […] Apple a brusquement restreint ses règles de suivi publicitaire sur les cookies, ces mouchards qui permettent de pister un internaute et d’en déduire ses centres d’intérêt, et sur lesquels s’appuie Criteo pour afficher ses publicités ciblées. »
Critéo a été un énorme fournisseur de publicités ciblés pour la presse Française, voila que les très méchants GAFAM y sont brocardés pour avoir obligé Critéo à respecter le RGPD.
Ce papier est absolument magnifique pour qui lit entre les lignes.
Super article, j'en ai appris pas mal, merci :)
Personnellement j'utilise SmartHTTPS : https://mybrowseraddon.com/smart-https.html
Dans le tableau, il aurait « infini » pour le nombre d'entrées et 100% en couverture de trafic. Il test systématiquement le HTTPS (et par défaut, mets en whitelist le site si ça foire après avoir fallback en HTTP, pour ne pas réessayer à chaque fois). On peut évidemment forcer le HTTP ou le HTTPS manuellement sur chaque site pour qu'il n'essaye pas à chaque fois.
Il permet également d'ajouter l'en-tête Upgrade-Insecure-Requests quand un site est chargé en HTTPS, afin d'éviter le mixed-content.
Je le préfère donc à HTTPS Everywhere qui est souvent conseillé. Et je le recommande aussi en priorité par rapport à celui-ci.