Sufflope a écrit 3182 commentaires

Il faut évidement que ce soit bien fait :)

Les bases en elle-même savent faire des choses là dessus (comme séparer les blobs sur un espace différent et te les présenter comme une même table (comme une vue) et ne charger les blob que si tu l'a vraiment demandé). Mais rien autour ne permet d'en tirer vraiment parti

Oui et c'est le point que j'abordais en disant que tu réinventes un peu un stockage hors de la BDD. Une fois que ton appli est suffisamment souple pour n'avoir besoin des données QUE pour les utiliser réellement (et pas parce que tu voulais savoir le nom du fichier seulement, par exemple, et t'as pas le choix de tout charger) tu as quasi automatiquement la possibilité de ne pas les stocker dans la BDD du tout, et par exemple les stocker sur un autre disque moins cher, du S3 encore moins cher, les foutre dans un CDN…

Je ne connais pas vraiment la problématique SSD ou pas (en terme de prix).

Tu te fais plus bête que tu n'es, là :-) Je pense quand même que tu as remarqué le léger écart du prix au Go entre HDD et SSD.

C'est indexé comme toutes tes autres données,

J'ai oublié d'y répondre dans mon message initial mais justement si tu colles tes fichier à la bourrin dans une colonne binary y a rien d'indexé du tout ou alors j'ai pas compris.

J'en ai plus sous la main là pour vérifier, mais de mémoire, dans les cas où j'ai vu des binaires stockés en BDD (côté techno, du Hibernate + PostgreSQL), c'était quand même plus lourd que le fichier binaire de base.

Plus, c'est chiant quand tu veux voir tes données, si t'as pas prévu une table "binary_data" pour isoler les données des méta-données, tu devras bien faire "select (id, date_created…) from media" et pas select * sinon merci la purge.

C'est chiant pour rapatrier un dump de prod sur l'intégration ou le dev, il va enfler très, très vite. Et généralement on peut imaginer que si t'as tout foutu en base tu es partout parti du principe que les données sont là, donc tu pourras pas forcément "nettoyer" le dump à coup de truncate pour le faire maigrir, sous peine que tout explose dans le code.

Ça oblige à avoir beaucoup de place sur les serveurs de données. Exit la BDD sur SSD, ou alors une baie de SSD hors de prix, ou alors tu devras configurer ta BDD pour qu'elle mette cette table sur des disques moins chers. Donc soit te manger une pénalité de latence pour l'accès aux métadonnées si elles ne sont pas séparées, soit séparer le binaire comme dit plus haut, mais alors un peu réinventer le "je mets mes données ailleurs que dans la BDD".

Alors je parle pas des BDD que je ne connais pas, mais dans un RDBMS, sans être impossible, c'est quand même pas terrible (et même s'il y a des nouveautés dans Postgres ou les autres RDBMS qui rendent ça plus facile, ils ne peuvent qu'aider pour le select * et le stockage séparé sur de l'espace moins cher, pas rendre ton code résilient à l'absence des binaires pour éviter de rappatrier des dumps de 3To en dev).

J'ai pas de Debian pour vérifier, mais normalement, ce n'est pas ce fichier qu'il faut modifier.

