Faut assumer mon chèr, quand tu postes des aneries de manière répetitive, tu te fais remettre en place.
De temps en temps, ca arrive à tout le monde hein, moi, Zenitram et autres compris. Mais ce n'est de loin pas la première fois que tu nous ressors ton histoire sur la securité et le LL ici, alors ques tes arguments ont déjà été demontré comment totalement sans fondement.
Maintenant, si tu préfères évidemment précher dans un bocal où tout le monde pense comme toi, fais seulement, mais ça ne te fera certainement pas avancer, ça te fera juste continuer à garder la tête dans le sable et te demander pourquoi le reste du monde ne suit pas à la lettre tes idées.
T'as oublié de nous mettre aussi une press release de Laurent Blanc disant que le PSG est la meilleure équipe du monde et une autre de José Mourihno disant que c'est Chelsea.
Je n'ai jamais compris pourquoi en informatique on accepte la vente de systèmes opaques qui empêchent l'amélioration de la qualité et de la sécurité et pourquoi on punit les personnes qui luttent contre cela.
Parce que les gens en charge ont, contrairement à toi, compris que ce que tu racontes ne tient pas debout et que faire ce que tu dis ne changerait en rien la qualité ou la securité.
Mais au moins, il a été possible de le voir et de le corriger. Après, c'est une question de moyens et de volonté. Mais sans au préalable une ouverture du code source, c'est mort d'avance.
Le fait qu'aucune de ces failles n'ait été trouvée grâce au code contredit totalement ce que tu racontes. Avoir les sources ouvertes clairement n'a pas aidé, et cela prouve aussi qu'on peut trouver les failles sans les sources.
On peut aussi envisager par exemple que certaines écoles d'informatique proposent des projets d'étude pour analyser des codes et trouver des failles de conception ou d'écriture. Ce serait de bons sujets bien plus intéressant que des projets montés de toute pièce.
Merci de confirmer ce que je pensais depuis le début, tu ne connais absolument rien à ce sujet.
oui, et j'en ai parfaitement le droit lorsque ma sécurité ou ma vie privée est en jeu ou celle de nombreuses personnes. Et lorsqu'on lit tous les jours les attaques réussies sur des systèmes opaques et qu'on en voit les conséquences désastreuses, on ne peut plus accepter ce risque.
Marrant, parce que les conséquences sont tout aussi désastreuses du coté du LL, il n'y a pas moins de problèmes, mais pourtant tu ne te focalises que sur un coté, en sortant l'idiotie que les convertir en projets de l'autre coté va miraculeusement résoudre le problème alors que les LL existants sont toujours aussi troués.
Non vraiment, tout ce que tu fais c'est du délit de sale gueule informatique, tu n'as absolument aucune connaissance du sujet, les faits vont à l'encontre de ce que tu racontes, et pourtant tu t'obstines.
c'est à l'éditeur d'ouvrir le code afin qu'on s'assure qu'il a bien mis les moyens financiers pour le sécuriser correctement.
Ah la belle connerie ! On a bien vu avec OpenSSL que les gens se contre-foutent de vérifier, et qu'être en libre ne change rien à l'affaire.
mais l'ouverture du code doit être exigée pour vérifier que les éditeurs ont bien fait leur travail en payant des gens compétents et non en confiant l'écriture du code à des stagiaires ou à des intervenants successifs qui ont chacun à leur tour fait leur soupe. Ça, ça se détecte assez vite. Et un mouchard aussi.
Sérieusement, arrêtes de parler d'un sujet auquel tu ne connais visiblement rien du tout. Un mouchard ça se cache facilement même dans du code ouvert.
Mais quelles conneries tu nous sors… ça te tenterait d’arrêter de parler de ce que tu ne connais pas ?
Les boites proprios les plus grosses mettent certainement plus de moyens que les projets OSS les plus gros (MS, Google, Apple), elles ont des dizaines d'experts payés pour et n'hésitent pas à engager des boites spécialisées quand le besoin se fait sentir.
Les petites boites proprios, elles n'en font pas bcp, mais inutile de dire que c'est la même chose pour les petits projets libres.
Les problèmes de sécurité informatique ne sont bien sûr pas les mêmes qu'en mécanique et qu'en électronique mais ce sont aussi des problèmes de sécurité et ils sont complexes et coûteux à résoudre, bien plus qu'en mécanique et qu'en électronique.
Oui oui bien sur ! Dis moi donc combien couterait la correction d'une faille HW dans un CPU Intel que je rigole.
Depuis quand l'Église est invité à émettre son avis sur un mariage civil qui est détaché de toute religion ?
Je ne vois aucun problème à ce qu'ils émettent un avis.
Je veux dire, même mon chien coin peut le faire, ça veut pas dire pour autant qu'on va l'écouter. Le seul truc qu'il ne faut pas faire, c'est leur donner un pouvoir de décision.
A Seattle c'est la même chose, et non c'est pas mieux. Tu veux vivre dans un était policier ? Alors oui c'est mieux, mais à part ça ils ont ici une manière de faire qui antagonise la population contre la police, qui se retourne en devenant plus violente, ce qui antagonise encore plus la population, etc…
Non vraiment, la France c'est peut-être pas parfait, mais je suggères d'éviter le modèle US…
Si je modifie la dll "machin.dll", et qu'il y a un bug dans la dll "truc.dll", comment "truc.dll" peut-il être décalé ? comment le débugage de truc.dll m'informe du contenu de machin.dll ?
Faut comprendre que quand tu debug un probleme, en faisant du step-by-step dans un debugger, tu passes frequemment d'un dll a un autre au fil des fonctions.
1) le débuggeur, sans symbole de débuggage, n'est pas capable de retrouver la ligne.
T'imagines bien que MS génère et garde les symboles de debuggage pour tous les binaires qu'il publie, c'est impossible de properement debugger un problème sans ça.
Évidemment, la plupart des employés ne sont pas informé de ce workflow, tout comme les employés ne sont pas informé des fraudes fiscales prévues dans le workflow dans certaines entreprises.
La différence est que dans le cas financier, c'est au final la tête qui regroupe les résultats de différents groupes qui n'ont pas accès à tout, ils ne peuvent pas voir si il y a eu magouille car leurs chiffres personnels ne peuvent pas être directement reliés.
Avec du code, l'origine du code dans un module est clair : c'est tel groupe de 3-4 développeurs. Lorsque ils debuggent un problème et voient que le binaire ne correspond pas au code, ou voient que le code dans le dépot a changé et ils ne reconnaissent pas le changement, c'est immédiatement visible. A moins d'avoir tous les développeurs et testeurs de ce module dans la poche, ça va être dur de faire passer en douce un changement. Totalement impossible ? Non, mais c'est pas mal plus dur que trouver une faille dans le code que ces développeurs ont écrit par exemple je dirais.
Quand il y a un bug sous Windows, tout le code de Windows est analysé, dans toutes les dll ?
Quand tu insères du code dans un binaire, ça décale tout le code de diffèrentes manières. Si qq'un rapporte un bug dans ce binaire, ou un binaire relatif, et qu'un développeur charge le schmilblick dans un debugger pour voir ce qu'il se passe, il verra que les lignes de code sont décalées par rapport à l'assembleur indiqué par le debugger, voire même le debugger lui dira directement que le binaire ne correspond pas aux symboles de debuggage si l'attaquant n'a pas fait l'effort/réussi à modifier les symboles de debuggage en même temps.
Et oui, ca n'a rien de spécifique à Windows, c'est vrai pour Linux aussi.
Et tout les développeurs ont systématiquement tout le code dans toutes les versions distribuées, qu'ils recompilent parallèlement entièrement ?
Compilent-ils tous sur exactement la même machine ? Avec un compilateur et une machine qui ont exactement le même état ?
Cela n'a rien à voir avec le problème. Le problème est la correspondance entre lignes de code (que les développeurs ont évidemment), et ce que les symboles de debug disent. Si ton debugger à un moment te dit qu'il y a un appel de fonction, et tu vois une ligne de code disant "int a = 4+20;", tu sais qu'il y a qqe chose qui foire.
Et tout ça c'est évidemment sans parler du fait que les binaires sont signés d'habitude(du moins pour Windows, Office et autres softs), faudrait que le gars arrive à faire son changement dans l'intervalle entre la génération des binaires et leur signature, sinon il devra poser lui même une requête de signature(ça demande typiquement 2-3 personnes, donc il devra avoir des complices déjà), et inutile de dire que ça va tout de suite alerter tout le monde. Ça va pas être du gâteau.
En ce qui concerne l'accès au code source: s'il est si restreint et contrôlé, cela pose les mêmes problèmes d'avoir un petit nombre de personne y ayant accès / contrôle (remplace "de haut niveau administratif" par "de haut niveau de contrôle de l'accès").
Non du tout, c'est très différent. Si tu prends le cas de Microsoft, ou Amazon, ou Google, … t'as des centaines et centaines (voire milliers selon les projets hein) de développeurs/testeurs, t'as quelque dizaines de managers de 1-2ème niveau, et au dessus c'est le "haut management".
Ces sociétés ont toutes des permissions sur leur code source, géré par groupe, avec un pare-feu humain pour joindre le groupe. Tu regardes typiquement qui est la personne, pour qui il bosse et quel est le titre de son job pour décider quand tu reçois la requête, il y a une automatisation pour expédier les requêtes ou c'est super évident (le gars est dans la hiérarchie du VP du bon groupe, son titre est développeur, …). Ça te dit si il bosse dans le bon département, si il est sensé avoir accès au code, … et il y a toujours le manager de la personne en CC: sur l'email histoire qu'il soit au courant. C'est au final très simple et une requète "bizarre" se voit très vite.
Façile ? Non justement. La force de la NSA ce sont ces informaticiens, leur spécialité est tout ce qui est technique. Des gars derrière leur écran, dans les bureaux de la NSA.
Se faire passer pour quelqu'un d'autre en public, mentir de manière efficace pendant des semaines et des mois, … devant des gens, c'est pas forcément leur spécialité.
Pas forcèment plus qu'en interne à la boite, car oh grande nouvelle, plusieurs personnes lisent le même code en interne aussi, et tout le monde n'est pas employé par la NSA.
Parce que le jour ou un bug est rapporté, les développeurs chargent le binaire publié, et se rendent très vite compte que le code (et les symboles de débuggage si l'effort est fait de les modifier aussi) ne correspondent pas au code qu'ils ont.
Sans parler du fait qu'être placé très haut ne signifie pas que la personne a accès aux machines.
Tu peux être sur que les VPs et autres de Windows n'avaient pas accès aux machines de build et aux dépots de code source par exemple, car tout le monde doit faire la demande. Et une demande de leur part d'avoir un accès, surtout en écriture, vu leur job, aurait été vue avec énormement de suspicion par les gens en charge d'autoriser la requète.
Tout a fait, c'est possible, c'est par contre légèrement plus complique que ce que tu écris :
Faut qu'il y ait un poste disponible la ou tu veux mettre la backdoor. Te faire engager dans le team marketing ou vente ça va pas aider
Faut que tu passes l'interview quand même
Faudra que tu insères la backdoor dans la partie de code qui t'es assignée point de vue boulot, sinon ça va amener des questions…
T'as typiquement un background check dans nombre de boites, et ça force le fait que la personne qui est engagée soit un développeur, tu peux pas envoyer n'importe quel agent de terrain. En remote c'est évidemment plus facile car pas d'interactions face à face et 8h par jour.
Bref, la barre est quand même plus élevée qu'apparaître de nulle part et envoyer des patchs à un projet.
Hardware
- ECS EXEC/BASIC ROM, containing the built-in BASIC programming language and additional BIOS routines to handle the added hardware features
- additional 2kB of system RAM (supposedly, the system could be further expanded to as much as 64kB with add-on memory modules, but no such modules ever made it to production)
- additional AY-3-8910 sound chip (this was the same sound chip used in the Intellivision)
- a cassette recorder/printer interface (used the same peripherals as the Mattel Aquarius)
- two additional input ports for the alphanumeric Computer Keyboard, the Music Synthesizer keyboard, or two additional Intellivision Game Controllers.
[^] # Re: je suis effaré
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 1.
Faut assumer mon chèr, quand tu postes des aneries de manière répetitive, tu te fais remettre en place.
De temps en temps, ca arrive à tout le monde hein, moi, Zenitram et autres compris. Mais ce n'est de loin pas la première fois que tu nous ressors ton histoire sur la securité et le LL ici, alors ques tes arguments ont déjà été demontré comment totalement sans fondement.
Maintenant, si tu préfères évidemment précher dans un bocal où tout le monde pense comme toi, fais seulement, mais ça ne te fera certainement pas avancer, ça te fera juste continuer à garder la tête dans le sable et te demander pourquoi le reste du monde ne suit pas à la lettre tes idées.
[^] # Re: je suis effaré
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 0.
LOL merci pour ce grand moment d'humour !
T'as oublié de nous mettre aussi une press release de Laurent Blanc disant que le PSG est la meilleure équipe du monde et une autre de José Mourihno disant que c'est Chelsea.
[^] # Re: ennuis
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à -1.
Parce que les gens en charge ont, contrairement à toi, compris que ce que tu racontes ne tient pas debout et que faire ce que tu dis ne changerait en rien la qualité ou la securité.
[^] # Re: ennuis
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 0.
Le fait qu'aucune de ces failles n'ait été trouvée grâce au code contredit totalement ce que tu racontes. Avoir les sources ouvertes clairement n'a pas aidé, et cela prouve aussi qu'on peut trouver les failles sans les sources.
[^] # Re: ennuis
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 0.
Et il y a plein de petites boites software ou les devs aiment eux aussi le travail bien fait…
[^] # Re: ennuis
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 1.
Merci de confirmer ce que je pensais depuis le début, tu ne connais absolument rien à ce sujet.
Marrant, parce que les conséquences sont tout aussi désastreuses du coté du LL, il n'y a pas moins de problèmes, mais pourtant tu ne te focalises que sur un coté, en sortant l'idiotie que les convertir en projets de l'autre coté va miraculeusement résoudre le problème alors que les LL existants sont toujours aussi troués.
Non vraiment, tout ce que tu fais c'est du délit de sale gueule informatique, tu n'as absolument aucune connaissance du sujet, les faits vont à l'encontre de ce que tu racontes, et pourtant tu t'obstines.
[^] # Re: ennuis
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 1. Dernière modification le 12 janvier 2015 à 15:09.
Et tu crois que c'est different pour le LL hors les gros projets ? Tu crois que des experts s'amusent a aller revoir le code de projets obscurs ?
[^] # Re: ennuis
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 3.
c'est à l'éditeur d'ouvrir le code afin qu'on s'assure qu'il a bien mis les moyens financiers pour le sécuriser correctement.
Ah la belle connerie ! On a bien vu avec OpenSSL que les gens se contre-foutent de vérifier, et qu'être en libre ne change rien à l'affaire.
Sérieusement, arrêtes de parler d'un sujet auquel tu ne connais visiblement rien du tout. Un mouchard ça se cache facilement même dans du code ouvert.
[^] # Re: ennuis
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 0.
Mais quelles conneries tu nous sors… ça te tenterait d’arrêter de parler de ce que tu ne connais pas ?
Les boites proprios les plus grosses mettent certainement plus de moyens que les projets OSS les plus gros (MS, Google, Apple), elles ont des dizaines d'experts payés pour et n'hésitent pas à engager des boites spécialisées quand le besoin se fait sentir.
Les petites boites proprios, elles n'en font pas bcp, mais inutile de dire que c'est la même chose pour les petits projets libres.
[^] # Re: ennuis
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 6. Dernière modification le 12 janvier 2015 à 11:12.
Heartbleed : https://www.youtube.com/watch?v=ezjRv_7iZZM --> analyse de traffic reseau resultant de tests de fuzzing
Shellshock : http://www.openwall.com/lists/oss-security/2014/10/08/17 " I did not find it by
looking at bash's code either."
Quand a corriger le bug, tu me fais bien rire. Et tu le testes comment le code ? Et tu l'integres comment ? Et tu maintiens ton fork comment ?
C'est irrealisable sur le long terme de faire son propre patch pour 99% de la planete, c'est le groupe maintenant le composant qui doit le faire.
[^] # Re: Résistance aux pannes ou aux attaques ?
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 1.
Oui oui bien sur ! Dis moi donc combien couterait la correction d'une faille HW dans un CPU Intel que je rigole.
[^] # Re: ennuis
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 4.
Grosse connerie, aucun, je dis bien AUCUN de ces bugs n'a été trouvé en lisant le code.
[^] # Re: ennuis
Posté par pasBill pasGates . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à -1.
Ah oui ? Comment oses-tu dés lors dire que les logiciels propriétaires sont mal écrits ?
[^] # Re: Contre-sens "Barbare"?
Posté par pasBill pasGates . En réponse au journal Liberté d'expression sous les balles. Évalué à 3.
Bof… Johnny Halliday qui exprime une opinion lui aussi a un effet sur une partie des gens… c'est triste, mais c'est comme ca…
[^] # Re: Contre-sens "Barbare"?
Posté par pasBill pasGates . En réponse au journal Liberté d'expression sous les balles. Évalué à 3.
Je ne vois aucun problème à ce qu'ils émettent un avis.
Je veux dire, même mon chien coin peut le faire, ça veut pas dire pour autant qu'on va l'écouter. Le seul truc qu'il ne faut pas faire, c'est leur donner un pouvoir de décision.
[^] # Re: Et c'est une belle merde
Posté par pasBill pasGates . En réponse au journal Manu est avec vous. Évalué à 10.
A Seattle c'est la même chose, et non c'est pas mieux. Tu veux vivre dans un était policier ? Alors oui c'est mieux, mais à part ça ils ont ici une manière de faire qui antagonise la population contre la police, qui se retourne en devenant plus violente, ce qui antagonise encore plus la population, etc…
Non vraiment, la France c'est peut-être pas parfait, mais je suggères d'éviter le modèle US…
[^] # Re: Compléments
Posté par pasBill pasGates . En réponse au journal tor et la nsa. Évalué à -1.
Faut comprendre que quand tu debug un probleme, en faisant du step-by-step dans un debugger, tu passes frequemment d'un dll a un autre au fil des fonctions.
T'imagines bien que MS génère et garde les symboles de debuggage pour tous les binaires qu'il publie, c'est impossible de properement debugger un problème sans ça.
La différence est que dans le cas financier, c'est au final la tête qui regroupe les résultats de différents groupes qui n'ont pas accès à tout, ils ne peuvent pas voir si il y a eu magouille car leurs chiffres personnels ne peuvent pas être directement reliés.
Avec du code, l'origine du code dans un module est clair : c'est tel groupe de 3-4 développeurs. Lorsque ils debuggent un problème et voient que le binaire ne correspond pas au code, ou voient que le code dans le dépot a changé et ils ne reconnaissent pas le changement, c'est immédiatement visible. A moins d'avoir tous les développeurs et testeurs de ce module dans la poche, ça va être dur de faire passer en douce un changement. Totalement impossible ? Non, mais c'est pas mal plus dur que trouver une faille dans le code que ces développeurs ont écrit par exemple je dirais.
[^] # Re: Et les batteries ?
Posté par pasBill pasGates . En réponse au journal Tesla Motors VS the rest of the world. Évalué à 4.
Transports en commun sous-développés ? Je t'invites à venir visiter les USA mon cher, tu verras à quel point la France est bien de ce côté…
[^] # Re: Et pourtant une autre révolution est en marche
Posté par pasBill pasGates . En réponse au journal Tesla Motors VS the rest of the world. Évalué à 7.
L’épisode est qu'il a décidé une fois pour toute que les voitures ne seraient pas autonomes avec 100 ou 200 ans, et rien ne le fera changer d'avis.
[^] # Re: Compléments
Posté par pasBill pasGates . En réponse au journal tor et la nsa. Évalué à 2.
Quand tu insères du code dans un binaire, ça décale tout le code de diffèrentes manières. Si qq'un rapporte un bug dans ce binaire, ou un binaire relatif, et qu'un développeur charge le schmilblick dans un debugger pour voir ce qu'il se passe, il verra que les lignes de code sont décalées par rapport à l'assembleur indiqué par le debugger, voire même le debugger lui dira directement que le binaire ne correspond pas aux symboles de debuggage si l'attaquant n'a pas fait l'effort/réussi à modifier les symboles de debuggage en même temps.
Et oui, ca n'a rien de spécifique à Windows, c'est vrai pour Linux aussi.
Cela n'a rien à voir avec le problème. Le problème est la correspondance entre lignes de code (que les développeurs ont évidemment), et ce que les symboles de debug disent. Si ton debugger à un moment te dit qu'il y a un appel de fonction, et tu vois une ligne de code disant "int a = 4+20;", tu sais qu'il y a qqe chose qui foire.
Et tout ça c'est évidemment sans parler du fait que les binaires sont signés d'habitude(du moins pour Windows, Office et autres softs), faudrait que le gars arrive à faire son changement dans l'intervalle entre la génération des binaires et leur signature, sinon il devra poser lui même une requête de signature(ça demande typiquement 2-3 personnes, donc il devra avoir des complices déjà), et inutile de dire que ça va tout de suite alerter tout le monde. Ça va pas être du gâteau.
Non du tout, c'est très différent. Si tu prends le cas de Microsoft, ou Amazon, ou Google, … t'as des centaines et centaines (voire milliers selon les projets hein) de développeurs/testeurs, t'as quelque dizaines de managers de 1-2ème niveau, et au dessus c'est le "haut management".
Ces sociétés ont toutes des permissions sur leur code source, géré par groupe, avec un pare-feu humain pour joindre le groupe. Tu regardes typiquement qui est la personne, pour qui il bosse et quel est le titre de son job pour décider quand tu reçois la requête, il y a une automatisation pour expédier les requêtes ou c'est super évident (le gars est dans la hiérarchie du VP du bon groupe, son titre est développeur, …). Ça te dit si il bosse dans le bon département, si il est sensé avoir accès au code, … et il y a toujours le manager de la personne en CC: sur l'email histoire qu'il soit au courant. C'est au final très simple et une requète "bizarre" se voit très vite.
[^] # Re: Compléments
Posté par pasBill pasGates . En réponse au journal tor et la nsa. Évalué à 0.
Façile ? Non justement. La force de la NSA ce sont ces informaticiens, leur spécialité est tout ce qui est technique. Des gars derrière leur écran, dans les bureaux de la NSA.
Se faire passer pour quelqu'un d'autre en public, mentir de manière efficace pendant des semaines et des mois, … devant des gens, c'est pas forcément leur spécialité.
[^] # Re: Compléments
Posté par pasBill pasGates . En réponse au journal tor et la nsa. Évalué à 0.
Pas forcèment plus qu'en interne à la boite, car oh grande nouvelle, plusieurs personnes lisent le même code en interne aussi, et tout le monde n'est pas employé par la NSA.
[^] # Re: Compléments
Posté par pasBill pasGates . En réponse au journal tor et la nsa. Évalué à 1.
Ben non, ca ne marche pas.
Parce que le jour ou un bug est rapporté, les développeurs chargent le binaire publié, et se rendent très vite compte que le code (et les symboles de débuggage si l'effort est fait de les modifier aussi) ne correspondent pas au code qu'ils ont.
Sans parler du fait qu'être placé très haut ne signifie pas que la personne a accès aux machines.
Tu peux être sur que les VPs et autres de Windows n'avaient pas accès aux machines de build et aux dépots de code source par exemple, car tout le monde doit faire la demande. Et une demande de leur part d'avoir un accès, surtout en écriture, vu leur job, aurait été vue avec énormement de suspicion par les gens en charge d'autoriser la requète.
[^] # Re: Compléments
Posté par pasBill pasGates . En réponse au journal tor et la nsa. Évalué à -1.
Tout a fait, c'est possible, c'est par contre légèrement plus complique que ce que tu écris :
Bref, la barre est quand même plus élevée qu'apparaître de nulle part et envoyer des patchs à un projet.
[^] # Re: Deux autres...
Posté par pasBill pasGates . En réponse au journal ARM: Etat des lieu dans la communauté linux. Évalué à 4.
http://en.wikipedia.org/wiki/Entertainment_Computer_System
Hardware
- ECS EXEC/BASIC ROM, containing the built-in BASIC programming language and additional BIOS routines to handle the added hardware features
- additional 2kB of system RAM (supposedly, the system could be further expanded to as much as 64kB with add-on memory modules, but no such modules ever made it to production)
- additional AY-3-8910 sound chip (this was the same sound chip used in the Intellivision)
- a cassette recorder/printer interface (used the same peripherals as the Mattel Aquarius)
- two additional input ports for the alphanumeric Computer Keyboard, the Music Synthesizer keyboard, or two additional Intellivision Game Controllers.