Nicolas Boulay a écrit 15824 commentaires

Cites-nous un nouveau p-member qui était contre OOXML, histoire de voir ?

"La première sécurité est la liberté"

Et niveau sécurité de l'engin ? Il faut protéger sa source de temps ? Il faut empêcher a tout prix l'accès a la clef prive ?

Par ce que réaliser ce genre de compteur avec un écran, cela représente rien en électronique. (en gros, je sais faire)

Par contre, faire la même chose en protégeant toutes les IOs, c'est une autre paire de manche. (protection de la RTC, utilisation de puce de carte a puce pour planquer la clef, utiliser sans doute un autre uP pour gérer l'affichage, etc...)

J'imagine qu'un truc le moins chére possible mais non sécurisé pourrait amorcer le projet. Déjà si la clef prive dépend du porteur et non du systèmes, il y a moins besoin de sécuriser la calculette contre les attaques hardware (en gros que chaque carte contient une clef différente, cela complique les attaques sur la clef).

"La première sécurité est la liberté"

Si apres ca, pbpg nous ressort que MS n'est pas malfaisant...

"La première sécurité est la liberté"

disons que si le sujet est le token, on ne sait pas quel doivent être ses propriétés. Je vois bien le genre de calculette RSA mais est-ce qu'une clef usb avec un seul bouton ne suffirait pas ?

"La première sécurité est la liberté"

Les démarrages sont fastidieux. Mais après un moment, l'application démarre. Amarok tourne très bien par exemple. Même quelques jeux en 3D tourne bien.

"La première sécurité est la liberté"

Il n'y a pas toujours besoin d'avoir une implémentation super forte. Et c'est toujours utile d'avoir des implémentations de références.

De plus, certain téléphone ont des fonctionnalités proche de celle des cartes a puces.

"La première sécurité est la liberté"

C'était une final avec tout plein d'officiel dans les tribunes, avec l'ambiance anti violence autour des stades (et le ra le bole des "je me fous du foot" de dépenser autant pour la sécurité), il ne fallait pas être devin pour connaitre la réaction des autorités.

"La première sécurité est la liberté"

tu a écris la banderole ou quoi ?

"La première sécurité est la liberté"

Si tu veux lancer une discussion sur linuxfr, il faut l'ouvrir !

Je connais un peu la sécurité et un peu plus l'électronique, mais difficile de commenter quand il n'y a pas de problématique posée.

Qu'elles sont vos difficultés ? Qu'elle forme électronique ont les tokens ? Est-ce des cartes a puce, des clefs usb ou rien a voir ?

"La première sécurité est la liberté"

"En revanche les droits moraux sont inaliénables (donc pas cessible ) , perpétuel et imprescriptible (Art. L. 121-1)."

Sauf que dans les faits ces droits ne servent quasiement à rien. Le plus intéressant est que l'on préserve la paternité, "personne ne peut dire c'est moi qui l'ai fait".

L'autre droit, c'est le droit moral d'utilisation de l'œuvre, ou encore le droit de modification ou de retrait. Dans les faits, on ne peut les exercer car il faut dédommager les propriétaires de toutes pertes.

"La première sécurité est la liberté"

Tentes avec le dernier kernel de Linus.

"La première sécurité est la liberté"

La corruption de donnés peut provenir de la RAM, du disque dure (mais j'aurais tendance à l'exclure vu la quantité de correction possible), le cablage, mais aussi un bug dma ou du contrôleur disque (fake raid?).

Bref, cela peut être plein de choses. Il faut aussi vérifier les messages d'insulte IDE qui pourrait se trouver dans les logs.

Le type de la machine, son age, pourrait aidé. Est-ce que tu viens de faire un upgrade ou pas ? (si elle est ressente, cela peut être un bug d'incompatibilité entre périphérique, essaye dans ce cas de virer l'utilisation des DMA par exemple ). A-t-elle plus de 4Go de RAM? c'est pas courant et cela semble parfois poser problème. En 64 bits ?

"La première sécurité est la liberté"

