paulez a écrit 387 commentaires

T'as changé quels paramètres de taille de buffer ? Généralement sur MySQL/MariaDB avec le moteur InnoDB c'est innodb_buffer_pool_size qui bouffe toute la RAM.

Debian 8 n'est plus supportée par Debian, mais par le projet LTS jusqu'en juin. Donc en gros d'ici là il faut mettre à jour vers Debian 10 ou Debian 9. Au niveau sécurité c'est le plus bel effort que tu puisses faire, après celui de désactiver l'authentification SSH par mot de passe et d'activer les mises à jour automatiques de sécurité.

Le cloud est toujours plus cher si tu l'utilises de la même manière qu'un serveur dédié. L'équivalent en capacité est généralement 5 fois plus cher voire plus.

Pour utiliser le cloud et ne pas payer plus, il faut adapter l'utilisation. Le plus simple déjà est de ne plus sur-provisionner comme on a tendance à faire en dédié, étant donné qu'augmenter la capacité est beaucoup plus simple.

Si tes sites ont de mal de trafic qui change pas mal de fonction de l'heure de la journée tu peux étudier comment faire de l'"auto-scaling" pour réduire la capacité (et payer moins) en heure creuse. Tu peux aussi déplacer l'hébergement statique vers des produits dédiés comme S3 qui coûteront beaucoup moins cher.

Pour les sauvegardes pareil, tu peux utiliser S3 ou autre pour héberger tes snaphosts, ou directement faire des snapshots de tes VMs.

Tu peux même pousser et faire du serverless, créer des conteneurs et ne pas gérer les serveurs qui les font tourner.

Pour résumer, le cloud c'est très différent de l'hébergement dédié, donc ça s'utilise assez différemment.

Tout à fait je rebondissais seulement sur:

Les processeurs actuels compilent si vite, que diminuer la superficie et la dépense de ressources est devenu assez simple.

L'intérêt de Gentoo est ailleurs, comme tu l'as dit. Le principal à mon avis étant la customisation du système à l'aide des use flags.

J'utilise Gentoo aussi, par contre je ne suis pas vraiment convaincu que le temps passé à compiler soit compensé par le temps gagné par la suite en temps d'exécution. Je pense même que globalement la consommation d'énergie est largement supérieure dans le cas d'utilisation de Gentoo à en juger par la température de la pièce à la fin de la journée.

D'ailleurs c'est précisé sur le wiki, le comportement de la commande su a changé.

Est-ce que tu passes root avec la commande su ? Si oui ne pas oublier d'ajouter un tiret su - pour charger l'environnement (et donc le PATH correct avec /usr/sbin).

Fais attention avec la désactivation du mot de passe, assure-toi bien que personne d'autre ne peut se connecter à ton Redis ! Sinon un attaquant pourrait facilement voler des sessions et accéder aux données de tes utilisateurs.

Ce sont les sessions qu'il faut partager, pas les cookies. Les cookies sont stockés par les clients, et généralement permettent de retrouver une session côté serveur.

Quand tu as plusieurs serveurs qui potentiellement servent la même session, il faut partager le stockage de session. Tu peux configurer PHP pour faire ça avec Memcached ou Redis.

Une raison potentielle:

If you distribute a covered work knowingly relying on a patent license, you must act to shield downstream users against the possible patent infringement claims from which your license protects you.

S'il y a un patent troll lancé contre les utilisateurs de bash, Apple pourrait se retrouver dans la position de devoir soutenir la défense de tous les utilisateurs, ce qui générerait des coûts de justice faramineux. Le risque financier étant très élevé, il peut être préférable de ne redistribuer aucun logiciel GPLv3.

