L'ecran 1920*1080 px, mais n'offre que la moitie de ca en points.
En gros, ca se presente aux applis comme du 960x540, le but etant d'avoir une grande qualite d'affichage: chaque point est rendu par 4 pixels, 2x2). Ca elimine l'aliasing sur les fontes et dessin, tu ne vois plus les pixels sur les photos (de qualite suffisante, evidemment), bref ca fait un bien meilleur rendu.
Ton n900 avait 100dpi, soit moins du quart de ce que t'as avec un nexus.
La resolution ridiculement grande, au final elle fait que 950x500 qqchose, hein, le but c'est d'avoir une definition retina, de rendre chaque point sur 4 pixels pour avoir un rendu tres precis, au point de ne plus distinguer les pixels, justement.
45GB de musique, une bonne dizaine de gigo en photos aussi.
J'ai un compte itunes match, mais je telecharge TOUT sur le telephone. J'ai autre chose a foutre le matin que de me demander ce que je veux ecouter, et quand t'es dans un avion, ta connection lte tu peux te la mettre au cul. Quand au wifi de l'avion, ben c'est pas vraiment au top.
Idem quand je suis dans le metro sous la baie, au 4ieme sous sol du parking ou tout simplement dans une zone d'ombre niveau couverture.
Ah, et derniere chose, mon plan data, je prefere l'utiliser pour autre chose que telecharge de la musique (comme du thethering ou autre usage gourmand).
Mon laptop stream tout par contre, quand je suis dessus, j'ai du wifi, et meme si j'en ai pas, ben j'ai mon telephone.
Ps: tu serais pas en train de nous faire un "16gb should be enough for everyone", des fois?
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.
[^] # Re: Pendant ce temps à Mountain View
Posté par groumly . En réponse au journal Le Neo900 est officiellement annoncé. Évalué à 1.
l'o po copris.
[^] # Re: Pendant ce temps à Mountain View
Posté par groumly . En réponse au journal Le Neo900 est officiellement annoncé. Évalué à 2.
L'ecran 1920*1080 px, mais n'offre que la moitie de ca en points.
En gros, ca se presente aux applis comme du 960x540, le but etant d'avoir une grande qualite d'affichage: chaque point est rendu par 4 pixels, 2x2). Ca elimine l'aliasing sur les fontes et dessin, tu ne vois plus les pixels sur les photos (de qualite suffisante, evidemment), bref ca fait un bien meilleur rendu.
Ton n900 avait 100dpi, soit moins du quart de ce que t'as avec un nexus.
[^] # Re: Pendant ce temps à Mountain View
Posté par groumly . En réponse au journal Le Neo900 est officiellement annoncé. Évalué à 4.
La resolution ridiculement grande, au final elle fait que 950x500 qqchose, hein, le but c'est d'avoir une definition retina, de rendre chaque point sur 4 pixels pour avoir un rendu tres precis, au point de ne plus distinguer les pixels, justement.
[^] # Re: Pendant ce temps à Mountain View
Posté par groumly . En réponse au journal Le Neo900 est officiellement annoncé. Évalué à 8.
45GB de musique, une bonne dizaine de gigo en photos aussi.
J'ai un compte itunes match, mais je telecharge TOUT sur le telephone. J'ai autre chose a foutre le matin que de me demander ce que je veux ecouter, et quand t'es dans un avion, ta connection lte tu peux te la mettre au cul. Quand au wifi de l'avion, ben c'est pas vraiment au top.
Idem quand je suis dans le metro sous la baie, au 4ieme sous sol du parking ou tout simplement dans une zone d'ombre niveau couverture.
Ah, et derniere chose, mon plan data, je prefere l'utiliser pour autre chose que telecharge de la musique (comme du thethering ou autre usage gourmand).
Mon laptop stream tout par contre, quand je suis dessus, j'ai du wifi, et meme si j'en ai pas, ben j'ai mon telephone.
Ps: tu serais pas en train de nous faire un "16gb should be enough for everyone", des fois?
[^] # Re: Pendant ce temps à Mountain View
Posté par groumly . En réponse au journal Le Neo900 est officiellement annoncé. Évalué à -2.
Waou, 32GB, google vient de rentrer de plein pied dans l'annee 2010.
[^] # 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.