Je comprends tout à fait les problèmes des dev de kernel. Mais sa réponse ne parlait pas vraiment de ça.

De plus, le genre de code kernel dont tu parles est le coeur de Linux, pas vraiment les drivers par exemple. Or, c'est le plus gros du code.

"La première sécurité est la liberté"

Si tu fais un truc type seti@home, j'imagine qu'il ne faut pas compter à plus d'un échange par seconde entre la racine et chaque noeud. Si tu as le droits à quelques dizaines de seconde par coups, cela doit pouvoir être faisable en distribuant des sous-arbres à fusionner ensuite.

Chaque noeud peut partir dans son "délire" tout seul dans son coin et "resynchroniser" toutes les secondes. Même si tu doubles le boulot à faire, si tu as 1 000 machines, tu t'en fous.

"La première sécurité est la liberté"

Ce qui revient au même... L'origine de l'état change mais sinon, c'est la même chose.

"La première sécurité est la liberté"

Si ton programme se parallélise pas trop mal, le premier gagnant sera le premier programme avec un fonctionnement proche de seti@home ou folding.

Tu peux ainsi avoir un cluster de quelque milliers de machines, voir beaucoup plus.

"La première sécurité est la liberté"

Euh.... Fonctionelement c'est quoi la différence ?

Au réveil, à l'appel de la fonction dédiées, le périphérique doit être dans le même état qu'avant que cela soit par copie recopie d'une plage de registre ou que cela soit par une phase d'init et de reconfiguration.

Cela revient au même. L'état est sauvé en RAM et restaurer ensuite. Tous les périphériques passent de toutes façon par une phase de reset, le problème c'est que cela n'est pas forcément possible de reseter un module précis.

"La première sécurité est la liberté"

"Les gens qui se chargent d'attaques personelles (corrompus, etc...) sont plutot dans le camp anti-OOXML, comme les gens de l'ISO et autres(Patrick Durusau, ...) l'ont remarque."

Quand tout un comité technique pense et affirme non, mais que son président s'abstient finalement après certain contact, on pense qu'il y a un problème. Quand cela se produit dans son propre pays, on se dit que la grosse boite a vraiment tout pourris pour en arriver là.

Je me rappelle tes commentaires concernant les mails et document limite sectaire de ta boite du procès antitrust. Tu nous traitais limite de bisounours ou d'attardé-mental de croire que les grosses boites pouvaient penser autrement.

Dans ma boite (américaine), il n'y a pas de slide où "We work for the customers" barré 4 fois, avec au final "we work for microsoft". Ici, il y a des posters dans les bureaux "Solve the customers problems".

Je crois que tu es complètement déformé par la propagande interne de ta boite, tu en as même perdu le sens moral au point de justifier les horreurs que montre les documents du procès anti-trust. La boite te répète que tout le monde pense comme cela, alors tu les crois. Et cela justifie par la même occasion tout comportement immoral.

"La première sécurité est la liberté"

Je suis tout à fait d'accord, surtout avec ton dernier point :)

Mais il y a des cas ou le premier point est moins vrai typiquement : le cas de CAN, ou les mainteneurs s'en foutent, ou le cas de hardware super complexe pour des gros drivers bas niveau, là il faut déjà avoir le matos et ensuite pourvoir comprendre la doc.

"La première sécurité est la liberté"

J'ai regardé quelques fonctions d'endormissement de certains drivers. Souvent ils sous-entendent uniquement du suspend-to-ram sans perte de l'état interne du périphérique. Ce qui est évidement absurde dans le cas du suspend to disk et pas franchement gagné pour le suspend to ram (ou tu coupes le jus de tout sauf la DDR qui est en auto refresh)

Bref, il y a un gros soucis de sauvegarde et de restauration d'état dans beaucoup de drivers.

"La première sécurité est la liberté"

Parce que "l'autre" manière de travailler c'est de faire son patch dans son coin pour ses clients et ne pas perdre du temps à chercher à l'inclure.

L'effort supplémentaire pour le faire inclure est souvent jugé hors de proportion et surtout ne respecte pas les planning des boites (même si je comprends que les mainteneurs s'en foutent).

