未来の子どもたちに伝えたいコンピュータ5


(20190206追加)追加ばかりですみません。飛ばして後で読んでください。

『「コレクティブ・コード・ベース」と「ビック・オープン」のすすめ。
一億総プログラマー時代へ。ソフトウエアもDIYの時代。
まだ物々交換の時代。人々は自分のできる些細な労力で貢献した。その些細な労力が集結して回り回って大きなものが戻って来た。小さなボランティア精神の循環がより大きなものに育つ。現在のソフトウエアの世界は特にこのパターンに当てはまるのではないでしょうか。
「オープン・アーキテクチャ」、「オープン・デザイン」、「オープン・ソーズ」、「オープン・エデュケーション」と、一つ追加されましたが「ビック・オープン」です。これも勝手に作った造語ですが、「ビック・オープン」は貧困層の大きな力となるでしょう。これらが意味することは、安心と安全と、小さな力の集結と循環です。インプリメント(実装方法)は自由なのです。
私の拙い活動「未来の子どもたちが知るべきコンピュータ」は、この中の「オープン・エデュケーション」の一貫のために始めました。畑違いの作業でまだ完成度も低く読み難いもので全然収斂されたものではありませんが、しかし、少しは自分の意見が言えたのではないか。また、少しは知識の役に立ったのではないかと期待しています。
こういった、それぞれの人間が、自分のできる時間に、自分のできる範囲のことを少しずつでも、ボランティア精神に則って行動することで、物々交換の時代のように小さな力が巡り巡って、大多数の望むものに成長していくのではないかと思っています。
例えば、ソフトウエアの世界でも、古いソフトウエアは現在では誰でも作れる時代に成りつつあると思います。開発APIも多くの変遷があり、既に下位互換性は新しいものができる度に壊され続けています。はっきりといって昔のソフトウエアはまともには動かないことが多いのではないでしょうか。こういったものは、「オープンデザイ」などで、もっと誰でもDIYで作り易くするべきだと思います。「これくディブ・コード・ベース」はそういった発想から出てきました。
「私はこの古いソフトのデータ構造とアルゴリズムは少し分かるので解説する」、「私はその解説の足らない部分を知っているので補足する」、「私はその解説をもっと分かり易く作り直す」、「私はその解説を元にプログラムのサンプルを作ってみる」、「私はそのソース・コードを修正してみた」と連綿と続くボランティアの輪ができると思います。この流れで、あの古いが使いや易かったソフトウエアが復活すれば、これほど助かることはありません。貧困層は助け合いで生活水準を賄ってきたとも言えます。現代は貧困格差、1%対99%などとも揶揄されますが、ソフトウエアのDIYも、「みんなで作る、みんなのための、みんなのソフトウエア」になるのではないでしょうか。
「私は様々な場所にあった意見を纏める」、「私しは文字ベースだった解説を図解にする」、「私は図解を更に勧めてアニメーション解説にする」、「私はアニメーション解説を動画にする」などと発展していくものと信じています。「私は、この解説のリストが解り易い」、「私は私なりの考えで、この解説の流れで聞くと分かりやすいと説明する」、「私はこの分野(ゲームやデータベースなど)に関するデータ構造とアルゴリズムを纏め関連を説明する」などと更に広がっていき、それを見た人たちが解り易いものを選んでいく。などとソフトウエアの輪が広がっていくことこそが、ソフトウエアの力を広げて、さらなる発展と利用と利便性向上に繋がるのではないかと思っています。
そして、以前にも語りましたが、「コレクティブ・コード・ベース」の「オープン・ソース」は、ただ「ソース・コード」を公開するだけを言いません。これだとただ投げやりなもので、発展には繋がりにくいものと思います。基本的に努力義務として「ヒント」を多く付属させることが望まれます。「プログラムの概要図解」だったり、「データ構造とアルゴリズムの概要や説明」だったり、「オブジェクト指向に基づいたブロック図での説明」だったり、「インターフェースとメッセージ説明の追加」だったり、「ソース・コードの場所と説明のまとめ」だったりします。「コレクティブ・コード・ベース」的な考えでは、投げやりな公開ではなく、発展的な方向への指針であり、可能な限り理解してもらう姿勢です。また、「ソース・コード」だけでも、上記のような、「解説する人たち」の流れを作りやすくすることが必要です。
もはや、古いソフトウエアは万人の資産であると言っても良いでしょう。これからの人たちは、もはや「コンピュータ」なくしては生活ができないと言っても過言ではない状況です。身の回りのソフトウエアによる利便性くらいは、「小さなボランティア精神とDIY指向」でいきましょうということです。
#コンピュータ #ソフトウエア #ボランティア #オープン・ソース






(20190204)その前に追加です。飛ばして貰っても良いです。

