ryuse

通信業界で開発の仕事をしています。 【RAN, SRv6, P4, 5GC, UPF, etc. 】

[ryuse @13ryuse4]

折角なので記念？に、本日最終出社日でした！お世話になった方々、大変お世話になりました！(語彙力)

[Kentaro Ebisawa @ebiken]

社内にまだできる人がいない新分野をアサインしてもらう（勝手に始めてデファクト担当になる）ことで、勉強時間＝＝仕事時間にして多重することでなんとか時間作っている。

[横浜539 @PutStickerOn]

面白かった。

> マルチキャストは仕組みとして放送に近いため、「IPで放送のようなものを出すのはいかがなものか」といった指摘もあったのです。
そんなコメントあったんか…。

radikoの配信基盤を設計した技術者、香取啓志氏が語る「放送×インターネット」の次https://t.co/NHfyfvfnmx

[Kunihiro Ishiguro @kishiguro]

https://t.co/I5SglsoV6e XDP/eBPF統合版リリース。EVPN(E-LAN, E-LINE両方)をVXLAN, MPLS, SRv6全てのEncapsulationでサポートするのはLinuxでは初めてのはず。XDP/eBPFエンジンはL2/L3/MPLS/SRv6/VXLAN/GTP/BFDに対応。

[nelio @nelishiba]

ざっと読んだ。
僕の研究活動や思想を知っている方はわかるかと思いますが、近い活動を内々でやってきているので自分が先にオープンにできなかったことは、正直に申しあげれば大変悔しいです。同時に大変勇気をもらえました。こういう活動は意義がある。やらねば。 https://t.co/p0pH2bGsLG

[taihei @taihei299792458]

恐ろしく丁寧な5Gネットワーク入門的なサイトを見つけてしまった...
一瞬知り合い作かと思ったが多分そんなことないな
特にここなどのわかりみが深い
https://t.co/yUK7D51QSb

[ryuse @13ryuse4]

久しぶりにポストしたら過去5年分くらいのポストが消えた。。。？一時的な何かだろうか。

[ryuse @13ryuse4]

まあ、全ての可能性を考慮して事前に検証/設計しておけと言われればそれまでだが。実際上は全てを網羅するのは難しいし、なぜ網羅出来なかったかを掘り下げても不毛じゃないかなというのはなんとなく思う。

[ryuse @13ryuse4]

既視感ありすぎて筆が止まらなかった。

[ryuse @13ryuse4]

運用「事実多数のユーザーに通信影響が出ていたわけです。どのようにお考えでしょうか。」

僕「うるせぇ予見出来るなら最初から検証して対策しとるわ(ご迷惑お掛けして大変申し訳ございません)」

[ryuse @13ryuse4]

運用「こういった障害が起きてユーザー影響が出るたびに想定外という言葉が言われると思うんですね。予見出来なかったというのはそれでいいんですかね？」

僕「基本的に予見が出来れば対策を打ちたいという思いです。本音としては。我々としてもこんな障害を起こしたくもない」

[あーぁ @sxzBST]

熊本イオンモール記者会見、記者の質問が酷すぎる

記者「こういった災害が起きて人命が失われるたびに想定外という言葉が言われると思うんですね 、予見出来なかったっていうのはそれでいいんですかね？」

吉田社長「基本的に予見ができれば対策を打ちたい思いです。本音として。 我々としてはこんな事故を起こしたくもない」

記者「事実3名の方が現状として亡くなられているわけです。どうお考えでしょうか？」

吉田社長「冒頭で慚愧の念に耐えないと申し上げましたけど本当に心より深くお詫び申し上げたいと思っております。我々の施設で人命を失うということの重さを痛切に感じております」

できる限りの対応をしていると答えているのに意地悪な質問を繰り返すマスコミ。震度7の大地震。さすがにこれでイオンを責めるのはおかしい。

[横浜539 @PutStickerOn]

はてなブログに投稿しました
vJunosでEVPN-MPLS L3VPNをしてみた。 ～その2～ - 横浜539のブログ

EVPN Route-Type 5を使って、EVPNで収容されているPCから擬似Internet(異なるNW)と通信する設定を検証しました！！
https://t.co/9rrrTKGpj8
#はてなブログ

[横浜539 @PutStickerOn]

続き書いております。
乞うご期待…！！！

[Kunihiro Ishiguro @kishiguro]

@takemioIO 一通りCNI, Cilium, L2, L3, MPLS, SRv6のeBPF実装を書いてみました。https://t.co/rhhcYLHuuW ドモノリシックです。次のzebra-rsリリースから使えるようになります。

[qooqle @qooqle]

シレッとSRv6 MUP実装されてて草www
最高かよ！！

https://t.co/VLtXPk7hbX

[Kunihiro Ishiguro @kishiguro]

Rust版zebraをリリースしました https://t.co/wwjlYfKWnx

[iwashi / Yoshimasa Iwase @iwashi86]

第一原理からソフトウェアを学ぼうという記事。論理回路から始まり、パケット通信まで解説されている。

https://t.co/xg74aPJGBz

[Kenn Ejima @kenn]

スタックの誤謬、いい記事だったので全文訳します！

——

なぜ大企業は失敗し続けるのか：スタックの誤謬