"La première sécurité est la liberté"

"1 an, c'est rien pour une entreprise..."

Tu me fais marrer (jaune) ! Et je bosse ou à ton avis dans mon garage ?

Je bosse pour une boite pour qui 6 mois de plus est déjà trop, et la boite est énorme.

Et après, ca viendra avec le temps...

C'est bien ça le problème !

Faire son truc dans son coin et balancer ce qui est fait en open source, c'est déjà fait. Mais il y a une perte en ligne monstrueuse sur les fonctionnalité par rapport à ce qui touche le kernel vanilia.

Vu le niveau "générique" de ta réponse, je crois que tu es bien loin du dev kernel, et du dev dans une grosse boite qui aimerait avoir plus de code en mainstream.

"La première sécurité est la liberté"

Finalement, Microsoft agit comme une grosse boite qui a les moyens.

Ce qui est hallucinant, c'est toute les personnes de l'état français qui agissent uniquement en faveur d'une grosse boite US et quelques un de ses satellites au détriment de toutes les autres boites dont les françaises, les citoyens et l'administration elle-même (on va bien rigoler quand il voudront ouvrir leur document openxml office2007 avec office2012).

Je ne pense pas que MS soit si-puissant. Il doit y avoir quelques FanBoys MS bien placé, je ne vois que cela.

"ne pas mettre sur le dos de la malice ce qui peut l'être par la bêtise"

"La première sécurité est la liberté"

L'histoire de l'inclusion de la pile CAN me rappelle les problèmes que l'on a ici sur l'inclusion de chose dans Linux. Je me rappelle aussi les appels/voeux pieux de Linux concernant le fait d'intégrer de nouveau codeur plus gentiellement/facilement.

1 an, semble énorme pour beaucoup d'entreprise. J'ai lu un peu les threads d'échange pointé par les différentes articles.

So we have to be patient and i personally have to perform the task "It is therefore your responsibility to make the work interesting to the networking developers and fun to review." given by David Miller ...

But this task is hard to perform, when there's no feedback from the netdev guys and when it's not very interesting by design (of CAN) ;-( I have no idea when PF_CAN becomes that interesting to the major players like Patrik McHardy and David Miller, so that the code gets finally reviewed. I assume that is no sufficient answer for your question. Btw. i backed off for two weeks now and i'm patient.

J'aime particulièrement le passage ou il est dis que les nouveau venu doivent montrer du code intéressant pour être revu... J'imagine la tête des équipes soft avec ce genre de "requirement"....

J'ai vraiment l'impression qu'il y a une différence entre la volonté affiché d'intégrer et d'accueillir les nouveaux venu et la réalité. La réalité, c'est la liste des mainteneurs juste en dessous de Linus, qui décide réellement si votre sous-système est digne d'intérêt. Et si vous devez passer par plusieurs mainteneurs, vous êtres mal barré (au hasard: le mainteneur d'une sub-arch arm qui réfère au mainteneur arm qui réfère à Linus).

En gros, si la boite n'emploie pas un dev déjà reconnu au niveau de Linux, elle perd un temps fou pour son problème soit pris en compte ou son code revu.

En tout cas, cela n'encourage pas du tout à pousser sa boite à se mettre dans la boucle...

"La première sécurité est la liberté"

L'origine de mon point de vue était de dire que la GPL a eu plus de succès dans ses réalisations que l'open source type BSD.

C'est toi qui a parlé des lignes de code comme mesures du succès. Linux est en effet 2 à 3 fois plus petit que Eclipse. Mais mon exemple concernait Linux dans son environnement : une distribution Linux.

Ensuite, j'ai rajouté que le nombre de ligne de code n'est pas forcément un bon repère surtout pour un OS où l'on recherche la légerté et un IDE dont le code non utilisé n'a pas d'impact.

D'aprés ta slide 46, Eclispe, c'est une trentaine de boite et 11 millions de lignes de code. Si tu compares cela à tout ce qui veut s'appeler "Gnu", il y a de la marge.

"La première sécurité est la liberté"