祝「富岳」

1位にこだわらないスパコンとして生まれて1位を獲った「富岳」。日本の技術者たちが開発で目指したものとは
https://pc.watch.impress.co.jp/docs/column/gyokai/1261786.html

新型コロナでいいニュースのないところで、久しぶりにいいニュースですね。

個人的にはCPUがARM系で、ゼロから開発された「A64FX」に興味がわきましたね。

x86のライセンス問題に縛られない、良い選択だったのではないでしょうか。

東京都 オープンソースで新型コロナ対策サイト開設

「東京都　新型コロナウイルス対策サイト」

東京都の新型コロナ対策サイト、GitHubでコード公開　修正提案受け付け
　https://www.itmedia.co.jp/news/articles/2003/05/news073.html

東京都のコロナ対策サイトに学ぶ、オープンデータな情報開示のあるべき姿
　https://news.yahoo.co.jp/byline/tokurikimotohiko/20200312-00167278/

東京都がMITライセンスでソースコードをGitHubで公開してるようですね。良い話です。

今後、ソースコードの管理をどのようにしていくのか、課題点も出るでしょうが。

しかし、こういったことを省庁でできないのが残念です。

まぁ、オープンソースを業務に活用するという発想がまず無いですからね。一部、図書館サーチシステムなどオープンソースが活用されている事例はありますが、基本外注。

自分たちで優秀なエンジニアをスカウトして（現段階では育成は無理）自分たちで「システムを作り」、「システムを管理していく」という土壌が生まれない限りは無理ですね。公的機関の性ではあると思いますが、自分たちで作成したソフトウェアで、何かトラブルが起きたときに責任を取りたくないというのが、発想としてはじめに出てくのではないかと思います。でも、そこはうまく乗り越えられる仕組みを作っていかないと、Society 5.0時代に行き詰まると思うんですがね。費用は高く、しかも使いにくい（笑）システムを導入し続けてるってのはよくある話。でもって、毎年高い管理費を払っている。ベンダー依存のシステムを導入したがために、時を経るにつれ、システム変更が大変になるってもよくある話ですね。でもそれ、あのオープンソースで構築すれば行けるじゃん、てのは思うことがあります。そもそも国自身がSociety 5.0の旗を振っているんですから、自分たちでも努力していかないと。LibreOfficeなんかは、個人でも簡単にできるかなりお手軽なオープンソースの利用ですよね。複雑な数式が入ったエクセルファイルなどは除きますが、ただのcvsファイルや神エクセルファイル程度のものなら、別にエクセルである必要性は全くと言ってよいほど無いです。お役所でのワードファイルなんかは、フォントや文字サイズの指定等が異常に細かく指定され、無駄にきれいなものがあったりしますが、それも別にワードじゃなくても、writerでも書けるわけで。ただ、なかなか利用できないのは、過去の膨大なエクセルファイルやワードファイルの遺産があるがために、LibreOfficeの活用が進まないってのが現状な感じだと思います。

ちなみに、自分の場合は新規に作るファイルは全部LibreOfficeでやっていったので、ある時を境にほぼすべての業務がLibreOfficeに切り替わりました。現在、エクセルやワードを扱う場合は、使用頻度の低いファイルを取り扱う時くらいで、共用作業PCでちょこっと処理するくらいですね。

もし組織でこういった運用をするのであれば、組織全体で計画的に動かないと無理でしょうね。こういうのはトップがババッと方向性を示さないと基本的には無理だとは思いますが。

まぁ国のサイバーサイバーセキュリティの責任者にパソコンが使えない政治家が任命されていたことが以前話題になったりしましたが、ITに疎い人物がこういった役職に就いているくらいですから、こういったことを変えていくのも難しいでしょう。

台湾のIT大臣とは偉い違いです。こういう人事がしっかりなされているから、向こうではいろんな対応が早くなるんでしょうね。

可変圧縮比エンジン VCR実用化

日産が20年の月日をかけ、実用化したらしいとのこと。

ただ、日産は今微妙な状況にあるんですよね。

フランスにいいようにやられなければよいのですが。
　
　

新技術：TCPに代わるQUIC(Quick UDP Internet Connections)

1980年代頃から使われていたTCP。それに代わるプロトコル、QUICの標準化作業が進んでいる模様。
QUICはgoogleがWebアクセスの高速化のために開発したプロトコルで、

・TCPでコネクション確立時に行われる「3ウェイハンドシェーク」を省けるため、コネクション確立にかかる時間を短縮できる。
・「ヘッドオブラインブロッキング」（Head-of-Line Blocking／パケットロスが起こるとその再送が完了するまで、後続のパケットを送れない）を回避できる。

などが利点のようである。

スマホ普及が7割を超える現在において、モバイル環境のようなパケットロスが多い状況ではメリットを享受しやすいようだ。

それ以外にも「素早いコネクションの確立」や「コネクションのマイグレーション」、セキュリティ面の強化等の改善がある模様。

いずれ、各サーバーや各ブラウザがこのプロトコルに対応し、普及する時がやってくるかもしれない。

非常に楽しみだ。

　
　

<外部サイト>
　・TCP＋TLSに代わる高速プロトコル、Google生まれの「QUIC」の特徴と標準化の行方　
　・TCPに代わる高速プロトコルの標準化――QUIC　
　・GoogleのQUICプロトコル：TCPからUDPへWebを移行する　
　

　
　
　
　
　
　
　

圧縮技術「LZHAM」リリース！

高速ロスレス圧縮「LZHAM」、初のメジャーバージョンが登場
　http://news.mynavi.jp/news/2015/01/27/076/

1月25日(米国時間)、LZHAMの初のメジャーバージョンリリースとなる「LZHAM v1.0」が「Rich Geldreich's Tech Blog」において公開された。LZHAMはC/C++で開発されたロスレスデータ圧縮コーデック。データ圧縮率はLZMAとほぼ同等だが、デコード速度がLZMAの1.5倍から8倍ほど高速という特徴がある。Windows x86/x64、Mac OS X、iOS、Linux x86/x64がサポートされている。
・・・
デコードの速度はzlibほど高速ではないものの、LZMAよりはかなり高速とされており、高い圧縮率を実現しつつ高速なデコードが必要になるシーンで活用できる。
・・・

　

なんか面白そう。
いずれ試してみようと思います。

　

〔関連ページ〕
　・マルウェア対策-予備知識：「拡張子」と「２種のファイル実行パターン」