  |
はてなキーワード: アーキテクチャとは
スタックオーバーフローのユーザー会に行ってきた。Tシャツ目当てで。
メタな話は、正直あの界隈の人たち好きじゃないので興味なかったのだけど、
同じように一般参加した人がstackoverflowに質問した内容やそれを自己解決した経緯を聞くのは楽しかった。
エンジニアだったら、なんかの問題に躓いて、死ぬほどリファレンス読み込んで解決できなくて
神にもすがる思いで誰か…同僚だったり、SOだったり、GitHubに頼った経験はあると思う。
同僚に事象を説明していたら、環境差分に気づいてスルスルっと解決しちゃった体験。
サンドバッグになってありがとうといつも優しい同僚に言っていたが、最近ラバーダッキングというちゃんとした名前があることを知った。
長ったらしいエラーログから特徴的な文言を抜き出して、ググった先がGithubのissueで。
英語で続くよくわからない会話についた絵文字のGJを頼りにフィックスして結局直ってねーじゃんと失望するような体験。
kubernetesを見るがいい。よくわからないbotが90日後にやってきて勝手にissueをcloseしていくぞ。
そんな中で、技術者として真だなと思うのが技術的に解決方法を自分で見つけた人。隣の人から聞いたのはそんな話だ。
macのドック(下にあるアプリケーションのローンチバー)から消したアプリアイコンが、電源入れるたびにゾンビのように復活するので調べたら
osのバージョンアップ用プロセスがdockの配置を定義している静的ファイルを操作して勝手に元に戻していたことがわかったらしい。
osのバージョンアップ用プロセスがリブートで必ず動くことへの対応は見つけられなかったけど、事象と対症療法は何とか見つかったよとのこと。
正直かっこええなと思う。
システムのアーキテクチャがわかってて深い理解があって初めて可能になるような。
こんな方法はベンダーのマニュアルにも、どの教本にも載ってはいない。しかし、可能ではある。システム全体に対する深い知識と理解と応用力があれば。
EGFﾏﾀﾞｰ?といつも呟いている自分は、EGコンバットでいつEMPバラージにあってもいいように備えている。
そんな中、CVE-2018-1002105 の issue を読んで kube-apiserver に詳しくなろう！
は今、「kubernetes the hard way on azure」をやってて最初のCIDRによるネットワークの分割は、lucidchartでお絵描きまでして頑張ったのに
kubeconfigファイルの作成あたりは無の境地になって、。。。はっと、なんか不安になってきた自分に強くささった。
「kube-apiserver がリバースプロキシとして動作する」こともあるというアーキテクチャの理解をベースに脆弱性情報がこうやって発展するのか...みたいな。
震えるほどかっこええなと思う。
知識の深堀のために、SOが発展していけたら。そんなことを思う。
中国は習近平体制以降、西側の技術を用いて西側用へ最適化された製品やサービスを西側へ輸出することで経済成長してきた。
それと同時に西側で生まれたイノベーション企業や製品・サービスについて、その当初は中国内でビジネスをすることを静観するが、同種の企業や製品・サービスが中国企業として成立すると西側の企業や製品・サービスを規制して中国資本の自国産業を守ってきた。
米国はドナルド・トランプ体制以降にこれらが非常に強く問題視され、中国携帯電話メーカーのZTEに端を発し中国へ規制を強める動きが本格化した。
前述した通り中国は同種の企業や製品・サービスが中国企業として成立すると西側の企業や製品・サービスを規制して中国資本の国内産業を守るため、Googleは中国内で度々規制の憂き目に遭っていた。
Googleが中国政府へ不満をつのらせていたのは明白で、米国法を遵守するとともに報復的な意図があったと推測されている。
ただし、前述したようにGoogleへ先に手を出したのは中国政府なので、一部で語られている「Googleは米国政府の言いなり」という様な意見は少々弱い。Googleには同調する十分な理由があった。
当然ながらファーウェイは中国政府による海外企業規制に助けられていた面もあるので、完全な被害者と判断するかどうかは意見がわかれるところだろう。
スマートフォン向け基本ソフトウェア(OS)のAndroid OSはその大部分が誰しもが無料で利用できるオープンソースなソフトウェアだが、Android OSと名乗るにはGoogleが定めるライセンスに則らなければならない。
そのライセンス取得にはGoogle Mobile Service(GMS)の工場出荷時状態からのインストールが必須だが、このGMSの大部分は非公開であるクローズドソフトウェアであり、GMSはGoogleの承認がなければインストールすることが正式にはできない。
GMSはAndroidアプリ開発において便利な機能がまとまっており、Androidアプリ開発者の開発労力を低減させるため、人気がある高機能で高品質のAndroidアプリではGMSの機能が当たり前のように採用されており、Android OSでないと人気のAndroidアプリが正常に動作しなくなる可能性が高い。
ファーウェイがAndroid OSを使えなくなるとはどういうことか？という疑問の答えの1つが「人気のAndroidアプリが使えなくなる」というものだ。
その他にもGoogleが正式に認証するAndroid OS向けのソフトウェア情報やセキュリティ情報、携帯電話本体のハードウェア開発に関わる情報も提供されなくなるので、ユーザーとしては便利に安全に使い続けることが困難になる。
ファーウェイがスマートフォンを製造できなくなる可能性は非常に低いと見られている。
それは前述したAndroid OSはオープンソースソフトウェアという部分が関わっており、Android OSのオープンソース部分をまとめたAndroid Open Source Project(AOSP)という存在があるためファーウェイがスマートフォンを製造できなくなることはないと思われる。
AOSPは様々なスマートフォン向けOS開発へ応用されており、一部報道でファーウェイが独自OSを開発するという情報が流れているが、ファーウェイはAOSPを利用して独自OSを開発すると思われる。
AOSPベースのスマートフォン向けOSはライセンスの兼ね合いでAndroid OSと名乗れないだけで、AOSPはOSの振る舞いとしては事実上Android OSと大きな差異はない。
ただし、問題となるのはAOSPへは前述したGMSが含まれないので、ファーウェイが開発するAOSPベースの独自OSでは人気のAndroidアプリが正常に動作しない可能性があるので、ファーウェイ製スマートフォンはコストパフォーマンスの高い人気のAndroidアプリが正常に動かないスマートフォンに成り下がるかも知れないのが問題だ。
ARM社はCPUアーキテクチャと呼ばれる、現在のコンピュータやスマートフォンの機械的中核となっているCPUの設計図を考え出している会社だ。
そして現在のスマートフォン向けCPUの大半がARMが考え出したCPUアーキテクチャを採用しており、CPU製造メーカーはARMへライセンス料を支払ってCPUを製造している。
ファーウェイのスマートフォンのCPUであるKirinシリーズCPUは、ファーウェイ傘下のハイシリコン社が製造しているが、このハイシリコンが製造しているKirinシリーズCPUはARMのCPUアーキテクチャを採用している。
つまり、ハイシリコンはファーウェイへKirinシリーズCPUを製造・供給できなくなっており、ファーウェイのスマートフォン製造が窮地に陥っているということだ。
ただし、CPUの調達価格は高くなってしまうがハイシリコン以外の西側の会社からCPUを調達したり、ハイシリコンからKirinシリーズCPUを例えばシンガポールで作った資本関係のない企業あたりへ権利移転して、ファーウェイが輸入するという3店方式のような方法がないわけではないので、直ちにファーウェイのスマートフォン製造が止まることはないだろう。
そもそもSDメモリーカードとは米国へ本部を置く非営利団体SD Association(SDA)が規格を策定しているメモリーカードだ。
SDAは米国へ本部を置いているため法律も米国法の影響下にありSDメモリーカードに関わる技術情報提供やライセンス料の受け取りなどに関して米中貿易摩擦の煽りを受けた形だ。
そして、ファーウェイがSDメモリーカードを使えなくなるのか？という疑問についてだが「SDメモリーカードは使えなくなるがMulti Media Card互換メモリーカードは使える」という回答になる。
この辺りに詳しくない者へ説明は非常に困難を極めるのだが、メモリーカードはこれまで様々な形式や規格が作られてきた。その中にMulti Media Card(MMC)と呼ばれるメモリーカードがある。
このMMCはライセンス料フリーで利用することが可能で、実は形状がSDメモリーカードと全くの同一である。
そして、MMCとSDメモリーカードの歴史的経緯でSDカードはMMCと一部の機能的互換性を持つという側面がある。
そのためライセンス料の支払いが難しいオープンソースかつコミュニティベースで開発されている一部のUNIX OSや一部のLinux OSではMMCに関しての例外的実装としてMMC互換メモリーカードが動作するのだ。
そのためファーウェイはSDメモリーカードが使えなくなってもMMC互換メモリーカードは使い続けることができるという見方が強い。
再度言う、SDメモリーカードは使えないがMMC互換メモリーカードは使えるのだ。
前述したように、中国の経済成長は西側の技術を用いて西側用へ最適化された製品やサービスを西側へ輸出することで経済成長してきたものであり、その経済成長の推進力は西側の知財によるところにある。
今回の中国はその推進力たる知財を人質に取られている状況であり、推進力を奪われれば中国経済が下降線を辿ってしまうのは難しい想像ではない。
そしてまた「中国を刺激するとGoogleに変わってBaidu、Amazonに変わってAlibaba、そういった中国発サービスが世界を取る」というような意見が稀に見られるが、今まで国際競争に晒されていなかったサービスが来年いきなり世界を取ることは有り得ないので、今回の米中貿易摩擦で懸念する問題ではない。
もちろん10年後や20年後はわからない。だがしかし、今現在の中国発サービスがGoogleやAmazonと対抗できるまで成長するには中国は西洋の知財がどうしても今現在必要なのである。
さらに言えば、中国は簡体字教育を推し進め過ぎていて既存のサービスは簡体字にしか対応していないサービスばかりであり直ぐに多言語化したり、現地法規やユーザー特性に合わせたサービスの微調整を直ぐにするというのは全く現実的じゃない。
例えば、簡体字で話す微博(中国のマイクロブログSNS)ユーザーがいきなり多言語に馴染めるとは思えない。というかむしろ中国在住人以外が微博を利用する理由が今のところない。
何故ならば当時の日本は海外企業を特に規制などは殆どしていなかったからだ。
当時はまだ自由貿易協定などが世界でも稀で、どこの国も輸出入へ関税を掛け自国産業を守ろうのすることが通例だったからだ。
そういった意味で当時の日本は海外企業へ対してあからさまな政治的意図のある摘発などをもって規制することは殆どしていなかった。
今回の米中貿易摩擦は価格の安さから起きた貿易摩擦とは違うと言える。
前述した通りそもそもの発端が中国政府による海外企業の冷遇なので中国は米国へ折れるしかないというのは米中双方が間違いなく理解している。
どこの国も自国企業の優遇はしている。しかしあからさまな冷遇をするのは可能な限り控えているのが通例だ(インフラ関連企業などで海外資本比率に規制を設けるなどの冷遇はどこの国もしている)。
つまり、決着は中国内における海外企業への規制緩和しかないのである。
中国側が簡単に負けを認めない理由が自国産業を守るためにどこまで海外企業への規制を緩和するか？というのを決めかねているというただ1点であり、この判断を誤ると中国バブルはすでにもう弾けていると言われている中で自国産業が急速に萎んでしまうから決めにくいのだ。
もちろん、そのようなことが起きれば習近平体制が揺らぐのは明白であり、中国政府としては非常に難しい判断をしなければならない状況だ。
西側で生まれたイノベーション企業や製品・サービスについて、その当初は中国内でビジネスをすることを静観するという習近平体制の今までの状況から考えるに、中国政府が取る選択は時間稼ぎである可能性が高い。
可能な限り時間を稼いで自国産業が可能な限り最小限のダメージで済むような方策を取ろうとしているところだろう。
ただ、米国もバカではないので、その中国の動きを察して段階的に規制強化をし圧力を強め、中国が持つ有限の時間を浪費させようとしている。
あまりにも中国側の時間稼ぎが上手く行き過ぎるとファーウェイは世界のスマートフォントップメーカーから転落する可能性がある。
しかしながらファーウェイが倒産するところまでは行かず、その前に今回の米中貿易摩擦は解決すると踏んでいる。
つまり中国側が白旗を揚げて海外企業への規制を緩和するということだ。
その後ファーウェイが今のように復活するというのは五分五分だと見ているが、ファーウェイが中堅やそれ以下へ成り下がっても、次はハイセンスかシャオミあたりがスマートフォンメーカーとして世界で注目を浴びるのではないか？と予想している。
オッポやヴィーヴォはあまりにも米中貿易摩擦が長期化すると煽りを食らって会社が傾いてしまうのではないか？とは心配になる。
最後に、中国はファーウェイが倒れても第2第3の中国企業がポストファーウェイとして候補に挙げられる程度にはまだまだ余力があるのだと記してこのエントリを終えたいと思う。
都内のWEB系サービス企業でソフトウェアエンジニアをやっている。
先日、給与査定があったのだが、それにどう考えても納得いかないことがあったのでここで書く。
その時提示された給与に関しては、希望額には届かなかったものの前職よりもUPするので、まあいいか、がんばろ、ということで入社。
社員それぞれにグレードが与えられていて、MBOの達成度合いに応じてグレードのアップダウン、給与のアップダウンが発生する。
ざっくりいうと、MBOの評価がSだとグレードアップされ、Aだと給与アップの評価される。
チームメンバーでありつつ、場面に応じてチームリーディングを期待されるくらいの役割。
エンジニアスキルについても、設計から実装まで全て独力でやっていけることを期待されている。
Bランク。グレード相当の働き。
給料は上がらない。入社当時と同じカネで一年間働くことになる。
給与査定に関してそういうシステムであるということは理解している。
だが、上記の働きをして1円も給与がアップしないのは全く納得がいかねぇ。
給与査定の面談では今年度はモバイルアプリのテックリードだけではなく、開発チーム全体のリーダーに据えたいと考えているので頑張ってくれことだったのだが、じゃあ給料上げろよ。
ってか期待されている役割と実際のグレードの期待役割に乖離があんだろ。
一年間、すごく良く頑張ってくれて、採用してよかったとの言葉もあったが、そんな言葉はいらんので給料上げろ。
今年に入って、某有名アプリを開発をしている会社から転職してきた俺よりも10個下くらいの若手がいる(非エンジニア)。
前社での働きがどうだったかとかは俺は知らない。
で、だ。ひょんなことからその人の給与を知ってしまったのだが、俺と同額。
この時点でちょっと納得いっていなかったのだが、まあ、よしとしよう。一年間、バリューを発揮してきたのだから、おれも給料上がるだろ、と思っていた。
のだが、先に述べた通り、給料は据え置き。
これおかしいと思うんだよな。一年間会社に貢献してきた俺と、まだ貢献がゼロでその時点で何のバリューも発揮していない人間で結果的に同等の評価って。
前職の企業のネームバリューがでかいから、そういうものなのかもしれないし、そういうものとして理解することはできる。
だか、やっぱり納得がいかない。
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10
技術責任者だかエンジニアマネージャだかしらんけどおまえクソコードしか書けねーだろ。
つかほぼコード書いてないじゃん。そのくせ基盤部分とかアーキテクチャ設計に入りたがる。
そして飽きたら社員に任せて自分はドロン。基盤の設計がクソだから誰も触りたがらないしメンテコストがヤバいのよ。
自分でコード書けないのは自覚してるらしいけど、そんならそのポジション空けろよ。
おまえがそこにいられる理由はただひとつ。創業メンバーだから。
そのくせ知識だけはいっちょ前にひけらかしてくるからまたウザイ。
おまえネットベンチャーでちょこっとエンジニアやってた経歴しかないじゃん。
勉強会とかセミナーとか起業コンテストとか行きまくってるミーハー野郎じゃん。
技術選定のポリシーも何もなくて流行り物を選ぶだけ。技術力ちゃんと身についてます？
その技術によって採用のやりやすさだったり、外注エンジニアの単価が決まること理解できてる？もっと会社のこと考えろよ。
「この会社でエンジニアとして成長して市場価値を高めよう」とか言っちゃってるのもう笑えない。
何度も言うけどおまえコード書けねーじゃん。なんでそんな上から目線なの？自分のキャリアは自分で決められるから。
いや、別にそういう制度があっても全然いいのよ。会社として用意してるのは素晴らしい。
でもコード書けないやつが考えるキャリアアップなんてクソみたいなもんでしょ。
プログラマとしてクソみたいな実力しか無いのにトップに立ってるつもりなのやめろよ。
テスラの車は、トヨタとメルセデスの古いプラットフォームから派生した純電気自動車だ。まあ、旧型カムリだ。各ECUとインパネ(IC)間がCANバスで結ばれ、ゲートウェイを通して車内インフォテインメント(カーナビ)が接続できる。そして、ゲートウェイにはセンターコンソール(MCU)、自動運転モジュール(APE)が接続されている。まあマツコネみたいなものだ。ただし、通常のカーナビと違い、このMCUはTegra 3(旧世代)または超高速なIntel Atomプロセッサ(現行)が採用されている(マジ)。そして、海賊版のUbuntu GNU/Linuxを実行している(マジ)。そしてLTE回線に直結し、テスラ本社のサーバ(mothership.tesla.com)にOpenVPN接続している。
古いモデルは3G、新しいモデルはLTEモジュールを標準搭載している。明示的に特別注文しない限り無効化や取り外しは行われない。本社Mothershipは各車の動作状況を監視・操作するほか、オートパイロット起動通知を受け取り、またssh接続のためのパスワードを保持する。これによりファームウェアのrootが取られた場合にオーナーを蹴り出したり、あるいは事故発生時に「オートパイロットは(直前でエラーを吐いて運転をぶん投げたため)使用されておりませんでした」と発表するなどいち早くメディア対策を行うことができる。
更新パッケージは前述のOpenVPN経由でダウンロードされ、その中にAPEファームウェアのほかにもドアハンドル、ブレーキ、インバータECUなどのファームウェアが含まれていれば、MCUが更新処理を行う。これまでに配信されたアップデートには、Linux Kernelを含むMCUのOS更新、インバータ出力アップ(設計の三倍程度)、緊急制動距離の延長と短縮、自動緊急ブレーキの追加、自動運転の警告間隔延長・短縮(事故報道の頻度に応じて調整)、自動運転機能そのものの搭載や根本的な入れ替えなどがある。現在の仕様ではファームウェアバージョン表記はYYYY.WW.x.y.zで、GitのコミットIDが末尾に付き、平均して月2回程度のローリングリリースが行われる。つまりリポジトリのheadがざっと社内検証を通るとLTEで降ってくる。非常にまれなケースでは社長(@elonmusk)の「やりましょう」ツイートから数時間でバージョンが上がる。
純電気自動車なので、エンジンは搭載しない。代わりに車体下面にリチウムイオン電池パック(ノミナル電圧480Vまたは400V)を搭載する。パックは火薬式ヒューズを含む高電圧コンタクタ(リレー)を介してモータおよびインバータと接続され、インバータはモータ進角を監視しながらスロットル指示に合わせて三相交流電源を供給する。この辺りはCPUファンと変わりない。
普段AWSならこういうアーキテクチャが良いとか議論しているのを見かけるので、
エンジニアの人から見た、銀行のインターバンクの仕組みとか、ドル本位制の仕組みとか、そのあたりってどう判断してるのか気になった。
インターバンクで複数の銀行間がつながっていて、普段は特に問題ないのだが、1つの銀行が問題を起こすと、インターバンク通じてバタバタ他の銀行も死んでいき、政府の介入が必要な事態になる。
クラウド上のあるサービス間を監視し続けていて、債務不履行が起こってないかチェックしているが、いざ大きなエラーが出ると全部が死ぬ。冗長性担保してないのかよ。
ドル本位制もおかしなもので、アメリカ国内でやばいってなりドルが足りなくなったら、輸出入の取引に使用しているドルが足りなくなり、他の金融での資産があったとしても支払いができなくなるわけで、冗長性が足りない気がする。
Suicaには残高たくさんあるのだけど家に忘れてきてしまって、Edyの残高足りなくて買い物できん、って状況があるのだから、似たようなものかもしれないが。
日本だと国内需要に支えられているにもかかわらず、製品やサービスに問題な無かろうとも、少ない輸出入の割合が全体に影響するわけで。
今スパコンと呼ばれているものがなんであるかは取り敢えず無視していいし、ラズパイ並べたものがスパコンであるように感じたとしても取り敢えず別の何かとした上で
一応レギュレーションは想定するなり増田の方で決めてもよかったんだが、
この問題は「ラズパイの群れとスパコンを比較して、ラズパイの群れにだけある弱点を指摘しましょう」
ってつもりで答えてみて。
条件は以下。
■ラズパイ側
無限の速度のWi-fiで繋がれている。(ありえない仮定とか言うな。この条件でもちゃんと答えを出せるはずだ)
CPU周波数は仮に1GHzとでもしておこうか。メモリ1GB。コア数は1。
これが、世界各地に1000あるとしよう。
■スパコン側
1000コアの各コア1GHz動作のCPU（CPUアーキテクチャはラズパイと同じ）
この条件で、「スパコンで実行すると割とすぐ計算できるけどラズパイで計算すると果てしなく時間かかるだろ」ってプログラム例を挙げてみてくれ。
Green500と経済性は何の関係もないし、なんでそこで経済性を持ち出すのが訳がわからない。
ケーザイセーなるものは今のどの指標でも測ることはできないし、それを問題視するならケーザイセーとやらを評価するランキングを作れ。
アーキテクチャを変更したらソフトウェア更新コストがかかるなんてのは当たり前のことだし、そもそもお前の大好きなx86ですら世代を経るごとにコードを書き換えないと性能が出ない。
いい加減見苦しいぞ乞食。そろそろ黙れ。
そもそもパソコンの世界がx86による統一が図られたあとだから、ほぼすべての端末で艦これが動くのであって、HPCの世界にあっては、なにかを動かすためにはアーキテクチャごとに書き換える必要があるというのは、少し考えれば分かることだろうに…
おっと、いちいち書き換えるなんてコストが高すぎるとかその手の批判は過去数十年繰り返されてきたし、今更そんなものに答えたくないからやめてくれ。
うーん、あんまりその原点くらいに立ち戻るのは嫌なんだけど、Pezy以外がGreen500狙ってなくね？ って指摘はどうなん。ランクにはTop500だかの併記もあるし、他のチームがGreen500にあえてエントリしたとは言いづらいようにも見えるわけだが。
最初の方に言った通り、アーキテクチャ的には汎用なブツを利用してるしな。
それ自体は間違いではないけれど、それ金メッキじゃね？ って指摘はあるじゃろ。
そもそもお前の最初の論点は「Green500は意味なんかないランキングじゃん」だったはずだが、なに論点逸らしてんだテメー
せっかくだから真面目に答えてやろう。
まずHPLなりTop500なりでググれ。
四則演算レベルのベンチマークとか意味不明。そんなんあらゆる計算は四則演算で表せるに決まってんだろ。舐めてんのか
あとな、そもそも今日においてRISCだのCISCだのの分類に意味はない。CISCの代表格のx86が命令をマイクロオペレーションに分解して実行している以上、x86だってRISCだ。
それにな、アーキテクチャが混ざった環境下であっても、その性能を一定の指標のもと、正しく測ることが可能と大多数の人間に考えられているから、HPLは問題があると言われつつも40年間ベンチマークとして成立してんだよ。お前のようなニワカがギャーギャー言ってるようなことはとうの昔に語り尽くされているわけ。
もちろん、HPLに問題がないかといえばそういうわけでもない。様々な批判はある。代替するためにHPCGをはじめとしたベンチマークが提案されている。
んじゃ結構真面目な話するとPezyは周波数低いRISCなんだから消費電力低くて当然じゃね？ とちょっと調べて思ったりした。
んで、そのRISCとCISCとその他混ざったアーキテクチャの中で統一した指標を出すために回してるプログラムってなんだ？ ってことが気になった。
結局MIPSだかFLOPSだかをスコアにしてるんだから、スパコン用のプログラム的なものは回してなくて四則演算レベルのベンチマーク回してるだけなのでは説がある。
もっというと、ワイや増田やぱそこん先生はこのスコア見て何を導きだせばいいんだ？ っていう根源的な問題もある。
