Je ne sais pas vraiment ce que tu entends par « shuffle », mais mélanger une liste de nombre, cela est plutôt en O(n).
Tout à fait. J'ai mis mon cerveau en court circuit faignant: sort -R ou équivalent
Cela ne fonctionne que pour un petit espace de clefs…
Bien sur la discussion n'était que rhétorique vu le projet. Par contre des points intéressants sont il me semble:
Pour un projet comme ça, on s'en balance tout pétera avant
Ça vaut quand même le coût de bien comprendre ses contraintes pour ne pas s'en mettre qui empêchent de faire des trucs simples qui juste marchent. Ici on dit clé non prédictible, ca vaut le coup de réfléchir à deux fois à ce que ça veut dire exactement avant de faire un random de goret: séquence non prédictible, correspondance URL -> URL courte, rapport à la requête de création etc. En levant une contrainte qui n'existe pas ca ouvre souvent pleins de portes pour avoir un design propre.
Trouver des solutions simples face un problème due à une mauvaise solution (ici on pourra toujours sharder: quand ça ralenti on ajoute un nouvel espace de nom et c'est reparti)
Outils à utilisation mémoire non linéaire pour éviter de frapper un service comme un bourrin quand on peut éviter >90% des appels inutiles contre quelques Ko/Mo/Go. Bien entendu ici c'est totalement hors sujet.
Je me demande à partir de quand on risque de sentir un ralentissement.
Avec du matos moderne, tu peux estimer la performance d'un PNRG basé sur un XOR-shift ou une congruence linéaire à ~500M/s. Je te laisse faire le calcul d'à partir de quel taux de remplissage de l'espace tu passes plus de 100ms à générer des nombres.
Après tu vas requêter ta BDD comme un bourrin pour voir si l'enregistrement existe, là ça va faire beaucoup plus mal et beaucoup beaucoup plus vite. En gardant une archi pourrie comme celle la, une technique est de minimiser le nombre de requêtes que tu vas faire pour vérifier si une URL existe déjà ou pas. Si tu as de la RAM avec un espace de 8G clés, utiliser un bitmap ça passe sans soucis. Mais tu peux faire un compris en utilisant des structures probabilistes à occupation mémoire sous linéaire. Soit de type set membership avec un bloom-filter, soit avec de la détection de doublon avec un Streaming Quotient Filter. Ca va vachement alléger le goulot qu'est la base.
Après la conception reste pourrie pour faire un truc sérieux, le service est voué à se dégrader alors qu'on peut très bien faire du non prédictible sans brute-forcer de pleins de manière. La plus conne serait de faire un shuffle une bonne fois pour toute de ton espace de clé, et ensuite de consommer élément par élément. Ca coûte n log(n), soit rien pour 8G élément, une bonne fois pour toute et après c'est constant. Mais il y a 100 façons différentes de faire un truc propre.
Après encore une fois, pondre un truc pour 2 utilisateurs ou 1 milliards c'est pas vraiment les mêmes objectifs dans la conception et la notion de "good enough"
Si on me demande de faire un truc qui finalement ne sert à rien, ce n'est pas mon temps qui est perdu, c'est celui de l'entreprise
C'est ton temps qui est perdu, l'entreprise ne perd que de l'argent (et ca doit se discuter). Elle n'est pas humaine, n'a pas de cerveau, pas de conscience et n'a pas de durée de vie. Toi si.
Et si vraiment j'ai l'impression de ne servir à rien, il n'y a pas que le travail dans la vie. Ça fait longtemps que je ne vois plus le travail comme un fin en soit.
Fais le cacul de tes heures. Si tu as l'opportunité de pouvoir faire autre chose, ce raisonnement est très très très con. Tu choisis pertinemment de devenir un légume pendant 8h par jour alors que tu pourrais faire des choses qui t'épanouissent plus ou qui sont moins pénibles ?
Si on pousse le raisonnement à long terme, le jour où on te dit merci (par ce que ça va arriver) la suite risque d'être assez douloureuse. Nos métiers ont plutôt un cercle vertueux. Plus tu fais des trucs cools pour toi pendant ces heures, plus ta valeur marchande augmente et plus ta qualité de vie augmente (que ta priorité soit le temps, l'argent ou l'intêret). Se résigner à éteindre son cerveau c'est s’enterrer à petit feu. Tu te fermes les portes peu à peu et ça ne peut qu'empirer et finir par te retrouver bloquer.
Ça fait longtemps que je ne vois plus le travail comme un fin en soit.
Ca ne veut pas dire grand chose ca. On peut y caser tout et n'importe quoi.
Merci il me manquait donc l'autre partie dont j'avais pas trouvé la spec (ce que tu dis est logique même si je le vois pas noir sur blanc dans la PEP) .
Par contre tu confirmes mon affirmation sur le but du projet: Un DSL python pour former des requêtes SQL ? Ni plus ni moins.
>>> select = user.select()
>>> select.where = user.name == "toto';"
>>> tuple(select)
('SELECT * FROM "user" AS "a" WHERE ("a"."name" = %s)', ("toto';",))
Après ça dépend comment c'est utilisé et ou sont fait les vérifs. Mais de ce que j'ai compris ce n'est pas dans les buts du projet. C'est vraiment un DSL pour générer du SQL. L'auteur me corrigera si je dis des conneries.
Pour le code ca va très vite à explorer. Il n'y a pas de magie.
Posté par ckyl .
En réponse au journal python-sql n'est pas un ORM.
Évalué à 9.
Dernière modification le 14 septembre 2013 à 18:17.
L'avantage de ce genre d'approche, est d'avoir une requête dont la syntaxe est vérifiée à la compilation, et non à l'exécution.
Pour le coup c'est un peu raté.
" python-sql […] est une librairiePython "
Plus sérieusement le scope de Linq et de python-sql me semblent très très différents et tu fais fausse route en les comparant. python-sql c'est juste une façon de générer des requêtes SQL depuis une API plutôt que d'écrire la chaîne SQL. Ni plus ni moins. Il n'y a aucun lien avec les objets métier, la base, les schema, ou la façon d'interroger la base. Ca n'offre presque aucune sécurité supplémentaire non plus, d'ailleurs à priori je ne vois aucun soucis pour faire une bête injection sql avec python-sql.
Python-sql n'a l'air de s'intéresser qu'à une toute petite partie très précise du problème. À voir si ca peut être utile et à quoi.
Si tu veux la persistance et que tu as en tête les limites physiques des disques durs tu dois te rendre compte que la limite dure est assez basse. Soit tu as un cas d'utilisation très spécifique qui te permet d'aller chatouiller les perfs brutes (dès que les têtes commencent à bouger c'est vite mort), soit tu utilises du matos adapté à des lectures/écriture aléatoire: ssd, iofusion etc.
Seule solution si on veut pas faire un compromis sur la persistance sans modifier l'archi. Autrement on peut utiliser des techniques types event sourcing, archi distribuées pour être capable de reprendre sans rien perdre en cas de coupure.
L'inutilité de quelque chose ne se mesure pas à sa taille en pixel. Ca la rend certe plus visible; mais le combat de fond est le même: on s'en balance.
Posté par ckyl .
En réponse au journal Une tablette pour programmer.
Évalué à 4.
Dernière modification le 10 septembre 2013 à 19:40.
Je sais pas sa réponse mais pourquoi spécifiquement XPS ? Un bon latitude E 13" ça doit faire dans les 1.6/1.8kg depuis des années (lire 5+ ans). C'est pas le prix d'une tablette ni le même poids. Mais c'est un très bon choix pour ceux cherchant un clavier de la puissance & mobilité et qui ont des vrais écrans à coté. Et tu peux te monter un bon laptop (i7 / 8Go / SSD) qui marche nickel, ne chauffe pas et ne prend pas grand chose comme place.
C'est juste dommage que la qualité/finition des latitudes ait régressé par rapport à il y a 4 ans où elle avait atteint son pic (comme presque tout le matos Dell d'ailleurs). J'ai eu un E 13" entre un mac book pro et un thinkpad, c'était pour moi le meilleur.
question que je me pose c'est: est-ce que quelque chose a changé de ce côté, ou est-ce que ces frameworks ferment volontairement la porte a toutes les applications qui doivent être accessibles?
Sauf si tu parles d'au moins plus de 10 ans en arrière, à ma connaissance ca à toujours été une légende.
Je n'ai jamais pu trouver une seule preuve de ce problème, et toutes les sources que j'ai trouvée semblent dire la même chose.
J'imagine notamment que les applications développées pour (ou par) des instances gouvernementales doivent sans doute obligatoirement être accessibles
Souvent oui. Avec différents niveaux. Par exemple mal voyant et screen reader ce sont deux choses différentes. De même qu'être accessible au clavier. Même si pas mal de choses se recoupent.
cela veut-il dire que si les frameworks javascript sont envisagés, il faut développer deux fois l'application
Non ca veut dire que quand tu fais une appli correcte et que quand tu utilises des widgets corrects il n'y a pas de soucis pour les screen reader.
Si ca t'intéresse. Les pages d'IBM et de Dojo sont des bons points d'entrés pour trouver les refs et bonnes pratiques sur le sujet.
Il est quelqu'un qui aimerait devenir client de leur entreprise. S'ils n'en ont rien a faire de lui… Bah tant pis pour eux !
Tu n'as pas compris mon point. Linus est une personne publique, et il use de cette technique pour son côté buzz. Son message est publique et est un moyen de pression.
Toi, moi où l'auteur de ce journal ne somme pas des personnes publiques. Ton message est point-à-point avec la personne à qui tu t'adresses. Quelle est donc la stratégie de ne pas formuler très simplement qu'il est utilisateur de Linux et qu'il souhaiterait s'abonner ? Quelle est la plus value du style ado de 15 ans je sais tout, menace et dédaigneux ?
Tu résumes très bien le seul but de son message: "J'existe est-ce que tu veux mon argent ?"
Je ne vois pas en quoi il a "pissé sur" qui que ce soit…
Le style, la forme, l'effort fait pour formuler une demande très simple…
Réfléchi à comment tu réagis quand une personne tierce te contact en fonction de son attitude. Prends 10 secondes pour te mettre à la place de la personne à qui tu t'adresses.
Moi je fais clairement le parallèle avec les clients qui aggressent litérallement des commerciaux/vendeurs/représentant quand un produit est supprimé plutôt que de leur dire simplement qu'ils sont décus. Le mec en face de toi ce n'est pas lui qui à supprimé la ref ou décidé que le support Linux n'était pas au cahier des charges. C'est pas ton pote non plus, un peu de savoir vivre quoi. Un peu comme quand tu rapportes un bug ou fait une RFE quoi, la base du savoir vivre.
Faut avouer que le message original fait justement pas mal de détours :
Tout à fait. Et on peut être direct et correct:
" Existe t-il une offre pour les utilisateurs de Linux où suis-je obligé de me tourner vers des sites de streaming illégaux puisque Eurosport n'est pas en mesure de me fournir le service dont j'ai besoin et que je souhaite payer ? "
Il me semble que c'est facile à comprendre sans agresser son interlocuteur. T'as une chance que le mec face +1 dans la bonne case pour te compter, ce qui est grosso modo la seule chose qu'il puisse faire.
Linus te répondrais que ce genre de message les gens s'en tape royalement, et que pour gagner du temps rien de tel qu'un message clair et sans détour qui nuise a la compréhension.
En même temps tu n'es pas Linus et personne n'en a rien à faire de ce que tu dis. Lui il sait quand, avec qui et pourquoi l'utiliser. Il est direct avec les personnes directement impliquées soit. Et il joue de l'effet média contre les sociétés/groupes. Quand il fait un fuck à Nvidia en conf filmée c'est pas un hasard. Je ne pense pas qu'il fasse la même chose à un commercial ou un standardiste dans la vraie vie… Tu peux dire la même choses de plein de façon différentes selon la situation.
Note que même si Linus était un connard malpoli je vois pas en quoi en quoi ca justifie le comportement de quelqu'un d'autre.
Je ne connais aucun media qui répond, ou qui répond mais VRAIMENT a coté de la plaque, a croire que personne ne sait pas lire.
C'est un autre problème. Est-ce que faire le lourdaud y change quelque chose ? Non. Si tu penses que c'est inutile il suffit de s'abstenir ! Si tu penses qu'il faut un moyen de pression, très bien. Mais je vois pas l’intérêt d'aller pisser sur un mec par ce que ca nous défoule mais ca n'apporte rien à la démarche.
Tu fais parti de la masse de gens qui se comportent comme des gros connards envers les personnes travaillant dans le service/commerce ? Tu sais tout les gens tellement importants et stressés qu'ils parlent et traitent les gens comme de la merde pour des broutilles dont ils ne sont pas responsables plutôt que de simplement s'exprimer et traiter l'autre comme une personne.
Je comprends pourquoi les gens que je connais qui sont dans le commerce ont des envies de meurtre à cause des connards qui se comportes comme toi. Ca te couterait cher d'énoncer ton point de vue simplement et calmement ? Le mec qui va se taper ton message il n'y est pour rien. C'est plus difficile de rédiger un message correct et poli ?
Ton message est contre productif. Premièrement plus tu brises les bonbons aux gens sans raison moins ils auront envie d'être ton pote et de t'aider. Deuxièmement ton message est pathétique entre menaces, vulgarité, argumentation à deux centimes sans aucune structure. Personne ne va ni prendre ça au sérieux, ni vouloir t'aider en quoi que ce soit
Bien que ne ressentant personnellement aucun lien corporatiste ou de communauté. J'ai un peu honte d'être de prêt ou de loin amalgamé à ton message. Tu te fais du mal et nous fais du mal à tous.
Donc un conseil, sois poli et traite les gens comme des humains. Tu verras ça devient tellement exceptionnel de nos jours que ça marche (bon la mec qui se tape les mails va pas faire changer la politique technique et recoder le truc dans la nuit hein. Mais peut être qu'il fera remonté au lieu de foutre ce caca à la poubelle.)
Tu aurais pu dire un truc du genre:
Bonjour,
Amateur de vélo je souhaitais m'abonner à Eurosport player afin de suivre la vuelta ce week-end. Cependant, utilisateur de Linux sur PC je constate que je ne peux pas m'abonner à Eurosport player, Le plugin Silverlight n'étant pas disponible sur cette plateforme.
Existe t-il une offre alternative répondant à mes besoins ? Si ce n'est pas le cas pourriez vous notifier de l'existence de ce trou dans votre offre. Je suppose que je ne suis pas le seul utilisateur de Linux voulant souscrire à vos service.
Enfin ayant eu du mal à trouver l'information, je pense que la FAQ devrait être plus accessible et la mention de Windows à lieu de PC serait préférable pour éviter toute confusion et déception de client.
Ca aura certainement le même impact: aucun. Car ce genre de choix technique est assumé. Par contre y'a un mec en moins sur terre qui aura envie de t'enfoncer des clous dans les yeux, et peut être qu'a force de demande le choix technique sera revu. Encore faut-il que les demandes ne partent pas directement à la poubelle…
Avec les ACL le mecs ne peut effacer que les fichiers sur lesquels il a les droits. Donc le mec peut lire le code HTML, mais n'avoir le droit que de modifier certains fichiers CSS. Alors que les fichiers sont lisibles aussi bien par le proxy nginx que par apache et qu'un autre stagiaire ne peut modifier que les fichiers images.
Ca doit bien scaler et être très productif de gérer les utilisateurs, au sens employé, qui font les modifications au niveau de la prod !
Tu te focalises sur la gestion des personnes alors que ce qui est important c'est la gestion des briques et de leurs interactions. Tu veux empêcher un mec particulier de modifier une brique où un boût de brique ? C'est pas à la prod de le faire. Par contre la prod elle peut décider d'isoler deux briques.
Bidouiller pour empêcher un stagiaire de modifier un fichier sur la prod, ca sent très mauvais pour l'orga. Comme tu le dis toi même, la fiabilité et la sécurité passe par une gestion/validation humaine de ce qui est livré. Processus en deux étapes. Conception du produit puis déploiement.
La surface d'attaque est l'ensemble de tous les répertoires que l'utilisateur (au sens uid) VCS peut lire ou écrire. Sans ACL cette surface est disproportionnée par rapport au besoin.
Donc tes ACL ne sont pas par utilisateur comme tu t'obstines à l'expliquer avec l'exemple du mauvais stagiaire qui pourrait suprimer un png alors qu'il doit faire que du css. Alors que ce n'est pas du tout pour ca qu'on s'en sert. C'est bien pour séparer les briques. On peut utiliser les ACLs mais tu peux aussi avoir deux UID différentes avec des instances différentes et reverse-proxifier, balancer ca dans des VM, où un milliard d'approches différentes en fonction des briques et technos (par ce que les ACL sur www on arrive vite aux limites de l'exemple).
Personne ne dit que les ACL ne servent à rien, bien au contraire. Mais la justification utilisées me laisse très perplexe. Vérouiller qui fait quelle modification sur la prod avec une granularité fichier/rep ca sent pas bon du tout. L'info du mec qui a fait le changement devrait être perdu depuis longtemps entre le VCS, le packaging et le déploiement et ce n'est pas là qu'il faut s'en soucier. D'ailleurs ton stagiaire il a un UID spécifique sur la prod ? Sinon pourquoi dire que c'est un stagiaire et pourquoi insister sur la relation avec les ACL alors que ce n'est pas la solution à ce problème ?
Peut importe que le chemin soit tortueux, passe par trente applis qui redistribuent les fichiers dans tous les sens et que quinze procédures de vérifications automatiques se déclenchent - la question est "le stagiaire peut-il créer des fichiers sur un répertoire situé sur le serveur sans l'intervention d'un admin ?"
L'admin on s'en balance et c'est pas son soucis. On livre des briques spécifiées, packagées et compartimentées. Le problème de qui a contribué cette ligne ou ce fichier dans chaque brique ce n'est pas son problème et il ne peut et veut de toute facon pas le gérer. L'admin à papa, ca n'existe plus car ca ne scale pas et ca n'a pas de valeur ajouté bien au contraire. On livre des paquets intégrés aux systèmes cibles dans des repos spéciaux qui répondent aux specs, avec des processus de mise en prod/rollback automatique. L'admin traditionel ne peut pas suivre le dev de 200 briques, avec des dizaines/centaines/milliers de gars qui bossent. Il ne comprend même pas les besoins fonctionnels des briques. Par contre on intégre les admin dans les équipes de dev par ce qu'ils ont pleins de choses intéressantes à dire sur les contraintes opérationelles ou sécu. Ca permet de les prendres en compte dès la conception et pas une fois que ca plante et ca leur permet de gauler l'infra pour les besoins de leurs utilisateurs.
Si je prends ton exemple, il y a fort longtemps j'ai contribué quelques chapitres aux deux handbooks de FreeBSD. J'ai donc créé les fichiers avec mes petites mains, créé des patchs, puis envoyé des patchs sur le BTS, puis quelqu'un a poussé les patchs sur de CVS, puis quelqu'un d'autre à merger les commits dans les différentes branches, qui se sont finallement automatiquement retrouvés publiés sur le www de FreeBSD.org.
Donc tu penses qu'il y a un problème de sécu avec ce processus ? Je suis le stagiaire là ! Où faudrait-il mettre des ACLs ? L'admin de FreeBSD.org ne sait même pas que j'existe. D'ailleurs pourquoi il le devrait. Ce qui l'intêresse lui c'est qu'un handbook produise des fichiers html non modifiable/exécutable dans un répertoire précis du wwww/ et rien en dehors. Et c'est comme ca qu'on assure la sécurité. Que j'ai modifié le chapitre 2 c'est pas son soucis. C'est le soucis des commiters doc qui s'assurent de la qualité/sécurité de leur produit (j'aurais très bien pu mettre un lien pishing ou effacer un paragraphe ACL ou non).
Mais ils apportent 0 au niveau sécurité.
Si on va part là, les ACL c'est la même chose. Le mec qui efface des ressources par erreur alors qu'il a le droit bha voilà… Ce n'est pas la bonne réponse.
Les politiques de sécurité doivent s'appliquer aux briques pas aux personnes. Pas de raison de plus compartimenter telle ou telle personne à l'exécution, ce n'est pas ca l'unité logique. Chaque brique est responsable de ce qui se passe chez elle. L'infra la compartimente, l'empêche de faire ce quelle ne doit pas faire, et assure l'isolation entre les briques. Les personnes n'ont rien a voir là dedans. Après chaque brique prend la resonsabilité de sa qualité et s'occupe de la question des personnes.
Et quand le stagiaire a besoin de pouvoir écrire (même indirectement) sur un répertoire qui doit être lisible par Apache mais pas par le monde entier, on se retrouve très vite limité avec les droits Unix standard - sur toute machine (même mono utilisateur) les ACL devraient être activés par défaut sur toutes les partitions, et l'admin ne devrait les éteindre que si il a une excellente raison de le faire. Ce n'est pas le cas aujourd'hui.
Si tu bosses comme ca tu es resté dans les années 80 ou il y a un énorme problème d'organisation. Je t'invite à regarder les processus de release engineering modernes.
En l'occurence ici tu as une brique fonctionnelle qui doit être isolée des autres sur lequel travail un stagiaire (mais ca pourrait être n'importe qui…). Cette brique va livrer des artifacts bien définis qui seront déployés à un endroit et un contexte sécu précis. Ta sécurité vient de là. Que la brique fasse de la merde fonctionnellement on s'en balance. De toute facon le taff du mec c'est de la modifier et l'admin ni comprend rien. Par contre elle ne peut pas impacter le reste, elle ne peut pas sortir. Et l'équipe qui s'occupe de la brique à plutôt intêret à se surveiller. C'est comme ca qu'on assure à la fois la sécurité du système, la qualité fonctionnelle et qu'on arrête d'avoir des équipes d'admin qui coûtent le même prix que les équipes de devs sans aucune plus value. Il vaut mieux les occuper à faire des choses utiles et contribué à la qualité du système en amont non ?
Feedbin is a simple, fast and nice looking RSS reader.
Je veux bien qu'il soit nice looking mais sur un matos d'hébergement personnel typique (Raspi, NAS, ou PogoPlug), ça m'étonnerait qu'il soit fast. Et simple…
Tu le fais exprès où tu n'es pas capable de contextualiser une phrase ? Elle fait bien entendu référence à l'utilisation du service.
Pour "l'hébergement personnel typique" ca n'a jamais été son but.
Tu veux dire que les bases de code spaghetti, sans design, pété de trou de sécu et où seul jean kevin qui l'a écrit peut y comprendre quelque chose vont finir par disparaitre ? Quelle mauvaise nouvelle !
Presque à chaque fois que j'ai jeté un coup d'oeil dans les sources d'un service php que j'hébergeai pour moi. Je me suis posé pleins de questions existentielles sur la vie.
Genre là pour Feedbin, faut 3 ou 4 processus différents qui tournent (Redis, Sidekiq, nginx, ruby, ….), avec une installation à rallonge, où tu dois définir 28 (j'ai compté) variables d'environnement, qui checkout la moitié des gems ruby dans ton home..
Tu viens de découvrir qu'il existe un fossé entre les objectifs des projets destiné à l'hébergement personnel et les services hébergés.
Pour l'un on veut des dépendances minimales, une installation simple et un footprint minimal en s'en tamponnant des perfs. Pour l'autre on cherche une architecture robuste pour assurer la résilience du service, qui sera capable d'encaisser la charge et qui dispose de briques évolutive pour répondre rapidement aux différentes évolutions fonctionnelles ou non-fonctionnelles (basiquement tu scales petit à petit tout ses composants qui deviennent des goulots d'étranglement).
Ces contraintes et objectifs sont très important à comprendre quand on évalue des produits ou des technos ainsi que quand on créer un produit. Et je pense que c'est un problème courant quand on lit les conneries sur telle ou telle technos alors que le mec n'a visiblement pas su cerner le contexte dans lequel elle avait un intêret.
C'est la tout le problème pour les produits libre destinés aux particuliers et voulant jouer sur les deux tableaux. Il faut souvent une partie cloud/hébergement pour se financer et ainsi pouvoir arriver à un niveau de développement qui permet de faire des produits qui évoluent vites et sont bien polishés (une bonne UI/UX ca coûte une blinde, ca demande pas mal de technique et c'est donc très rare). Mais si tu pars avec ce modèle en tête alors tu as un produit inadapté à l'auto-hébergement du geek qui veut faire tourner ses 300 services dans 32Mo de RAM sur un ARM. On ne peut pas tout avoir et il faut faire des choix.
Le stagiaire a accès à un truc qui accès au serveur ("un truc" pouvant être composé de milliers de programmes à la queue leu leu).
Donc le stagiaire a des droits sur le serveur.
Bon non c'est la base du développement de tout produit.
Le stagiaire comme la plupart des contributeur il a un espace de travail une branche dédiée où sur une branche d'intégration qui n'est pas directement reliée à la production. La granularité en module se fait générallement à ce niveau là, tu n'as accès qu'aux projets sur lesquels tu dois bosser. Après c'est le rôle de quelqu'un d'intégrer vers la production en ayant valider les changements et en s'assurant de la cohérence de l'ensemble. Cette chaîne peut souvent être hierarchique.
Bienvenue dans les années 2000 ! C'est juste la facon standard de travailler pour les gens qui ont réfléchit 10 minutes et ont compris que le problème n'était pas une question de droit d'accès sur le serveur. De toute facon tout est packagé correctement et livré automatiquement.
Tu penses que ce sont les ACL sur le www de kernel.org qui s'occupe de la sécurité du noyau où alors l'organisation hierarchique des relectures/intégrations. Par ce que la aussi ton argument s'applique: le stagiaire qui soumet un patch il a accès au serveur.
Il a dis que tu peut lancer LibO sans avoir java. Fait le test, tu remarquera que ça reste très lent a démarrer.
Effectivement. J'ai eu une vraie machine pour tester par ce que c'est sympa de parler dans le vide mais prendre 5 minutes pour essayer de comprendre c'est quand même mieux. On peut même le faire quand on ne connait rien de OOO/LO comme moi:
Fait 1: Aucune JVM n'est chargée au démarrage quand on lance LO ou qu'on ouvre/édite/sauve un text document ou un spreadsheet. On peut facilement le voir avec un strace. L'assertion du monsieur est donc une énorme connerie, le démarrage est lent… à cause d'un truc qui n'est jamais chargé ni exécuté…
Fait 2: Une JVM embarquée est bien démarrée lorsque l'on bascule sur une fonctionnalité qui en a besoin (il y en a peu). Par exemple en utilisant le module base on voit passer:
Une fois qu'on a le pid on peut interagir avec elle part les moyens standard sans aucun soucis pour regarder ce qu'elle fait.
Après on peut après s'amuser à mesurer le temps de démarrage avec les caches du VFS pleins ou non. Par exemple je mets ~10s à lancer/ouvrir un document/quitter à froid mais < 2s une fois les pages en cache. On peut après s'amuser à profiler le démarrage avec perf/oprofile/flamegraph pour ceux que ça intéresse mais ça va pas apprendre grand chose à ce niveau là Le temps de démarrage vient clairement majoritairement des IO…
Voilà je peux dire des conneries, mais ou moins j'ai essayé de me faire un avis objectif sur la question.
[^] # Re: débat sur le revenu de base
Posté par ckyl . En réponse au journal Initiative citoyenne pour le revenu de base. Évalué à 2.
La France, le seul pays où on forme volontiers gratos n'importe qui, pour les foutres à la porte juste après ?
[^] # Re: Engouement
Posté par ckyl . En réponse au journal J'avais envie de coder ce soir. Évalué à 2.
Tout à fait. J'ai mis mon cerveau en court circuit faignant: sort -R ou équivalent
Bien sur la discussion n'était que rhétorique vu le projet. Par contre des points intéressants sont il me semble:
[^] # Re: Engouement
Posté par ckyl . En réponse au journal J'avais envie de coder ce soir. Évalué à 6.
Avec du matos moderne, tu peux estimer la performance d'un PNRG basé sur un XOR-shift ou une congruence linéaire à ~500M/s. Je te laisse faire le calcul d'à partir de quel taux de remplissage de l'espace tu passes plus de 100ms à générer des nombres.
Après tu vas requêter ta BDD comme un bourrin pour voir si l'enregistrement existe, là ça va faire beaucoup plus mal et beaucoup beaucoup plus vite. En gardant une archi pourrie comme celle la, une technique est de minimiser le nombre de requêtes que tu vas faire pour vérifier si une URL existe déjà ou pas. Si tu as de la RAM avec un espace de 8G clés, utiliser un bitmap ça passe sans soucis. Mais tu peux faire un compris en utilisant des structures probabilistes à occupation mémoire sous linéaire. Soit de type set membership avec un bloom-filter, soit avec de la détection de doublon avec un Streaming Quotient Filter. Ca va vachement alléger le goulot qu'est la base.
Après la conception reste pourrie pour faire un truc sérieux, le service est voué à se dégrader alors qu'on peut très bien faire du non prédictible sans brute-forcer de pleins de manière. La plus conne serait de faire un shuffle une bonne fois pour toute de ton espace de clé, et ensuite de consommer élément par élément. Ca coûte n log(n), soit rien pour 8G élément, une bonne fois pour toute et après c'est constant. Mais il y a 100 façons différentes de faire un truc propre.
Après encore une fois, pondre un truc pour 2 utilisateurs ou 1 milliards c'est pas vraiment les mêmes objectifs dans la conception et la notion de "good enough"
[^] # Re: mignon
Posté par ckyl . En réponse au journal Initiative citoyenne pour le revenu de base. Évalué à 7.
C'est ton temps qui est perdu, l'entreprise ne perd que de l'argent (et ca doit se discuter). Elle n'est pas humaine, n'a pas de cerveau, pas de conscience et n'a pas de durée de vie. Toi si.
Fais le cacul de tes heures. Si tu as l'opportunité de pouvoir faire autre chose, ce raisonnement est très très très con. Tu choisis pertinemment de devenir un légume pendant 8h par jour alors que tu pourrais faire des choses qui t'épanouissent plus ou qui sont moins pénibles ?
Si on pousse le raisonnement à long terme, le jour où on te dit merci (par ce que ça va arriver) la suite risque d'être assez douloureuse. Nos métiers ont plutôt un cercle vertueux. Plus tu fais des trucs cools pour toi pendant ces heures, plus ta valeur marchande augmente et plus ta qualité de vie augmente (que ta priorité soit le temps, l'argent ou l'intêret). Se résigner à éteindre son cerveau c'est s’enterrer à petit feu. Tu te fermes les portes peu à peu et ça ne peut qu'empirer et finir par te retrouver bloquer.
Ca ne veut pas dire grand chose ca. On peut y caser tout et n'importe quoi.
[^] # Re: netbook ?
Posté par ckyl . En réponse au journal Une tablette pour programmer. Évalué à 2.
Si ma memoire est bonne je bossais entre 5 et 7h sans soucis. Quand tu as besoin de plus, tu mets la grosse/supplementaire.
Apres ca a pu changer.
[^] # Re: Intérêt par rapport à du SQL brut
Posté par ckyl . En réponse au journal python-sql n'est pas un ORM. Évalué à 3.
Merci il me manquait donc l'autre partie dont j'avais pas trouvé la spec (ce que tu dis est logique même si je le vois pas noir sur blanc dans la PEP) .
Par contre tu confirmes mon affirmation sur le but du projet: Un DSL python pour former des requêtes SQL ? Ni plus ni moins.
[^] # Re: Intérêt par rapport à du SQL brut
Posté par ckyl . En réponse au journal python-sql n'est pas un ORM. Évalué à 4.
Après ça dépend comment c'est utilisé et ou sont fait les vérifs. Mais de ce que j'ai compris ce n'est pas dans les buts du projet. C'est vraiment un DSL pour générer du SQL. L'auteur me corrigera si je dis des conneries.
Pour le code ca va très vite à explorer. Il n'y a pas de magie.
[^] # Re: Intérêt par rapport à du SQL brut
Posté par ckyl . En réponse au journal python-sql n'est pas un ORM. Évalué à 9. Dernière modification le 14 septembre 2013 à 18:17.
Pour le coup c'est un peu raté.
" python-sql […] est une librairie Python "
Plus sérieusement le scope de Linq et de python-sql me semblent très très différents et tu fais fausse route en les comparant. python-sql c'est juste une façon de générer des requêtes SQL depuis une API plutôt que d'écrire la chaîne SQL. Ni plus ni moins. Il n'y a aucun lien avec les objets métier, la base, les schema, ou la façon d'interroger la base. Ca n'offre presque aucune sécurité supplémentaire non plus, d'ailleurs à priori je ne vois aucun soucis pour faire une bête injection sql avec python-sql.
Python-sql n'a l'air de s'intéresser qu'à une toute petite partie très précise du problème. À voir si ca peut être utile et à quoi.
[^] # Re: nosql embarqué ?
Posté par ckyl . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 4.
Si tu veux la persistance et que tu as en tête les limites physiques des disques durs tu dois te rendre compte que la limite dure est assez basse. Soit tu as un cas d'utilisation très spécifique qui te permet d'aller chatouiller les perfs brutes (dès que les têtes commencent à bouger c'est vite mort), soit tu utilises du matos adapté à des lectures/écriture aléatoire: ssd, iofusion etc.
Seule solution si on veut pas faire un compromis sur la persistance sans modifier l'archi. Autrement on peut utiliser des techniques types event sourcing, archi distribuées pour être capable de reprendre sans rien perdre en cas de coupure.
[^] # Re: Arf
Posté par ckyl . En réponse au journal [ HS ] 10.000 Français se suicident chaque année. Évalué à 10.
Interdire la moto car les motards pratiquant réprésentent à eux seuls presque 10% des suicdes par an ?
(oui je suis un peu en avance…)
[^] # Re: La classe !
Posté par ckyl . En réponse à la dépêche Linux From Scratch fait sa rentrée des classes. Évalué à 2.
L'inutilité de quelque chose ne se mesure pas à sa taille en pixel. Ca la rend certe plus visible; mais le combat de fond est le même: on s'en balance.
[^] # Re: La classe !
Posté par ckyl . En réponse à la dépêche Linux From Scratch fait sa rentrée des classes. Évalué à 2.
C'est pas la même chose pour les +1000 et "je plussoie" ? Ca prend aussi plein de place et ca sert tout autant à rien non ?
[^] # Re: netbook ?
Posté par ckyl . En réponse au journal Une tablette pour programmer. Évalué à 4. Dernière modification le 10 septembre 2013 à 19:40.
Je sais pas sa réponse mais pourquoi spécifiquement XPS ? Un bon latitude E 13" ça doit faire dans les 1.6/1.8kg depuis des années (lire 5+ ans). C'est pas le prix d'une tablette ni le même poids. Mais c'est un très bon choix pour ceux cherchant un clavier de la puissance & mobilité et qui ont des vrais écrans à coté. Et tu peux te monter un bon laptop (i7 / 8Go / SSD) qui marche nickel, ne chauffe pas et ne prend pas grand chose comme place.
C'est juste dommage que la qualité/finition des latitudes ait régressé par rapport à il y a 4 ans où elle avait atteint son pic (comme presque tout le matos Dell d'ailleurs). J'ai eu un E 13" entre un mac book pro et un thinkpad, c'était pour moi le meilleur.
[^] # Re: Et l'accessibilite?
Posté par ckyl . En réponse à la dépêche AngularJS, une autre façon de faire du web. Évalué à 3.
Sauf si tu parles d'au moins plus de 10 ans en arrière, à ma connaissance ca à toujours été une légende.
Je n'ai jamais pu trouver une seule preuve de ce problème, et toutes les sources que j'ai trouvée semblent dire la même chose.
Souvent oui. Avec différents niveaux. Par exemple mal voyant et screen reader ce sont deux choses différentes. De même qu'être accessible au clavier. Même si pas mal de choses se recoupent.
Non ca veut dire que quand tu fais une appli correcte et que quand tu utilises des widgets corrects il n'y a pas de soucis pour les screen reader.
Si ca t'intéresse. Les pages d'IBM et de Dojo sont des bons points d'entrés pour trouver les refs et bonnes pratiques sur le sujet.
[^] # Re: Beurk
Posté par ckyl . En réponse au journal Interoperabilité, encore et encore.... Évalué à 8.
Tu n'as pas compris mon point. Linus est une personne publique, et il use de cette technique pour son côté buzz. Son message est publique et est un moyen de pression.
Toi, moi où l'auteur de ce journal ne somme pas des personnes publiques. Ton message est point-à-point avec la personne à qui tu t'adresses. Quelle est donc la stratégie de ne pas formuler très simplement qu'il est utilisateur de Linux et qu'il souhaiterait s'abonner ? Quelle est la plus value du style ado de 15 ans je sais tout, menace et dédaigneux ?
Tu résumes très bien le seul but de son message: "J'existe est-ce que tu veux mon argent ?"
Le style, la forme, l'effort fait pour formuler une demande très simple…
Réfléchi à comment tu réagis quand une personne tierce te contact en fonction de son attitude. Prends 10 secondes pour te mettre à la place de la personne à qui tu t'adresses.
Moi je fais clairement le parallèle avec les clients qui aggressent litérallement des commerciaux/vendeurs/représentant quand un produit est supprimé plutôt que de leur dire simplement qu'ils sont décus. Le mec en face de toi ce n'est pas lui qui à supprimé la ref ou décidé que le support Linux n'était pas au cahier des charges. C'est pas ton pote non plus, un peu de savoir vivre quoi. Un peu comme quand tu rapportes un bug ou fait une RFE quoi, la base du savoir vivre.
[^] # Re: Beurk
Posté par ckyl . En réponse au journal Interoperabilité, encore et encore.... Évalué à 3.
Tout à fait. Et on peut être direct et correct:
" Existe t-il une offre pour les utilisateurs de Linux où suis-je obligé de me tourner vers des sites de streaming illégaux puisque Eurosport n'est pas en mesure de me fournir le service dont j'ai besoin et que je souhaite payer ? "
Il me semble que c'est facile à comprendre sans agresser son interlocuteur. T'as une chance que le mec face +1 dans la bonne case pour te compter, ce qui est grosso modo la seule chose qu'il puisse faire.
[^] # Re: Beurk
Posté par ckyl . En réponse au journal Interoperabilité, encore et encore.... Évalué à 10.
En même temps tu n'es pas Linus et personne n'en a rien à faire de ce que tu dis. Lui il sait quand, avec qui et pourquoi l'utiliser. Il est direct avec les personnes directement impliquées soit. Et il joue de l'effet média contre les sociétés/groupes. Quand il fait un fuck à Nvidia en conf filmée c'est pas un hasard. Je ne pense pas qu'il fasse la même chose à un commercial ou un standardiste dans la vraie vie… Tu peux dire la même choses de plein de façon différentes selon la situation.
Note que même si Linus était un connard malpoli je vois pas en quoi en quoi ca justifie le comportement de quelqu'un d'autre.
C'est un autre problème. Est-ce que faire le lourdaud y change quelque chose ? Non. Si tu penses que c'est inutile il suffit de s'abstenir ! Si tu penses qu'il faut un moyen de pression, très bien. Mais je vois pas l’intérêt d'aller pisser sur un mec par ce que ca nous défoule mais ca n'apporte rien à la démarche.
Tu fais parti de la masse de gens qui se comportent comme des gros connards envers les personnes travaillant dans le service/commerce ? Tu sais tout les gens tellement importants et stressés qu'ils parlent et traitent les gens comme de la merde pour des broutilles dont ils ne sont pas responsables plutôt que de simplement s'exprimer et traiter l'autre comme une personne.
# Beurk
Posté par ckyl . En réponse au journal Interoperabilité, encore et encore.... Évalué à 10.
Ton message m'inspire trois pensées:
Je comprends pourquoi les gens que je connais qui sont dans le commerce ont des envies de meurtre à cause des connards qui se comportes comme toi. Ca te couterait cher d'énoncer ton point de vue simplement et calmement ? Le mec qui va se taper ton message il n'y est pour rien. C'est plus difficile de rédiger un message correct et poli ?
Ton message est contre productif. Premièrement plus tu brises les bonbons aux gens sans raison moins ils auront envie d'être ton pote et de t'aider. Deuxièmement ton message est pathétique entre menaces, vulgarité, argumentation à deux centimes sans aucune structure. Personne ne va ni prendre ça au sérieux, ni vouloir t'aider en quoi que ce soit
Bien que ne ressentant personnellement aucun lien corporatiste ou de communauté. J'ai un peu honte d'être de prêt ou de loin amalgamé à ton message. Tu te fais du mal et nous fais du mal à tous.
Donc un conseil, sois poli et traite les gens comme des humains. Tu verras ça devient tellement exceptionnel de nos jours que ça marche (bon la mec qui se tape les mails va pas faire changer la politique technique et recoder le truc dans la nuit hein. Mais peut être qu'il fera remonté au lieu de foutre ce caca à la poubelle.)
Tu aurais pu dire un truc du genre:
Ca aura certainement le même impact: aucun. Car ce genre de choix technique est assumé. Par contre y'a un mec en moins sur terre qui aura envie de t'enfoncer des clous dans les yeux, et peut être qu'a force de demande le choix technique sera revu. Encore faut-il que les demandes ne partent pas directement à la poubelle…
[^] # Re: Tout va bien, je t'assure
Posté par ckyl . En réponse au journal Les BSD isolés. Évalué à 1.
Ca doit bien scaler et être très productif de gérer les utilisateurs, au sens employé, qui font les modifications au niveau de la prod !
Tu te focalises sur la gestion des personnes alors que ce qui est important c'est la gestion des briques et de leurs interactions. Tu veux empêcher un mec particulier de modifier une brique où un boût de brique ? C'est pas à la prod de le faire. Par contre la prod elle peut décider d'isoler deux briques.
Bidouiller pour empêcher un stagiaire de modifier un fichier sur la prod, ca sent très mauvais pour l'orga. Comme tu le dis toi même, la fiabilité et la sécurité passe par une gestion/validation humaine de ce qui est livré. Processus en deux étapes. Conception du produit puis déploiement.
Donc tes ACL ne sont pas par utilisateur comme tu t'obstines à l'expliquer avec l'exemple du mauvais stagiaire qui pourrait suprimer un png alors qu'il doit faire que du css. Alors que ce n'est pas du tout pour ca qu'on s'en sert. C'est bien pour séparer les briques. On peut utiliser les ACLs mais tu peux aussi avoir deux UID différentes avec des instances différentes et reverse-proxifier, balancer ca dans des VM, où un milliard d'approches différentes en fonction des briques et technos (par ce que les ACL sur www on arrive vite aux limites de l'exemple).
Personne ne dit que les ACL ne servent à rien, bien au contraire. Mais la justification utilisées me laisse très perplexe. Vérouiller qui fait quelle modification sur la prod avec une granularité fichier/rep ca sent pas bon du tout. L'info du mec qui a fait le changement devrait être perdu depuis longtemps entre le VCS, le packaging et le déploiement et ce n'est pas là qu'il faut s'en soucier. D'ailleurs ton stagiaire il a un UID spécifique sur la prod ? Sinon pourquoi dire que c'est un stagiaire et pourquoi insister sur la relation avec les ACL alors que ce n'est pas la solution à ce problème ?
[^] # Re: Tout va bien, je t'assure
Posté par ckyl . En réponse au journal Les BSD isolés. Évalué à 4.
L'admin on s'en balance et c'est pas son soucis. On livre des briques spécifiées, packagées et compartimentées. Le problème de qui a contribué cette ligne ou ce fichier dans chaque brique ce n'est pas son problème et il ne peut et veut de toute facon pas le gérer. L'admin à papa, ca n'existe plus car ca ne scale pas et ca n'a pas de valeur ajouté bien au contraire. On livre des paquets intégrés aux systèmes cibles dans des repos spéciaux qui répondent aux specs, avec des processus de mise en prod/rollback automatique. L'admin traditionel ne peut pas suivre le dev de 200 briques, avec des dizaines/centaines/milliers de gars qui bossent. Il ne comprend même pas les besoins fonctionnels des briques. Par contre on intégre les admin dans les équipes de dev par ce qu'ils ont pleins de choses intéressantes à dire sur les contraintes opérationelles ou sécu. Ca permet de les prendres en compte dès la conception et pas une fois que ca plante et ca leur permet de gauler l'infra pour les besoins de leurs utilisateurs.
Si je prends ton exemple, il y a fort longtemps j'ai contribué quelques chapitres aux deux handbooks de FreeBSD. J'ai donc créé les fichiers avec mes petites mains, créé des patchs, puis envoyé des patchs sur le BTS, puis quelqu'un a poussé les patchs sur de CVS, puis quelqu'un d'autre à merger les commits dans les différentes branches, qui se sont finallement automatiquement retrouvés publiés sur le www de FreeBSD.org.
Donc tu penses qu'il y a un problème de sécu avec ce processus ? Je suis le stagiaire là ! Où faudrait-il mettre des ACLs ? L'admin de FreeBSD.org ne sait même pas que j'existe. D'ailleurs pourquoi il le devrait. Ce qui l'intêresse lui c'est qu'un handbook produise des fichiers html non modifiable/exécutable dans un répertoire précis du wwww/ et rien en dehors. Et c'est comme ca qu'on assure la sécurité. Que j'ai modifié le chapitre 2 c'est pas son soucis. C'est le soucis des commiters doc qui s'assurent de la qualité/sécurité de leur produit (j'aurais très bien pu mettre un lien pishing ou effacer un paragraphe ACL ou non).
Si on va part là, les ACL c'est la même chose. Le mec qui efface des ressources par erreur alors qu'il a le droit bha voilà… Ce n'est pas la bonne réponse.
Les politiques de sécurité doivent s'appliquer aux briques pas aux personnes. Pas de raison de plus compartimenter telle ou telle personne à l'exécution, ce n'est pas ca l'unité logique. Chaque brique est responsable de ce qui se passe chez elle. L'infra la compartimente, l'empêche de faire ce quelle ne doit pas faire, et assure l'isolation entre les briques. Les personnes n'ont rien a voir là dedans. Après chaque brique prend la resonsabilité de sa qualité et s'occupe de la question des personnes.
Si tu bosses comme ca tu es resté dans les années 80 ou il y a un énorme problème d'organisation. Je t'invite à regarder les processus de release engineering modernes.
En l'occurence ici tu as une brique fonctionnelle qui doit être isolée des autres sur lequel travail un stagiaire (mais ca pourrait être n'importe qui…). Cette brique va livrer des artifacts bien définis qui seront déployés à un endroit et un contexte sécu précis. Ta sécurité vient de là. Que la brique fasse de la merde fonctionnellement on s'en balance. De toute facon le taff du mec c'est de la modifier et l'admin ni comprend rien. Par contre elle ne peut pas impacter le reste, elle ne peut pas sortir. Et l'équipe qui s'occupe de la brique à plutôt intêret à se surveiller. C'est comme ca qu'on assure à la fois la sécurité du système, la qualité fonctionnelle et qu'on arrête d'avoir des équipes d'admin qui coûtent le même prix que les équipes de devs sans aucune plus value. Il vaut mieux les occuper à faire des choses utiles et contribué à la qualité du système en amont non ?
[^] # Re: Encore un truc que tu dois héberger sur un Quad Core
Posté par ckyl . En réponse à la dépêche Libération de Feedbin, lecteur de flux RSS/ATOM. Évalué à 1. Dernière modification le 07 septembre 2013 à 12:17.
Tu le fais exprès où tu n'es pas capable de contextualiser une phrase ? Elle fait bien entendu référence à l'utilisation du service.
Pour "l'hébergement personnel typique" ca n'a jamais été son but.
[^] # Re: Encore un truc que tu dois héberger sur un Quad Core
Posté par ckyl . En réponse à la dépêche Libération de Feedbin, lecteur de flux RSS/ATOM. Évalué à 4.
Tu veux dire que les bases de code spaghetti, sans design, pété de trou de sécu et où seul jean kevin qui l'a écrit peut y comprendre quelque chose vont finir par disparaitre ? Quelle mauvaise nouvelle !
Presque à chaque fois que j'ai jeté un coup d'oeil dans les sources d'un service php que j'hébergeai pour moi. Je me suis posé pleins de questions existentielles sur la vie.
[^] # Re: Encore un truc que tu dois héberger sur un Quad Core
Posté par ckyl . En réponse à la dépêche Libération de Feedbin, lecteur de flux RSS/ATOM. Évalué à 8.
Tu viens de découvrir qu'il existe un fossé entre les objectifs des projets destiné à l'hébergement personnel et les services hébergés.
Pour l'un on veut des dépendances minimales, une installation simple et un footprint minimal en s'en tamponnant des perfs. Pour l'autre on cherche une architecture robuste pour assurer la résilience du service, qui sera capable d'encaisser la charge et qui dispose de briques évolutive pour répondre rapidement aux différentes évolutions fonctionnelles ou non-fonctionnelles (basiquement tu scales petit à petit tout ses composants qui deviennent des goulots d'étranglement).
Ces contraintes et objectifs sont très important à comprendre quand on évalue des produits ou des technos ainsi que quand on créer un produit. Et je pense que c'est un problème courant quand on lit les conneries sur telle ou telle technos alors que le mec n'a visiblement pas su cerner le contexte dans lequel elle avait un intêret.
C'est la tout le problème pour les produits libre destinés aux particuliers et voulant jouer sur les deux tableaux. Il faut souvent une partie cloud/hébergement pour se financer et ainsi pouvoir arriver à un niveau de développement qui permet de faire des produits qui évoluent vites et sont bien polishés (une bonne UI/UX ca coûte une blinde, ca demande pas mal de technique et c'est donc très rare). Mais si tu pars avec ce modèle en tête alors tu as un produit inadapté à l'auto-hébergement du geek qui veut faire tourner ses 300 services dans 32Mo de RAM sur un ARM. On ne peut pas tout avoir et il faut faire des choix.
[^] # Re: Tout va bien, je t'assure
Posté par ckyl . En réponse au journal Les BSD isolés. Évalué à 5.
Bon non c'est la base du développement de tout produit.
Le stagiaire comme la plupart des contributeur il a un espace de travail une branche dédiée où sur une branche d'intégration qui n'est pas directement reliée à la production. La granularité en module se fait générallement à ce niveau là, tu n'as accès qu'aux projets sur lesquels tu dois bosser. Après c'est le rôle de quelqu'un d'intégrer vers la production en ayant valider les changements et en s'assurant de la cohérence de l'ensemble. Cette chaîne peut souvent être hierarchique.
Bienvenue dans les années 2000 ! C'est juste la facon standard de travailler pour les gens qui ont réfléchit 10 minutes et ont compris que le problème n'était pas une question de droit d'accès sur le serveur. De toute facon tout est packagé correctement et livré automatiquement.
Tu penses que ce sont les ACL sur le www de kernel.org qui s'occupe de la sécurité du noyau où alors l'organisation hierarchique des relectures/intégrations. Par ce que la aussi ton argument s'applique: le stagiaire qui soumet un patch il a accès au serveur.
[^] # Re: Tu es dur
Posté par ckyl . En réponse au journal MS Office c'est vraiment de la merde. Évalué à 6. Dernière modification le 05 septembre 2013 à 21:55.
Effectivement. J'ai eu une vraie machine pour tester par ce que c'est sympa de parler dans le vide mais prendre 5 minutes pour essayer de comprendre c'est quand même mieux. On peut même le faire quand on ne connait rien de OOO/LO comme moi:
Fait 1: Aucune JVM n'est chargée au démarrage quand on lance LO ou qu'on ouvre/édite/sauve un text document ou un spreadsheet. On peut facilement le voir avec un strace. L'assertion du monsieur est donc une énorme connerie, le démarrage est lent… à cause d'un truc qui n'est jamais chargé ni exécuté…
Fait 2: Une JVM embarquée est bien démarrée lorsque l'on bascule sur une fonctionnalité qui en a besoin (il y en a peu). Par exemple en utilisant le module base on voit passer:
Une fois qu'on a le pid on peut interagir avec elle part les moyens standard sans aucun soucis pour regarder ce qu'elle fait.
Après on peut après s'amuser à mesurer le temps de démarrage avec les caches du VFS pleins ou non. Par exemple je mets ~10s à lancer/ouvrir un document/quitter à froid mais < 2s une fois les pages en cache. On peut après s'amuser à profiler le démarrage avec perf/oprofile/flamegraph pour ceux que ça intéresse mais ça va pas apprendre grand chose à ce niveau là Le temps de démarrage vient clairement majoritairement des IO…
Voilà je peux dire des conneries, mais ou moins j'ai essayé de me faire un avis objectif sur la question.