Ce fichier (dans un target dans /etc/systemd) est en fait un lien symbolique vers la config de base qui est dans /usr/lib/systemd (que tu as donc éditée, qui sera potentiellement écrasée lors d'une mise à jour, etc etc) qui dit en gros que cette cible utilise ce service.

Tu devrais soit mettre tes changements dans un fichier /etc/systemd/system/bind9.service (tu auras sûrement à le créer), en ne mettant que les nouvelles valeurs de clés que tu veux changer (pas la peine de tout recopier du service de base), et systemd utilisera la config de base en lui superposant tes modifs.

Tu peux aussi faire un dossier /etc/systemd/system/bind9.service.d/ et y mettre tous les toto.service, tutu.service etc. que tu veux (si tu veux couper tes modifs en plusieurs configs décorrellées) et qui seront de la même façon superposés à la config de base.

C'est fait automatiquement je crois si tu utilises la commande systemctl edit bind9 (de mémoire) mais je ne l'ai pas encore utilisée, je fais mes mkdir et nano à la main.

Parce que tailleDonnées risque de poser problème avec l'accent, et neighbor c'est chiant à écrire.

"imaginez un employée d'une banque (réseau sécurisé pour le sieur) qui lance un spam bot contre son grès (il aurait visité un site "méchant" et paf un exploit dans le browser et paf spambot… [Sur un réseau bureautique "sécurisé" avec controle des ports et proxy…sisi puisque Lennart le dit ].

On doit pas connaître les mêmes banques puisque pour au moins une, le "réseau sécurisé" c'est le réseau où c'est marqué que t'as pas le droit d'y brancher un câble ethernet si t'as pas le droit d'accès au réseau sécurisé. La sécurité c'est que comme les gens ont pas le droit ils le feront pas.

Après vérification de mon Debconf, le niveau de priorité est réglé à 'high' ('high' is for rather important questions), donc pour les questions importantes, et, vu comment les devs de Systemd considèrent les utilisateurs, je n'étais pas près de voir s'afficher de question…

Et allez c'est encore la faute de systemd. C'est Lennart qui choisit le niveau de priorité des fichiers dans le packaging dans Debian ? Quel salaud il a vraiment tout infiltré. Tu te ridiculises.

Je peux écrire un OS, je peux écrire un compilateur optimisant, j'ai déjà écrit des modules noyals, j'ai administré des machines unix pendant plus de 15 ans mais je suis incapable de faire quoique ce soit avec ces produits révolutionnaires sans rencontrer des problèmes majeurs bloquants

Tu sais faire tout ça mais rien avec systemd, même pas une unit file simple qui ressemble à : (c'est de tête c'est ptêtre pas exactement ça mais l'idée est là) :

[Service]
Name=My Daemon
Bin=/usr/bin/myDaemon
User=mydaemon

? Y a un truc qui colle pas.

L'outil qui te sert à démarrer ta machine (init) n'a pas vraiment besoin de gérer les processus par après. systemd le fait, mais ce n'est pas le rôle de l'init.

Du coup avec sysV /etc/init.d/apache restart une semaine après le boot de la machine, c'est bien ou mal ?

It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler.

Quand je vois la simplicité d'un fichier de config systemd pour l'immense majorité des cas (limite un unit file d'un daemon simple c'est 3 lignes, le nom du service, le binaire à lancer, et l'utilisateur) et les critiques style "mais ça casse mon script d'init de 1500 lignes pour mon usine à gaz ignoble", je dirais que c'est tout le contraire.

Le mec a confondu systemd et JEE.

Ce qui n'empêche pas, point de vue système, de se prémunir des comportements malsains de programmes, sans attendre qu'ils soient parfaits et exempts de bugs.

Avec ce comportement par défaut ça sera "systemd-spawn-machinchose --flag-super-important nohup mon_script", ça c'est le progrès… Aussi un "soit-disant sysadmin" utilise généralement différentes versions d'OS et différents OS, tu peux imaginer un peu le casse tête (?).

On pourrait s'interroger sur la pertinence de balancer des traitements critiques sans prendre la peine de les rendre résilients, relançable… mais bon il fera un alias nohup = systemd-run --trucmuche et voilà.

Mais avec systemd, je n'ai pas avertissement, tout est écrasé silencieusement.

Ah oui voilà c'est la faute de systemd qui a piraté dpkg pour court-circuiter l'avertissement qu'un fichier a été modifié.

Enfin on s'en fout des détails, l'important, c'est que c'est la faute de systemd.

Je propose surtout qu'on arrête de nous casser les burnes avec ce chiffre que personne ne sait interpréter

C'est marrant moi je l'interprète assez rapidement en "3500 personnes mortes à cause d'un accident de la route" mais bon je dois être un peu trop con.
Ou alors c'est "mort" que tu as du mal à interpréter, mais ne t'inquiète pas ça viendra en grandissant. Tu peux faire l'expérimentation toi-même si tu as un poisson rouge, ou regarder Kill Bill 2.

j'ai été habitant principal pendant 7 ans, puis j'ai gardé l'appart en backup au cas où je revenais avant de le mettre en vente une fois certain de ne pas revenir et c'est devenu taxable pour moi : l'appart principal non taxé est un peu à la tête du client

Ah oui le fameux "appart' principal" que t'occupais pas en fait, du coup il était ton principal quoi ?? En gros t'as participé à la crise du logement en gardant un appart' vide pour ton confort, ou il était pas vide mais alors tu le louais et il était ton principal de mes genoux, et t'es tout colère de t'être fait toper.

Les lecteurs pourront alors s’interroger du bien-fondé du financement par l'économie collaborative des charges publiques de la France.

Au hasard parce que tes économes collaboratifs, ils utilisent les routes, ils sont bien contents d'aller se faire soigner gratos à l'hosto, de pas se faire dépouiller par des pirates de la route en mode Mad Max parce qu'on a des forces de l'ordre, tout ça qui n'est pas gratos ?

D'un autre côté, en C (c'est quand même plus utile en C++ avec les objets, mais bon), on peut faire ceci:

Oui, et ? En javascript aussi tu as un système de portée de variables (c'est justement ce que la construction polémique utilise pour pas polluer le scope global…), je vois pas le rapport.

Là je ne sais pas comment fonctionne l'extension à laquelle se destine le bout de code du journal, mais si elle est minimaliste au sens "quand je tombe sur une URL qui match j'inclus ton script et yolo", sans imposer de structure ou de convention, il faut bien que le code s'exécute tout seul (ton main ne sera exécuté que parce que par convention c'est cette fonction qui est appelée quand on lance le binaire généré, y a rien de magique). Donc soit on prend le scope global pour chez soi et on fait la première proposition de Tanguy, le code à plat, soit on utilise ce type de structure.

Rajoute une convention "au chargement j'éxécute ta fonction main" et ça sera exactement pareil, je vois vraiment pas le rapport avec la choucroute.

Ou parce que d'autres langages plus anciens permettent de faire la même chose, avec moins de magie noire, et que, peut-être, JS aurai pu s'en inspirer.

Y a aucune magie noire, y a uniquement du sucre syntaxique. Si on commence à taxer ce qu'on connait mal de magie noire, pour moi le fait que quand je compile mon programme ça commence par int main et pas par char* tartempion, c'est de la magie noire.

Mais il est vrai que j'ai énormément de mal avec la notion de ne pas avoir besoin de définir un point d'entrée pour un programme, pour commencer.
Le fait de devoir le faire me semble tellement pratique quand je dois creuser dans le code des autres

Et voilà c'est purement de l'habitude. Perso j'ai l'habitude du développement web avec framework IoC, si je veux voir pourquoi tel appel merde je vais direct voir l'action dans le contrôleur concerné, c'est évident.

• Pas sûr que ça soit la faute du langage plutôt que son implémentation dans les navigateurs ou ailleurs qui ne te pousse pas à organiser ton code
• Quoi qu'il en soit c'est sensiblement la même chose en C si tu déclares une variable en dehors d'une fonction (ou dans un script Lua tiens, qui est pas mal utilisé par des projets en C/C++ pour la partie scripting, comme Javascript a été utilisé pour scripter les pages web ; c'est ptêtre inhérent à la simplicité voulue d'un système de scripting)
• C'est un raccourci pour ne pas nommer un "module" parce que c'est un module ad hoc utilisé seulement à côté de sa définition ; la version verbeuse qui serait (en restant dans du "vieux" javascript, sans utiliser de "nouveau" concepts justement de type modules) var MonModuleMétier = function(…){…}; MonModuleMétier.init(); serait inutilement lourde.

Je dirais que tu trouves ça affreux parce que ça ne match pas tes regex de "code dont j'ai l'habitude" et parce que c'est du javascript donc t'es obligé de dire que c'est mal.

http://markdalgleish.com/2011/03/self-executing-anonymous-functions/

Je n'ai jamais vu quelqu'un faire cela systématiquement (que ce soit en java ou en C# d'ailleurs).

Moi si, pour les couches de service et de DAO dans de "vieux" projets Spring. Bon, c'est quand même très has-been dans la scène java new age Akka / Play / Groovy et compagnie.

Je répondais à c'est tellement variable en fonction de ce que tu fais / veut faire de ta vie chez toi (genre tu veux un bureau pour télétravail. Si tu veux un 80m² dans un centre de grande ville avec un bureau un jardin un garage pour 300€/mois, il va falloir redescendre sur terre.

Ceci dit si tu télétravailles t'es pas obligé d'être en centre ville et tu peux aller plus loin pour avoir plus grand pour moins cher.

Venant d'un mec qui vomit du sirop sur fond de bruits de casserole assistés par ordinateur, avec des vidéos de paysages youtube filtrés à la instagram, c'est cocasse.

La seul chose que tu proposes est la duplication de serveur.

Oui, enfin pas juste un duplicat tenu à jour à coup de copie sur cassette. Et pour OVH des points de peering à peu près partout dans le monde. Rien du tout.

Mais tu oublis tout les autres spof : comme la liaison internet, la configuration réseau, les éléments type firewall ou switch managé,… Il y un tas de raisons que le truc tombe en panne. Beaucoup plus que pour un simple PC.

Ah oui parce que la boîte avec 10 000 postes, elle est pas internationale, elle a pas de switch ou de firewall évidemment. Un bon gros hub avec 10 000 ports, 10 000 IP publiques et rulez.

Il sera content ton commercial avec ses fichiers uniquement sur son poste quand il cramera quand il voudra envoyer sa propal par courriel sauf qu'il y a plus de réseau alors son SMTP local peut pas l'envoyer. MAIS son poste est pas en rade, c'est cool.

Nawak.

Je vois toujours pas le rapport avec J'ai encore les souvenirs de serveurs de fichiers SUN en rade, et la demi-journée perdu qui va avec, tous les 3 mois. T'as oublié la femme de ménage d'OVH a débranché la prise ?

avec un conteneur, il est possible d'avoir installé plusieurs applications dedans et de vouloir en désinstaller une seule.

Pour une VM "lourde" (avec un OS complet, juste VMisée histoire de pouvoir la migrer d'hôte par exemple), certes ; pour un conteneur (Docker notamment) il est recommandé de ne mettre qu'une appli par conteneur justement

le fait de savoir désinstaller permet de confirmer que l'on fait ce que l'on pense faire (faire ce qui était prévu et uniquement ce qui était prévu).

Déployer en prod dans des conteneurs jetables (parce que reproductibles, cf. la suite) n'empêche pas de tester en amont ce qu'on fait (tendance au reproducible build, etc).

il me semble plus satisfaisant de maîtriser ce que l'on fait que de jeter tout, mais techniquement/pratiquement/économiquement c'est un compromis sur le fait que de toute façon c'est techniquement difficile alors on va au plus simple / ça coûte moins cher de tout jeter ici « l'écologie/recyclage » on s'en fout mais si ça consomme sûrement plus en énergie / ça permet d'aller vite et c'est tout ce qui compte dans ce monde.

C'est une question de point de vue, avec un conteneur ou avec la compartimentation en groups de systemd par exemple, tu augmentes tes chances de maitriser l'arrêt de ton appli par rapport à "je regarde si j'ai un .pid, ah mince c'est un vieux pas à jour, ah qu'est-ce que j'ai fait de mes fils".

L'analogie avec le recyclage me semble fallacieuse. docker rm génère quand même moins de déchets que mettre ma voiture à la casse plutôt que la réparer.

conceptuellement je trouve étrange de se dire en gros « l'informatique est à mon service et me permet de tout faire » mais bon en fait je suis dépassé, quand j'ai un souci je jette tout. C'est une particularité de l'informatique, heureusement que tous les architectes ne détruisent pas les bâtiments à chaque fois, les mécanos les voitures, etc. C'est une exception de travailler à « ressources quasi-infinies à coût quasi-nul ».

Y a aussi que j'ai plus productif à faire que régler les contingences dont savent s'occuper des outils ? C'est même le but de l'informatique, non ?

Et encore une fois le greenwashing bof.

le fait de ne pas analyser ralentit probablement aussi la découverte de bugs. Exemple bateau : une appli crashe car tel port était déjà ouvert pour une raison non prévue. On la réinstalle, cool ça remarche. Mais on ne sait pas pourquoi et le point ne sera pas corrigé, donc ça tiendra jusqu'au prochain plantage.

Si ton appli n'est pas capable de cracher un message d'erreur "port 1234 already open" au démarrage, je vois pas bien en quoi la lancer dans une VM ou un OS bare metal va changer quoi que ce soit ???

on doit pouvoir trouver d'autres raisons, mais comme on n'est déjà plus vendredi, je vais retourner faire des scripts d'automatisation ansible pour les conteneurs et machines virtuelles de LinuxFr.org…

Bah voilà on est d'accord.