La vache, on peut entendre son accent de l'est rien qu'en le lisant le pere alexey, pas besoin de connaitre son nom pour savoir de quelle region il vient :)
Tu t'énerves beaucoup, donc c'est durde savoir de quoi tu parles exactement, mais quand je lit ca:
Mettre à NULL aide le GC a ne jamais arriver au stade de faire une passe entière sur tout le graphe de flot de donnée.
Je me demande bien de quoi tu parles. Si tu parles du GC java, tu viens d'écrire une gigantesque connerie. Si tu parles de n'importe quel GC mark and sweep en fait, tu viens d'écrire une monumentale connerie (et j'espère bien que plus personne n'écrit de GC a retain count).
Si ta variable est locale et que tu ne t'en sert plus jusqu'a la fin de ton scope et que le JIT ne l'a pas deja optimised out (ca commence a faire pas mal de et la quand meme), certes, tu vas permettre a une potentielle passe du GC de la trouver avant la fin du scope.
Si tant est que le GC fait sa pause entre le moment ou tu penses avoir assigne ta variable a NULL et le moment ou le scope se serait fini et ou ton pointeur devient garbageable.
Oui, je dit "pense avoir assigne ta variable", parce que tu n'es pas sans savoir que le compile peut decider que c'est une idée a la con d'assigner NULL a une variable locale et virer l'instruction (et entre nous, c'est difficile de lui en vouloir de penser ca).
Si ta variable n'est pas locale, i.e. un membre vu que c'est un peu le seul moyen d'avoir une variable non locale en java, ben soit tu viens de fixer une leak gentillette (= vaguement equivalent a un malloc non balance par un free en c), en d'autre termes, un bug, soit tu viens de modifier le comportement de ton programme (i.e tu viens de créer un bug).
Bref, t'avoueras qu'au final le gain est maigre et vraiment hypothétique.
Sinon je veux bien que tu m'expliques en quoi le GC java va skipper les structures récursives ou profondément linkees (et surtout j'aimerais bien savoir ce qu'est une structure profondément linkee), sachant qu'il fonctionne surtout par generation, et qu'il va donc parcourir toute la heap appartenant a une generation.
Ensuite, le "on the fly progressif", comme tu dit, ca ne garantit pas de tout libérer, effectivement, et ca tombe bien, c'est le but. Le fait est que les jeunes generations meurent très jeunes et les vieilles ne meurent souvent jamais. En gros, des gens plus malin que toi se sont rendus compte que l'immense majorité des objets meurent soit très très vite, soit jamais.
Donc effectivement, tu ne libères pas tout en faisant une passe sur ta jeune generation, tu libères quasiment tout, et c'est bien le but.
En arriver à devoir du tuning aussi bas niveau que https://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues (premier lien en cherchant garbage collector performance dans google, je n'ai pas sélectionné, hein) est ridicule quand le but affiché du GC est de ne plus gérer la mémoire. C'est plus de travail de tuning qu'une allocation manuelle et tes moyens d'actions sont très limités.
Oui, parce qu'évidemment, gérer une heap de 8+GB avec du c++, c'est trivial, hein? D'ailleurs, FF n'a jamais eu de problèmes de fragmentation de heap qui gonflait en permanence son occupation mémoire, c'est bien connu!
Mon point est simplement qu'en dehors de cas où on veut avoir le maximum de performance, la gestion par un garbage collector offrait des performances suffisantes. On parlait d'une application graphique à la base, pas d'un serveur daemon ultra optimisé ni d'un application de calcul intensif.
Ben justement, les pauses gc sur une UI, c'est redibhitoire a mon sens de se taper un freeze, meme de qq millisecondes.
Alors, certes, concurrent gc, tout ca, mais c'est pas encore au top, et ca n'elimine pas toutes les pauses.
Le port OSX est plus ou moins dans le même état que le Windows il y a peu : fonctionnel, mais a besoin de quelqu'un qui le suive de près.
C'est toujours base sur le X11 de mascosx ou ils ont finit par utiliser cocoa?
Entre x11 et les raccourcis mappes sur ctrl plutot que cmd, c'etait vraiment une plaie a utiliser.
Chez les fat bastards, ca marche vaguement, de loin. Yes, No, un mot par ci par la, ca marchotte.
Je prefererais taper 1 pour continuer et 2 pour payer ma facture, ca m'éviterais de passer pour un con a dire oui, non, facture comme un con tout seul devant mon écran mais bon.
Et tu fais quoi une fois que tu l'as trouve, le process?
Tu lui d'arreter d'acceder disque?
Et si c'est un client bittorrent, un serveur http ou un outil de backup automatique, tu fais quoi?
J'ai pas besoin que tu m'expliques ce qu'est un sac a dos, merci. Et j'ai encore moins besoin que tu m'expliques comment me passer de ce dont j'ai besoin.
La taille et le design.
Un 17" c'est pas un portable, c'est un desktop deguise en portable. Personne n'en achete donc le produit est au mieux bacle.
La batterie tiendra que dalle, si elle tient le laptop pesera plusieurs kilo et te demontera l'epaule quand tu devras le trimballer. C'est tellement gros que ca rentre dans aucune sacoche presentable, et necessite une valise pour le trimballer (j'exagere a peine), ou plutot les espece d'horreurs noires avec 55 poches inutiles ete le putain de scratch qui fait un bruit dementiel.
Dire que ca devrait etre moins cher parce que c'est plus petit, c'est comme dire qu'un string en fine dentelle devrait etre moins cher que la culotte de grand mere parce que ya moins de tissu (et en encore moins si tu comptes les trous de la dentelle).
Ou encore dire qu'une smart devrait etre moins chere qu'un kangoo, parce que le kangoo il est plus gros.
3000, un mois de salaire?
Oula revoies ton ordre de grandeur, un dev pas mauvais de base, dans des technos pas specialement recherches, ca va taper dans les 2500-3000 net par quinzaine.
Pour un gars pas mauvais en c et en secu, tu doubles ca, facile. Et ca c'est le net, et ca inclue pas les bonus, stock, contributions 401k et autres assurances santes.
Pour des gens capables de faire des patchs corrects sur des softs decemment complexes et critiques, google leur offre gracieusement l'equivalent de 1 a 2 jours de paye par bounty. Perso je trouve que ca fait tres peu cher paye vu le temps passe sur un patch decent.
Je sais pas, ptetre que l'idee c'est d'inciter les devs de boites qui gardent leurs patchs au chaud a les contribuer?
Maigrichon? Une faille critique passee inapercue pendant 2 ans dans une distrib majeure t'appelles ca maigrichon?
Moi j'appelle ca un echec complet du processus de qualite - ca inclue aussi le processus de test de debian. Ca prouve que given enough eyeballs, all bugs are shallow est completement faux (ou que le "enough" est ridiculement eleve). Surtout quand on considere que c'est meme pas une revue du code qui a trouve le bug… En gros, les eyeballs n'ont servi strictement a rien.
C'est pas un concept nouveau dans le monde du development, mais le seul truc qui marche vraiment pour trouver les bugs, c'est des tests (automatiques si possible) qui tournent le plus souvent possible. Les yeux, ils font des erreurs, comme on le voit ici.
T'es libre de dire que ca ne concerne "que" debian, ca reste une des distribs majeures et le bug a impacte beaucoup de monde.
Non, on est pas d'accord du tout.
Une faille aussi beante restee ouverte aussi longtemps, ca a confirme ce que je pensais depuis un bail: personne ne relit le code, ceux qui le font n'ont pas les competences pour le faire bien, et ceux qui ont les competences ont bien trop de boulot pour le faire gracieusement.
Au final, la disponibilite du code te permet de comprendre comment la faille arrive, depuis combien de temps la faille est la, mais c'est a peu pres tout. Pour la corriger, faut toujours passer par les channels habituels de release. En gros, ca aide apres la decouverte de la faille, mais avant, c'est kifkif. Et la liberte de la licence n'y fait pas grand chose, du shared source a la ms fait aussi bien l'affaire.
Apres, oui, avoir le code, c'est mieux que ne pas l'avoir, mais la disponibilite du code ne presuppose en rien de la qualite de l'implementation. Si c'etait le cas, il suffirait de liberer IE6 pour en faire un bon browser, et je doute que la licence d'IE ait grand chose a voir avec l'activation par defaut des activex.
Et partir du principe que comme c'est proprio, c'est forcemment plombe par la nsa, c'est tres con comme raisonnement.
La faille dans Debian est restée 4 ans. Certes, c'est toujours une question de temps, mais ça reste énorme.
Et surtout, elle a ete trouvee completement par hasard (un gars s'est retrouve avec 2 fois la meme cle privee), le code n'a en rien aide a trouve la faille.
La double pensee marche vraiment bien chez toi!
Je laisse tomber, tu refuses de voir les choses comme elles sont et change les definitions pour qu'elles collent a ta vision biaisee du monde.
Pour faire simple: en asymetrique, un message signe avec un cle ne peut etre dechifre qu'avec l'autre cle.
Tu peux utiliser ca de deux facons:
- chiffre avec la cle publique, seul le possesseur de la cle prive peut dechiffrer: garantit la confidentialite, personne ne peut lire le contenu.
- chiffre avec la cle prive, tout le monde peut dechiffrer (la cle publique est, ben, publique): garantit l'authenticite (ie celui qui a envoye est bien celui que tu penses).
Partant de la, https fonctionne comme suit:
- requete du client au serveur: salut! Files moi ton cert publique
- reponse du serveur: tiens, voila, et au fait, files moi le tien tant qu'on y est. a ce point, les echanges sont en clair.
- le client verifie le certificat du serveur (cf plus bas), et envoie le sien au serveur, chiffre avec la cle publique du serveur. En https de base, le cert client est genere a la volee.
- le serveur verifie celui du client (ou pas, c'est optionel), et repond "ok, ca roule ma poule, envoie la sauce", chiffre avec la cle publique du client
- le client genere une cle symmetrique (une master key en fait, mais on va faire simple), la chiffre avec la cle publique du serveur et lui renvoie
- le serveur recupere la cle symetrique et ensuite, tous les echanges sont en chiffrage symetrique.
En gros, le protocole utilise:
- le chiffrement par cle prive pour garantir l'authenticite des hotes
- le chiffrement par cle publique pour garantir la confidentialite de l'echange de cle symmetrique.
- une fois le handshake ssl fini, on passe sur une crypto symetrique, vachement moins gourmande en ressources.
Si quelqu'un intercepte les communications pendant le handshake, l'asymetrique garantit que c'est pas lisible sans la cle privee, donc fiable.
De meme apres en symmetrique, c'est considere suffisament fiable sans la cle partagee, cle qui a ete generee a la volee pendant le handshake, et transmise de facon fiable, donc personne ne peut savoir ce qui se dit entre le client et le serveur.
L'idee derriere est en gros:
- on veut etre sur que les hotes sont bien ceux qu'ils pretendent. C'est pour ca qu'un certif pour www.google.com ne marchera pas pour google.fr
- la crypto symetrique marche plutot bien, mais l'echange de cle est tres problematique, donc on utilise de l'asymetrique, vachement plus fort et pratique, pour echanger les cles.
A noter qu'on parle de machines, donc un peu conne. Si tu possedes la cle privee d'un cert en google.com, alors tu es effectivement google.com aux yeux de toutes les machines. C'est pour ca que proteger ses cles prives est tres important.
Qu'est ce qui t'empeche de generer un certif pour google.com donc? La chaine de confiance. On introduit un tiers, dit de confiance, pour garantir que les certifs corrspondent bien aux entites physiques: tu fais confiance a verisign, qui en echange s'engage a verifier l'identite physique des personnes a qui ils delivrent un certificat.
Ces cert sont hashes, puis chiffres avec la cle privee de l'autorite, et ce hash inclu dans le cert.
De son cote, le client a une liste de certificat publique racines. Pour valider un cert: tu le hash, et tu dechiffre le hash inclu dans le cert avec la cle publique de l'autorite. Si ca correspond, le certificat publique est considere comme valide, et le process continue sans alerter l'utilisateur. Si ca match pas, le navigateur gueule comme un putois.
La partie client/serveur est trs robuste, et tres dur a casser, surtout en temps reel (mitm synchrone ou l'homme du milieu reencode tout a la volee).
La partie confiance, ben c'est de la confiance, donc c'est plus du ressort de l'etre humain qu'autre chose. Si verisign deconne a plein tube et files des certs pour google.com aux mechants hackers ukrainien, ca marche plus.
Si verisign se prends une requete de la nsa et doit leur donner leurs master keys privees, ca marche plus non plus, mais aucun protocole ne peut regler un probleme humain a cette echelle.
C'est pour ca aussi que le business de verisign peut etre vu comme douteux: tu paye un fort montant pour un hash de qq centaines de bits. Ca fait cher du bit au final, mais tu payes surtout pour l'infrastructure de verification derriere. D'aucuns diront que c'est des clampins, perso je m'engage pas sur cette pente savonneuse.
C'est l'avantage de ssl, c'est que ca passe tres tres bien a l'echelle d'un point de vue technique, et c'est aussi tres facile de revoquer des certificats si quelqu'un se met a deconner.
Comment ca pas imposé? Dans quel monde une dependence du metapquet n'est pas imposee par le mainteneur dudit paquet?
Si tu forkes le meta paquet, tu n'utilises plus debian. Si tu vires le metapaquet, tu n'utilises plus gnome (c'est toi qui le dit dans ton blog).
Adblock plus est bien impose par debian.
Apres si ton point est de dire que debian ne t'es pas impose et que tu peux utiliser autre chose, certes, mais si tu vas par la windows est libre aussi, personne ne te force a l'utiliser.
Est ce que tu te rends compte de la debilite de ta reponse?
Si t'es pas content, utilise pas debian, mais cet argument ne s'applique pas a windows, bizarrement.
Des dependences decentes et ne pas se voir repondre "t'as qu'a virer le meta paquet et perdre une heure a virer un paquet totalement pas indispensable du tout au systeme, tout ca pour se retrouver gros jean comme devant au premier paquet dependant de gnome" sur un ton condescendant?
La prochaine fois que tu viens raler pour IE installe de force dans windows, je te rappelerais ta position sur les logiciels preinstalle que "t'as qu'a pas les utiliser".
A se demander comment font les ricains, avec leurs elections en semaines.
Peut etre que… Mais oui! Suffit de faire passer une loi qui dit que c'est illegal d'empecher un employe d'aller voter. Apres tout, on a bien des lois qui interdisent de bosser alors, hein.
Posté par groumly .
En réponse au journal Travail dominical.
Évalué à 3.
Dernière modification le 08 octobre 2013 à 19:01.
D'un autre cote, quelqu'un de non qualifie a pas le choix non plus maintenant, c'est le dimanche et pis c'est marre. En fait, meme pas, chez macdo c'est impose par l'employeur et pis c'est marre.
Quelqu'un de non qualifie n'a pas le choix tout court, tu prends ce qui vient et tu fais avec.
Le probleme c'est de pas etre qualifie, pas d'autoriser le travail le dimanche. Si tu veux un bon taff ou tu poses tes conditions, ya pas dix mille solution, soit bon et bosse dur.
Si tu retournes des steaks a macdo, c'est sur que c'est dur d'avoir de la marge de manoeuvre de negociation, qu'est ce que tu proposes contre ca?
Ce raisonnement est parfaitement faux du fait même que les magasins ne vendent pas plus globalement en ouvrant le dimanche qu'en fermant le dimanche, justement parce que l'ensemble des salaires ne changent pas.
Et pourquoi ils veulent ouvrir le dimanche alors? Pour emmerder le monde, et rewind particulierement?
La masse salariale est donc figee a jamais, et on bloque? Parce qu'a t'ecouter, c'est un peu ce que tu dit la.
Et l'erreur dans ce raisonnement, comme dans le tien, c'est qu'ils ne produisent rien donc ils ne peuvent pas avoir le salaire qui va avec.
Comment ca ils produisent rien? Casto va ouvrir le dimanche et faire creuser des trous aux employes?
Ou ils vont vendre plus, ete embaucher des gens qui auront donc un salaire, et des sous a depenser, par exemple chez casto?
Dans l'exemple de la grande distribution, on va vite proposer deux choix aux gens:
1. Tu travailles le dimanche pour le même salaire
2. Tu te barres
Et donc, ils ferment le magasin un jour par semaine, vu que la duree du travail reste a 39 heures?
Ben ouais, s'ils forcent tous les employes a bosser le dimanche, et que ces employes bossent toujours 39 heures par semaine, ya bien un jour ou il va falloir fermer.
M'est avis que ca va pas plaire a auchan, qui va donc embaucher des gens, et faire travailler des gens le dimanche, et d'autres en semaines. Truc de ouf!
Ben ecoutes.
Casto machin veut ouvrir le dimanche.
Visiblement, ils ont pas envie de fermer le reste de la semaine.
Ils tournent donc une journee de plus, soit ~14%.
Il leur faut x employes par jour pour faire tourner le magasin. Ils vont donc, sur le magasin, employer x*1.14.
Evidemment, ca veut pas dire que casto machin va employer 13% de gens en plus, vu qu'ils ont pas mal d'employes de bureaux qui n'ont aucun interet a faire bosser le week end (encore que, a en ecouter ici, on croirait que toute la france va etre au charbon le dimanche), mais c'est quand meme dur de nier que ca fait du boulot en plus?
Bon, ensuite, s'ils veulent ouvrir le dimanche, c'est bien qu'ils estiment que ca va leur rapporter du fric, non?
Ils vont en faire quoi du fric? Se barrer avec et aller aux putes? Ou l'utiliser pour augmenter les ventes, et donc mecaniquement les magasins, fournisseurs, transporteurs, que sais je encore?
Peut etre qu'ils vont lancer leur propre marque de clous. Aller hop, du taff de creer. Ou vendre plus de boulons, aller hop, du taff en plus pour les boulonniers et pour les routiers.
Tant que c'est le choix du magasin de fermer, mais visiblement c'est pas le cas.
Dur de dire que c'est loyal comme concurrence quand meme.
Pareil : pas moins d'emploi sur le global. Juste moins de pognon pour CE MAGASIN LA PRECISEMENT
A l'instant T, si, ya moins d'emplois.
Puisque t'as pas l'air de voir de problemes avec une paye retardee, on va donc:
- retarder ta prochaine paye de 3 semaines (ca correspond a quand madame bob aura suffisament gueule pour bouger bob)
- te retirer 5%, parce que ya eu des frais de gestion de stock entre temps.
Tu commences a voir le probleme?
Non, Bob achetera quand meme ces 3 boulons, parce qu'il en a besoin pour réparer son étagère et que madame Bob arrete pas de gueuler qu'elle a besoin d'une étagère en plus. Et meme si ce que tu dis est vrai : aucune conséquence sur l'emploi
Ou il va mettre 2 clous et une vis de travers. Ou il va se barrer plutot du taff pour s'arreter a casto truc (et donc repercussion sur sa boite qui a rien demande a personne).
Ou il va devoir attendre plein de trucs a faire et cramer une demi journee de vacances.
J'ai du mal a voir en quoi chacune de ces situations est ideales, et en quoi c'est si catastrophique de les resoudre.
[^] # Re: la réponse est évidente
Posté par groumly . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 0.
La vache, on peut entendre son accent de l'est rien qu'en le lisant le pere alexey, pas besoin de connaitre son nom pour savoir de quelle region il vient :)
Interessant quand meme.
[^] # Re: la réponse est évidente
Posté par groumly . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 5.
Tu t'énerves beaucoup, donc c'est durde savoir de quoi tu parles exactement, mais quand je lit ca:
Je me demande bien de quoi tu parles. Si tu parles du GC java, tu viens d'écrire une gigantesque connerie. Si tu parles de n'importe quel GC mark and sweep en fait, tu viens d'écrire une monumentale connerie (et j'espère bien que plus personne n'écrit de GC a retain count).
Si ta variable est locale et que tu ne t'en sert plus jusqu'a la fin de ton scope et que le JIT ne l'a pas deja optimised out (ca commence a faire pas mal de et la quand meme), certes, tu vas permettre a une potentielle passe du GC de la trouver avant la fin du scope.
Si tant est que le GC fait sa pause entre le moment ou tu penses avoir assigne ta variable a NULL et le moment ou le scope se serait fini et ou ton pointeur devient garbageable.
Oui, je dit "pense avoir assigne ta variable", parce que tu n'es pas sans savoir que le compile peut decider que c'est une idée a la con d'assigner NULL a une variable locale et virer l'instruction (et entre nous, c'est difficile de lui en vouloir de penser ca).
Si ta variable n'est pas locale, i.e. un membre vu que c'est un peu le seul moyen d'avoir une variable non locale en java, ben soit tu viens de fixer une leak gentillette (= vaguement equivalent a un malloc non balance par un free en c), en d'autre termes, un bug, soit tu viens de modifier le comportement de ton programme (i.e tu viens de créer un bug).
Bref, t'avoueras qu'au final le gain est maigre et vraiment hypothétique.
Sinon je veux bien que tu m'expliques en quoi le GC java va skipper les structures récursives ou profondément linkees (et surtout j'aimerais bien savoir ce qu'est une structure profondément linkee), sachant qu'il fonctionne surtout par generation, et qu'il va donc parcourir toute la heap appartenant a une generation.
Ensuite, le "on the fly progressif", comme tu dit, ca ne garantit pas de tout libérer, effectivement, et ca tombe bien, c'est le but. Le fait est que les jeunes generations meurent très jeunes et les vieilles ne meurent souvent jamais. En gros, des gens plus malin que toi se sont rendus compte que l'immense majorité des objets meurent soit très très vite, soit jamais.
Donc effectivement, tu ne libères pas tout en faisant une passe sur ta jeune generation, tu libères quasiment tout, et c'est bien le but.
Oui, parce qu'évidemment, gérer une heap de 8+GB avec du c++, c'est trivial, hein? D'ailleurs, FF n'a jamais eu de problèmes de fragmentation de heap qui gonflait en permanence son occupation mémoire, c'est bien connu!
[^] # Re: la réponse est évidente
Posté par groumly . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Ben justement, les pauses gc sur une UI, c'est redibhitoire a mon sens de se taper un freeze, meme de qq millisecondes.
Alors, certes, concurrent gc, tout ca, mais c'est pas encore au top, et ca n'elimine pas toutes les pauses.
[^] # Re: Enfin !!!
Posté par groumly . En réponse au journal GTK+ 3 disponible officiellement pour Win32 !. Évalué à 6.
C'est toujours base sur le X11 de mascosx ou ils ont finit par utiliser cocoa?
Entre x11 et les raccourcis mappes sur ctrl plutot que cmd, c'etait vraiment une plaie a utiliser.
[^] # Re: Pareil chez les Caribous.
Posté par groumly . En réponse au journal Les serveurs vocaux c'est le mal. Évalué à 3.
Et encore, heureusement que les units utilisent pas de XML, sinon il nous aurait fait un double combo XML + UTF8.
[^] # Re: Pareil chez les Caribous.
Posté par groumly . En réponse au journal Les serveurs vocaux c'est le mal. Évalué à 6.
Chez les fat bastards, ca marche vaguement, de loin. Yes, No, un mot par ci par la, ca marchotte.
Je prefererais taper 1 pour continuer et 2 pour payer ma facture, ca m'éviterais de passer pour un con a dire oui, non, facture comme un con tout seul devant mon écran mais bon.
[^] # Re: Ne jamais attribuer à la malveillance ce que la stupidité suffit à expliquer.
Posté par groumly . En réponse au journal Obsolescence programmée ou pas ?. Évalué à 0.
Et tu fais quoi une fois que tu l'as trouve, le process?
Tu lui d'arreter d'acceder disque?
Et si c'est un client bittorrent, un serveur http ou un outil de backup automatique, tu fais quoi?
[^] # Re: Mir
Posté par groumly . En réponse au journal L'open source Tea party et Mark Shuttleworth. Évalué à 9.
Mmmh, leur message veut dire: nous n'acceptons pas l'attitude de canonical, sous entendu vis a vis de mir/wayland.
Si c'est pas politique, je sais pas ce que c'est.
[^] # Re: Cher ?
Posté par groumly . En réponse au journal Les portables OEM sous Ubuntu, ça vaut le coup?. Évalué à -2.
J'ai pas besoin que tu m'expliques ce qu'est un sac a dos, merci. Et j'ai encore moins besoin que tu m'expliques comment me passer de ce dont j'ai besoin.
Tu poses une question, j'y reponds.
[^] # Re: Cher ?
Posté par groumly . En réponse au journal Les portables OEM sous Ubuntu, ça vaut le coup?. Évalué à 1.
La taille et le design.
Un 17" c'est pas un portable, c'est un desktop deguise en portable. Personne n'en achete donc le produit est au mieux bacle.
La batterie tiendra que dalle, si elle tient le laptop pesera plusieurs kilo et te demontera l'epaule quand tu devras le trimballer. C'est tellement gros que ca rentre dans aucune sacoche presentable, et necessite une valise pour le trimballer (j'exagere a peine), ou plutot les espece d'horreurs noires avec 55 poches inutiles ete le putain de scratch qui fait un bruit dementiel.
Dire que ca devrait etre moins cher parce que c'est plus petit, c'est comme dire qu'un string en fine dentelle devrait etre moins cher que la culotte de grand mere parce que ya moins de tissu (et en encore moins si tu comptes les trous de la dentelle).
Ou encore dire qu'une smart devrait etre moins chere qu'un kangoo, parce que le kangoo il est plus gros.
[^] # Re: Il n’y a pas de petites économies.
Posté par groumly . En réponse à la dépêche Le programme de Google pour améliorer la sécurité des logiciels libres. Évalué à 4.
3000, un mois de salaire?
Oula revoies ton ordre de grandeur, un dev pas mauvais de base, dans des technos pas specialement recherches, ca va taper dans les 2500-3000 net par quinzaine.
Pour un gars pas mauvais en c et en secu, tu doubles ca, facile. Et ca c'est le net, et ca inclue pas les bonus, stock, contributions 401k et autres assurances santes.
Pour des gens capables de faire des patchs corrects sur des softs decemment complexes et critiques, google leur offre gracieusement l'equivalent de 1 a 2 jours de paye par bounty. Perso je trouve que ca fait tres peu cher paye vu le temps passe sur un patch decent.
Je sais pas, ptetre que l'idee c'est d'inciter les devs de boites qui gardent leurs patchs au chaud a les contribuer?
[^] # Re: Encore un point
Posté par groumly . En réponse au journal Scandale de la NSA et cryptographie, le vrai du faux. Évalué à -1.
Maigrichon? Une faille critique passee inapercue pendant 2 ans dans une distrib majeure t'appelles ca maigrichon?
Moi j'appelle ca un echec complet du processus de qualite - ca inclue aussi le processus de test de debian. Ca prouve que given enough eyeballs, all bugs are shallow est completement faux (ou que le "enough" est ridiculement eleve). Surtout quand on considere que c'est meme pas une revue du code qui a trouve le bug… En gros, les eyeballs n'ont servi strictement a rien.
C'est pas un concept nouveau dans le monde du development, mais le seul truc qui marche vraiment pour trouver les bugs, c'est des tests (automatiques si possible) qui tournent le plus souvent possible. Les yeux, ils font des erreurs, comme on le voit ici.
T'es libre de dire que ca ne concerne "que" debian, ca reste une des distribs majeures et le bug a impacte beaucoup de monde.
[^] # Re: Encore un point
Posté par groumly . En réponse au journal Scandale de la NSA et cryptographie, le vrai du faux. Évalué à 1.
Non, on est pas d'accord du tout.
Une faille aussi beante restee ouverte aussi longtemps, ca a confirme ce que je pensais depuis un bail: personne ne relit le code, ceux qui le font n'ont pas les competences pour le faire bien, et ceux qui ont les competences ont bien trop de boulot pour le faire gracieusement.
Au final, la disponibilite du code te permet de comprendre comment la faille arrive, depuis combien de temps la faille est la, mais c'est a peu pres tout. Pour la corriger, faut toujours passer par les channels habituels de release. En gros, ca aide apres la decouverte de la faille, mais avant, c'est kifkif. Et la liberte de la licence n'y fait pas grand chose, du shared source a la ms fait aussi bien l'affaire.
Apres, oui, avoir le code, c'est mieux que ne pas l'avoir, mais la disponibilite du code ne presuppose en rien de la qualite de l'implementation. Si c'etait le cas, il suffirait de liberer IE6 pour en faire un bon browser, et je doute que la licence d'IE ait grand chose a voir avec l'activation par defaut des activex.
Et partir du principe que comme c'est proprio, c'est forcemment plombe par la nsa, c'est tres con comme raisonnement.
[^] # Re: Encore un point
Posté par groumly . En réponse au journal Scandale de la NSA et cryptographie, le vrai du faux. Évalué à 3.
Et surtout, elle a ete trouvee completement par hasard (un gars s'est retrouve avec 2 fois la meme cle privee), le code n'a en rien aide a trouve la faille.
[^] # Re: Non
Posté par groumly . En réponse au journal Ayé (plus) : Adblock Plus n'est plus installé par défaut dans Debian. Évalué à 2.
La double pensee marche vraiment bien chez toi!
Je laisse tomber, tu refuses de voir les choses comme elles sont et change les definitions pour qu'elles collent a ta vision biaisee du monde.
[^] # Re: Toujours pas clair pour un néophyte
Posté par groumly . En réponse au journal Scandale de la NSA et cryptographie, le vrai du faux. Évalué à 7.
Pour faire simple: en asymetrique, un message signe avec un cle ne peut etre dechifre qu'avec l'autre cle.
Tu peux utiliser ca de deux facons:
- chiffre avec la cle publique, seul le possesseur de la cle prive peut dechiffrer: garantit la confidentialite, personne ne peut lire le contenu.
- chiffre avec la cle prive, tout le monde peut dechiffrer (la cle publique est, ben, publique): garantit l'authenticite (ie celui qui a envoye est bien celui que tu penses).
Partant de la, https fonctionne comme suit:
- requete du client au serveur: salut! Files moi ton cert publique
- reponse du serveur: tiens, voila, et au fait, files moi le tien tant qu'on y est. a ce point, les echanges sont en clair.
- le client verifie le certificat du serveur (cf plus bas), et envoie le sien au serveur, chiffre avec la cle publique du serveur. En https de base, le cert client est genere a la volee.
- le serveur verifie celui du client (ou pas, c'est optionel), et repond "ok, ca roule ma poule, envoie la sauce", chiffre avec la cle publique du client
- le client genere une cle symmetrique (une master key en fait, mais on va faire simple), la chiffre avec la cle publique du serveur et lui renvoie
- le serveur recupere la cle symetrique et ensuite, tous les echanges sont en chiffrage symetrique.
En gros, le protocole utilise:
- le chiffrement par cle prive pour garantir l'authenticite des hotes
- le chiffrement par cle publique pour garantir la confidentialite de l'echange de cle symmetrique.
- une fois le handshake ssl fini, on passe sur une crypto symetrique, vachement moins gourmande en ressources.
Si quelqu'un intercepte les communications pendant le handshake, l'asymetrique garantit que c'est pas lisible sans la cle privee, donc fiable.
De meme apres en symmetrique, c'est considere suffisament fiable sans la cle partagee, cle qui a ete generee a la volee pendant le handshake, et transmise de facon fiable, donc personne ne peut savoir ce qui se dit entre le client et le serveur.
L'idee derriere est en gros:
- on veut etre sur que les hotes sont bien ceux qu'ils pretendent. C'est pour ca qu'un certif pour www.google.com ne marchera pas pour google.fr
- la crypto symetrique marche plutot bien, mais l'echange de cle est tres problematique, donc on utilise de l'asymetrique, vachement plus fort et pratique, pour echanger les cles.
A noter qu'on parle de machines, donc un peu conne. Si tu possedes la cle privee d'un cert en google.com, alors tu es effectivement google.com aux yeux de toutes les machines. C'est pour ca que proteger ses cles prives est tres important.
Qu'est ce qui t'empeche de generer un certif pour google.com donc? La chaine de confiance. On introduit un tiers, dit de confiance, pour garantir que les certifs corrspondent bien aux entites physiques: tu fais confiance a verisign, qui en echange s'engage a verifier l'identite physique des personnes a qui ils delivrent un certificat.
Ces cert sont hashes, puis chiffres avec la cle privee de l'autorite, et ce hash inclu dans le cert.
De son cote, le client a une liste de certificat publique racines. Pour valider un cert: tu le hash, et tu dechiffre le hash inclu dans le cert avec la cle publique de l'autorite. Si ca correspond, le certificat publique est considere comme valide, et le process continue sans alerter l'utilisateur. Si ca match pas, le navigateur gueule comme un putois.
La partie client/serveur est trs robuste, et tres dur a casser, surtout en temps reel (mitm synchrone ou l'homme du milieu reencode tout a la volee).
La partie confiance, ben c'est de la confiance, donc c'est plus du ressort de l'etre humain qu'autre chose. Si verisign deconne a plein tube et files des certs pour google.com aux mechants hackers ukrainien, ca marche plus.
Si verisign se prends une requete de la nsa et doit leur donner leurs master keys privees, ca marche plus non plus, mais aucun protocole ne peut regler un probleme humain a cette echelle.
C'est pour ca aussi que le business de verisign peut etre vu comme douteux: tu paye un fort montant pour un hash de qq centaines de bits. Ca fait cher du bit au final, mais tu payes surtout pour l'infrastructure de verification derriere. D'aucuns diront que c'est des clampins, perso je m'engage pas sur cette pente savonneuse.
C'est l'avantage de ssl, c'est que ca passe tres tres bien a l'echelle d'un point de vue technique, et c'est aussi tres facile de revoquer des certificats si quelqu'un se met a deconner.
[^] # Re: Non
Posté par groumly . En réponse au journal Ayé (plus) : Adblock Plus n'est plus installé par défaut dans Debian. Évalué à 3.
Comment ca pas imposé? Dans quel monde une dependence du metapquet n'est pas imposee par le mainteneur dudit paquet?
Si tu forkes le meta paquet, tu n'utilises plus debian. Si tu vires le metapaquet, tu n'utilises plus gnome (c'est toi qui le dit dans ton blog).
Adblock plus est bien impose par debian.
Apres si ton point est de dire que debian ne t'es pas impose et que tu peux utiliser autre chose, certes, mais si tu vas par la windows est libre aussi, personne ne te force a l'utiliser.
[^] # Re: Non
Posté par groumly . En réponse au journal Ayé (plus) : Adblock Plus n'est plus installé par défaut dans Debian. Évalué à 5.
Est ce que tu te rends compte de la debilite de ta reponse?
Si t'es pas content, utilise pas debian, mais cet argument ne s'applique pas a windows, bizarrement.
[^] # Re: Non
Posté par groumly . En réponse au journal Ayé (plus) : Adblock Plus n'est plus installé par défaut dans Debian. Évalué à 7.
Des dependences decentes et ne pas se voir repondre "t'as qu'a virer le meta paquet et perdre une heure a virer un paquet totalement pas indispensable du tout au systeme, tout ca pour se retrouver gros jean comme devant au premier paquet dependant de gnome" sur un ton condescendant?
La prochaine fois que tu viens raler pour IE installe de force dans windows, je te rappelerais ta position sur les logiciels preinstalle que "t'as qu'a pas les utiliser".
[^] # Re: travail hebdomadaire
Posté par groumly . En réponse au journal Travail dominical. Évalué à -1.
A se demander comment font les ricains, avec leurs elections en semaines.
Peut etre que… Mais oui! Suffit de faire passer une loi qui dit que c'est illegal d'empecher un employe d'aller voter. Apres tout, on a bien des lois qui interdisent de bosser alors, hein.
[^] # Re: travail hebdomadaire
Posté par groumly . En réponse au journal Travail dominical. Évalué à 3. Dernière modification le 08 octobre 2013 à 19:01.
D'un autre cote, quelqu'un de non qualifie a pas le choix non plus maintenant, c'est le dimanche et pis c'est marre. En fait, meme pas, chez macdo c'est impose par l'employeur et pis c'est marre.
Quelqu'un de non qualifie n'a pas le choix tout court, tu prends ce qui vient et tu fais avec.
Le probleme c'est de pas etre qualifie, pas d'autoriser le travail le dimanche. Si tu veux un bon taff ou tu poses tes conditions, ya pas dix mille solution, soit bon et bosse dur.
Si tu retournes des steaks a macdo, c'est sur que c'est dur d'avoir de la marge de manoeuvre de negociation, qu'est ce que tu proposes contre ca?
[^] # Re: travail hebdomadaire
Posté par groumly . En réponse au journal Travail dominical. Évalué à 0.
Et pourquoi ils veulent ouvrir le dimanche alors? Pour emmerder le monde, et rewind particulierement?
La masse salariale est donc figee a jamais, et on bloque? Parce qu'a t'ecouter, c'est un peu ce que tu dit la.
Comment ca ils produisent rien? Casto va ouvrir le dimanche et faire creuser des trous aux employes?
Ou ils vont vendre plus, ete embaucher des gens qui auront donc un salaire, et des sous a depenser, par exemple chez casto?
[^] # Re: travail hebdomadaire
Posté par groumly . En réponse au journal Travail dominical. Évalué à -2.
Et donc, ils ferment le magasin un jour par semaine, vu que la duree du travail reste a 39 heures?
Ben ouais, s'ils forcent tous les employes a bosser le dimanche, et que ces employes bossent toujours 39 heures par semaine, ya bien un jour ou il va falloir fermer.
M'est avis que ca va pas plaire a auchan, qui va donc embaucher des gens, et faire travailler des gens le dimanche, et d'autres en semaines. Truc de ouf!
[^] # Re: travail hebdomadaire
Posté par groumly . En réponse au journal Travail dominical. Évalué à -1.
Ben ecoutes.
Casto machin veut ouvrir le dimanche.
Visiblement, ils ont pas envie de fermer le reste de la semaine.
Ils tournent donc une journee de plus, soit ~14%.
Il leur faut x employes par jour pour faire tourner le magasin. Ils vont donc, sur le magasin, employer x*1.14.
Evidemment, ca veut pas dire que casto machin va employer 13% de gens en plus, vu qu'ils ont pas mal d'employes de bureaux qui n'ont aucun interet a faire bosser le week end (encore que, a en ecouter ici, on croirait que toute la france va etre au charbon le dimanche), mais c'est quand meme dur de nier que ca fait du boulot en plus?
Bon, ensuite, s'ils veulent ouvrir le dimanche, c'est bien qu'ils estiment que ca va leur rapporter du fric, non?
Ils vont en faire quoi du fric? Se barrer avec et aller aux putes? Ou l'utiliser pour augmenter les ventes, et donc mecaniquement les magasins, fournisseurs, transporteurs, que sais je encore?
Peut etre qu'ils vont lancer leur propre marque de clous. Aller hop, du taff de creer. Ou vendre plus de boulons, aller hop, du taff en plus pour les boulonniers et pour les routiers.
[^] # Re: travail hebdomadaire
Posté par groumly . En réponse au journal Travail dominical. Évalué à 0.
Tant que c'est le choix du magasin de fermer, mais visiblement c'est pas le cas.
Dur de dire que c'est loyal comme concurrence quand meme.
A l'instant T, si, ya moins d'emplois.
Puisque t'as pas l'air de voir de problemes avec une paye retardee, on va donc:
- retarder ta prochaine paye de 3 semaines (ca correspond a quand madame bob aura suffisament gueule pour bouger bob)
- te retirer 5%, parce que ya eu des frais de gestion de stock entre temps.
Tu commences a voir le probleme?
Ou il va mettre 2 clous et une vis de travers. Ou il va se barrer plutot du taff pour s'arreter a casto truc (et donc repercussion sur sa boite qui a rien demande a personne).
Ou il va devoir attendre plein de trucs a faire et cramer une demi journee de vacances.
J'ai du mal a voir en quoi chacune de ces situations est ideales, et en quoi c'est si catastrophique de les resoudre.