Le protocole SMTP ne garantit pas une non altération du contenu (d'ailleurs tu peux voir dans les en-têtes de tes emails que pas mal de serveurs sur le chemin ont laissé leur trace). Si tu veux avoir une garantie que le contenu n'a pas été altéré il faut ajouter une couche (comme PGP ou autres).

Malheureusement c'est une pratique super courante, d'ailleurs il y a l'air d'avoir une palanquée de tutoriels qui expliquent comment faire.

Le simple pour toi sera de compiler le programme (si tu as les sources) plutôt que d'essayer de le faire marcher avec des librairies 32 bits.

Quand tu dis qu'un disque dur peut-être détruit, en effet bon système transactionnel doit avoir de la redondance à ce niveau pour avoir un certain niveau de durabilité. 100% de durabilité n'existe pas.

La différence majeure entre un disque dur et de la RAM est la garantie d'écriture durable.
Avoir une écriture garantie durable dans un disque est très coûteux (il faut faire un fsync sur le fichier, qui s'assure que le fichier est physiquement écrit sur le disque et pas seulement dans un cache). Les bases de données transactionnelles ont tout un tas de techniques pour faire ça de manière efficace (redo log dans Oracle, WAL dans PostgreSQL).
Quand tu fais tourner ton PostgreSQL dans un ramdisk, il continue à gérer un WAL et toute la logique associée, alors que c'est complètement inutile.
Dans le cas de la mémoire, l'écriture ne peut pas être garantie durable donc ce genre de gestion n'a pas lieu d'être, ce qui change assez fondamentalement comment fonctionne une base de donnée qui fonctionne seulement en mémoire.
Concernant la définition de durabilité je trouve celle de Wikipedia assez bonne, pour résumer le résultat de la transaction survit même en cas de coupure d'électricité, ce que stocker uniquement en RAM ne garanti pas (d'où le titre).

Utilise Redis alors, c'est un moteur de stockage clé/valeur en mémoire qui semble avoir un support des transactions. C'est populaire pour tout ce qui n'a pas besoin d'être persistant (cache, file d'attente, etc).
Ça sera bien plus efficace qu'un SGBD traditionnel qui pense devoir gérer un disque dur magnétique, avec tout le surcoût que ça implique.

La définition ne le spécifie peut-être pas, mais c'est une contrainte majeure à tout logiciel de base de donnée transactionnel. Le fait que ton MySQL ou équivalent puisse redémarrer dans un état cohérent est assez critique. Il faut noter qu'il est possible de configurer MySQL pour qu'il soit plus performant mais on perd la garantie de durabilité (en configurant innodb_flush_log_at_trx_commit=2 par exemple), ce qui généralement génère de mauvaises surprises pas mal de temps plus tard quand le serveur crashe et qu'une ou plusieurs transactions ont disparu :-)

C'est volontaire peut-être, mais il faut que la personne qui a cette volonté comprenne bien que ça n'est plus transactionnel. Utiliser MySQL par exemple dans un ramdisk c'est assez contre productif car il y a énormément de logique dans MySQL pour gérer la notion de durabilité (et dans n'importe quel SGBD transactionnel) qui devient inutile dans un ramdisk. Autant utiliser une base de donnée conçue pour tourner en mémoire (comme Redis ou les memory tables de Mysql).

Une transaction est une suite d'opérations atomique, cohérente, isolée et durable.
"En RAM" est donc incompatible avec la notion de transaction car non durable.

Par contre en non transactionnel en RAM tu as pas mal de trucs comme Memcache et Redis.

Il y a pas mal de bons tutos de classification d'images avec machine learning sur la toile, ça peut valoir le coup d'essayer ! Tu dois pouvoir avoir un truc simple fonctionnel avec quelques heures d'exploration. Là où ça devient compliqué et prend du temps est d'avoir quelque chose qui marche vraiment bien, mais ça peut valoir le coup !
Il faut voir comme approcher le problème, trouver tous les levers de soleil peut bien correspondre à un problème de classification (séparer des images dans plusieurs catégories prédéfinies) et donner une note à l'image peut être un problème de régression (chaque image obtient un score). Il y a des exemples sympas sur le site de sklearn.

Sondage sur un échantillon de 1002 personnes, je suis curieux de savoir quelle est la marge d'erreur sur un tel échantillon.

OOM killer entre en action quand un processus essaie d'allouer de la mémoire mais qu'il n'y en a plus de disponible (en gros). C'est uniquement lié à la gestion de la mémoire. Donc si tu as un processus qui utilise tout ton CPU en permanence aucun mécanisme n'existe pour le tuer.
C'est logique d'ailleurs car il y a tout un tas d'application ou un processus va toujours utiliser beaucoup de temps processeur, par exemple sur un serveur chargé, une station de calcul, quelqu'un qui mine de la cryptomonnaie, etc.
Pour empêcher qu'un processus utilise en permanence tout le temps processeur sur ta machine tu peux essayer de jouer avec les cgroups pour limiter l'effet.

Tu peux y aller bourrin et essayer de supprimer tous les paquets dont le nom commence par "kde":

apt-remove "kde*"


Si tu pars 1 an ou deux, tu restes sur ton pays d'origine. Si tu pars pour plus longtemps, faut bien un jour se poser la question du choix.

Du choix de quoi ? Ça dépend vraiment du pays mais acquérir une nationalité est généralement assez difficile.

Ici on parle de regarder des contenus contraints géographiquement à la France seulement. En effet c'est difficile pour un expatrier d'accéder à des contenus francophones souvent. On peut essayer de réfléchir un peu plus loin que "les expatriés ont abandonné la France, ne paient pas d'impôts, qu'ils se débrouillent". Les expatriés peuvent apporter à la France, que ça soit en étant un très bon vecteur de culture Française, de contacts, etc. Restreindre l'accès à du contenu culturel français, au final c'est restreindre la diffusion de la culture française dans le monde. C'est un peu dommage à l'heure de la domination de la culture anglo-saxonne !

C'est la double peine car l'imposition est différente aux États-Unis par rapport à la France, avec une faible TVA et un impôt sur le revenu élevé. Donc un Américain vivant en France va payer beaucoup de TVA, moins d'impôt sur le revenu à la France, mais payer la différence en impôt sur le revenu aux États-Unis, donc au final payer plus d'impôts qu'un Français en France ou un Américain aux États-Unis.

Je n'ai pas Gnome non plus (KDE), mais je peux trouver une disposition qui semble correspondre "German (Switzerland)" variante "French (Switzerland)", essaie donc de trouver ça dans le menu que tu mentionnes.