Stack Fallacy（スタックの誤謬）は、非常に多くの企業が新しい市場を獲得しようと試みては派手に失敗する原因となってきた。データベース企業がアプリは簡単だと考えたり、VM企業がビッグデータは簡単だと考えたりするのを目にしたとき——彼らはスタックの誤謬に陥っているのだ。

スタックの誤謬とは、自分の層の一つ上の層を作るのは些細なことだという誤った思い込みである。

数学者はしばしば、自然界全体を数学的な言葉で記述できると信じている。ゆえに、物理学はすべて応用数学にすぎない。そしてそれが延々と続いていく。

スタックの誤謬——「ただのアプリでしょ」

ビジネスの世界にも、同様の幻想が存在する。データベース企業は、SaaSアプリは「ただのデータベースアプリ」だと信じている——これが、この新市場で簡単に作って、競争して、勝てるという誤った自信を彼らに与える。歴史が示してきたように、AmazonはクラウドのIaaS市場を支配し続けている。一方で、その素材となる下層の技術を作る技術ベンダーたちは競争に苦戦している。VMwareはAWSに勝つには程遠い。AWSのすべてが、VMwareの中核的な強みである仮想マシン技術の上で動いているにもかかわらず、だ。OracleはCRM SaaSでSalesforceに勝てずにいる。OracleはSalesforceを単なるホスト型のデータベースアプリだと見なしているにもかかわらず、である。それどころか、Salesforceは彼らのデータベース上で動いているのだ！

Appleはスタックを垂直に下へと統合することには成功し続けている——チップやプログラミング言語などを作っている——が、ここでもまたスタックを上へ登って、ああいった単純なアプリ、たとえば写真共有アプリや地図のようなものを作るのは非常に難しいとわかった。

歴史はこうした例で満ちている。IBMは、自社のPCというハードウェア層を動かすソフトウェア層を大したものではないと考え、MicrosoftにあっさりとOS市場を握らせてしまった。

90年代、ラリー・エリソンはSAPがプロセス自動化ソフトウェア（ERP）を売って途方もない額の金を稼ぐのを目にした——彼にとって、ERPは一連のテーブルとワークフローにすぎなかった——そこで彼は何億ドルも費やしてその市場を獲りにいったが、結果はまちまちだった。最終的にOracleはPeoplesoftとSiebelを買収することで、アプリ市場に金で参入した。

なぜ我々は繰り返しスタックの誤謬に引っかかるのか？

スタックの誤謬は人間の本性の産物だ——我々は自分が知っているものを（過剰に）高く評価する。具体的に言えば、あなたが大手データベース企業で働いていると想像してほしい——そしてCEOがこう尋ねる——うちはIntelやSAPと競争できるか、と。リレーショナルデータベースのソフトウェアを作れるからといってコンピュータチップを作れると想像する人はほとんどいないだろう。だが、一つ上の層の構成要素に馴染みがあるために、ERPアプリなら作れると信じてしまいやすい。なにしろ、テーブルとワークフローなら知っているのだから。

成功のボトルネックは、しばしばツールに関する知識ではなく、顧客のニーズに対する理解の欠如である。

データベースエンジニアは、サプライチェーンソフトウェアの顧客が何を望み、何を必要としているかをほとんど何も知らない。そのために人を雇うことはできるが、それは中核的な強みではない。

意外なことに、スタックを上へ向かって革新するよりも、下へ向かって革新するほうがはるかに簡単なのだ。

その理由は、自分自身が下層の自然な顧客だからである。Appleは、理想的な未来のマイクロプロセッサに自分が何を求めているかを知っていた。それを作るのに必要なスキルは持っていなかったが、顧客としてのニーズはよく理解されていた。技術的なスキルは買ったり獲得したりできるが、市場ニーズの深い理解をただ買ってくることは非常に難しい。

したがって、Appleが半導体チップを作るほうが、Apple Mapsを作るよりも楽だったのは何の驚きでもない。

Google、Facebook、WhatsApp

Googleはここでの絶好の例だ。Googleは我々のメールのグラフを握り、我々の興味関心のデータ（検索）を握っていた。それでもなお、「作るのは些細なこと」に見えるアプリ——ソーシャルネットワーク——で成功するのは非常に難しいとわかった。

実際のところ、これこそがスタックの誤謬の完璧な皮肉である。スタックの上のほうにあるものは作れる。ただ、何を作るべきかが明確でないことが多いのだ。

プロダクトマネジメントとは、何を作るべきかを知る技術である。

スタックの誤謬は、企業がなぜ明白なこと——あまりに手の届くところにあって、確実に作れそうなこと——で失敗し続けるのかについての洞察を与えてくれる。その答えはこうかもしれない。「何を」は「どうやって」よりも100倍重要なのだ、と。

https://t.co/xX49YyXY46

[Kentaro Ebisawa @ebiken]

AMD Pensando で Ultra Ethernet pipeline on P4 解説してたスライドどこにあったっけ。。。と思ったら昔の自分がまとめてた。w https://t.co/H6fxkIEPk4

[Maki_Daisuke @Maki_Daisuke]

これは典型的な「スタックの誤謬」。
技術レイヤーのスタックがあるとき、下位レイヤーのほうが重要で優れていて価値が高いと信じ込むやつ。
過去20年を振り返ると実際には、上位レイヤーを押さえたプレイヤーがその後下位レイヤーを垂直統合するのが勝ちパターンだった。
https://t.co/0RyjR0Cwgw

[ryuse @13ryuse4]

dUPF！