『今回の不具合騒動でも明らかに「ミスリード」がありました。
この問題はセキュリティとは関係なく、ハードウエアを修正すれば元に戻る問題です。
CPUの脆弱性「Spectre(スペクター)」と「Meltdown(メルトダウン)」とかいう問題です。
「セキュリティのためのパッチを当てるとPCのスピードが大幅に遅くなる」
とそれだけを豪語しているサイトを多く見かけました。「恰もセキュリティは遅い」と誘導しているようにです。
今回の件での「パッチ」は「通常のセキュリティ」とは何の関係もありません。
ハードウエアの不具合を修正できなかったので「無理からにセキュリティ」をソフトウエアで当てているだけです。
なぜ彼らは事さらに「セキュリティ=遅い」と強調ばかりやっているのでしょうか。
私のように「セグメント機構」があるだけで「バッファオーバランはできない」といった具体的な説明はしないのです。ただ「バッファオーバランはこれだけ怖く驚異だ」としか言いません。
ブロクを参照してください。
これだけの「セキュリティ機構」が現在のCPUでは動いているのに、なぜその説明は一切しないのでしょうか。
「トロイの木馬」もできる対策をしていません。
ウイルスが数億万種類もあると言いながら、その根幹に関わる情報は一切でてきません。唯一でてきた、「バッファオーバラン」も「トロイの木馬」も具体的な仕組みが分かったので対策など考えて答えを出しました。なんと、既に出来ない状態のようでしたが。
なぜ彼らは、「本当の簡単な対策」もしないで「ウイルスは封鎖できない」と言って見たり。私がブログで説明したような具体的な説明もしないで、「セキュリティをすると遅くなる」といった風潮ばかり一生懸命作るのでしょうか。
甚だ疑問です。
はっきりといいますが、「ハードウエアでのセキュリティ」や「OSの根幹部分での対策」はそれほど遅くなりません。今と同じくらいです。
遅いと言われるのであれば、少なくともASICなどで、ロボットコンテストのようなコンテストを開催するべきでしょう。なぜ肝心な「セキュリティ」に関するコンテストはしないのでしょうか。
x86系CPUのセキュリティコンテストを開催するべきです。「分岐予測」や「キャッシュ操作」や「パイプライン・スーパースケーラ構造」などでセキュリティとは関係ない性能差が出るので、「セキュリティON」と「セキュリティOFF」の速度差で競争すると良いと思います。もちろん、総合での競争もあってよいかと思います。486程度のものでの競争で大丈夫かと思います。私も「集スト」などの嫌がらせがなくて、「ASIC」マスター級の知識があれば参加したいところですが。
それから、「ゲームが遅くなる」とかは、よほどのゲーマーくらいでしょう。私はもうスペックバリバリの重たいゲームもしないですので、「ゲームよりセキュリティ」を選びますが、なぜ選択の権利まで奪うのでしょうか。これは「危険なIOT機器」と同じことです。私は明らかに一般家庭より何十倍も多い不具合で開発などを邪魔されつづけてきました。アイデアも多く盗まれました。間違いなくセキュリティの進化を望みます。
また、現在では一人でPCを何代も所有できる時代です。なぜ「ゲーム用」と「一般用」を分けて使用してはいけないのでしょうか。もしゲームをしたとしても、ゲーム用は分けると思います。
この件も20年も放置されたものがこのタイミングで見つかる。ちょっと疑問点もありますが、まあ何にしても、そこは強くは突っ込みません。だたセキュリティのことを真剣に考えてもらいたいだけです。
#ウイルス #セキュリティ #マッチポンプ #偽装社会 #独裁国家






「未来の子供たちに伝えたいコンピュータ」の第6章です。
すみません、まだフライング段階です。妨害が酷いのでフライングです。



(20190121)攻撃されたのでフライング。ここは読み飛ばしてください。

『第二部で行う予定の「ネット通信」問題。
問題はUDPとTCPプロトコルだが、これはポートとタスクが明確に対応している。
空いたポートはそのタスクを担当するアプリケーションの規格の問題となる。ただし、通常メーラーやブラウザはリング3モードのプログラムなので万が一暴走しても第一部で説明したようにシステムや他のプログラムは保護される。基本的にクライアント・サーバーモデルやオブジェクト指向で説明したように規格化された機能しか実行できない。
ホームページとは「url」からまず「index.html」を読み込む。このindex.htmlはページの構成情報が書いてある。ここからそこに書いてあるcssやjpg画像を読み込んで画面を表示していく。javascriptはこれらの名前の付いた素材要素を動的にその表示位置を変更するなどのダイナミックな操作が書いてあるだけ。
規格はRFCで余すところなくすべてのプロトコルが説明されています。
きちんと設計したものではウイルスの要素などはないものである。まずこの導線に関係のないサーバから関係のないリクエストが来る段階で弾くことができる問題である。
メールシステムも同じである。なのでメールから感染するなどは信じられない。どのように行うのかをきちんと説明してもらいたい。
#ウイルス #マッチポンプ #偽装社会』


001_R.JPG

002_R.JPG

003_R.JPG

004_R.JPG

005_R.JPG

006_R.JPG

007_R.JPG

008_R.JPG

009_R.JPG

010_R.JPG

011_R.JPG

012_R.JPG

013_R.JPG

014_R.JPG

015_R.JPG

016_R.JPG

017_R.JPG

018_R.JPG

019_R.JPG

020_R.JPG

021_R.JPG

022_R.JPG

023_R.JPG

024_R.JPG

025_R.JPG

026_R.JPG

027_R.JPG

028_R.JPG

029_R.JPG

030_R.JPG

031_R.JPG

032_R.JPG

033_R.JPG

034_R.JPG

035_R.JPG

036_R.JPG

037_R.JPG

038_R.JPG

039_R.JPG

040_R.JPG

041_R.JPG

042_R.JPG

043_R.JPG

044_R.JPG

045_R.JPG






この記事へのコメント