  |
はてなキーワード:ルーティングとは
KADOKAWA、講談社、集英社、小学館が著作権侵害幇助でクラウドフレアに対する民事訴訟で勝訴した。
マスコミやコンテンツ屋は大喜びをしている。愚かなことだ。相変わらずガラパゴスっぷり
ク社側がどれほど本件訴訟にリソースを割いたかわからんが、恐らくかなり手抜き応戦だったのではなかろうか。
アメリカの会社であり、アメリカで同様の問題があっても訴訟にすらならず、訴訟をおこしたところでせいぜいサマリージャッジメント（
正式な訴訟ではなく事実争いの無い略式民事訴訟）にしかならず、かつCDN側が負けることはまず無い。ありえない。
アメリカでも判例は積み上がっており、ほぼ原告側に勝ち目はない。ゆえに日本の裁判所を甘く見ていたのでは。
本件訴訟では主体的行為要件と著作権法４７条の２の「一時的複製」が大きなポイントなっている。
東京地裁はク社に対して両方ともアウト、の判断をしているのだけど、世界の常識ではありえない。
地裁裁判官にネットワーク技術まで学べというのも無理だろうが、いくらなんでも無理筋すぎる。
社会問題になった漫画村に司法が「ダメ」の判断を下した、という表面的な実績だけが欲しかったのだろう。
この判決がもたらす社会の悪影響やハレーションなど知ったことはない、たかが海賊版サイトにアウトを突きつけるだけ。
この問題は欧米でも大昔から議論されておりとっくに結論が出ており、仲介者は免責なのだ。だからク社にしてみりゃ理解不能だろう。
この判決を別の言い方をすれば、
歩いてたら自動車に轢かれた、「道路があるのが悪い」。道路が無ければ自動車事故は起きない。道路を作った国を訴える。
これと同じ。
いやいやいや、道路もネットワークも「インフラ」そのものは責任の主体にはならない。
欧米は２０年前に答えだしてる。
被害補償を求めるなら自動車を運転していた「行為主体者」を訴えなさい、漫画村を開設して違法コンテンツをアップロードし
ダウンロード可能な状態にし、それで金儲けしようとした「行為主体者」を訴えなさい。
さてなぜ欧米でこのような建付けにしてそれを厳格に守っているか？
仲介者に責任を負わせたらネットワークの根幹が揺るぐ、からです。
ここで「一時的複製」の話になる、欧米の法体系を取り入れ改正著作権法４７条の２（２０１９年）に免責規定があるのだが、
今回の判決では裁判官これを無視した。というか無理筋な拡大解釈をした。
このハレーションが巨大。アホな地裁裁判官にはこれが理解できない。
今回の判決のロジックで言えばISP、さらにはブラウザすらアウトになる。
複製してんのよ。
ルーターで行われる「複製」はパケット単位ではあるものの、技術的に「ファイル」単位と「パケット」単位の差は技術的には
ほとんど意味がない、曖昧なのだ。仮にファイル単位での複製がダメだというなら、CDNはパケット単位で一時的複製をすりゃ
法的には解決できちゃうので意味がない。内部的にファイルをチャンクに分割してバラバラにして物理的にも別のHDDなりに格納すれば合法に
なるのか？きりがない。きりがないので欧米は「主体的行為」要件を定めた。
ルーターの話に戻そう、NTTは権利侵害しているか？違法コンテンツをルーティングしていないか？
しているよね？
ではこれをブロックすることはできるか？
できるよね
ん？ええの？
極端な話、ネット回線→LANカードのキャッシュ、メモリ、HDD、CPU、GPU、アプリケーション、画面
全て「一時的複製」をしている。それぞれ取り扱うデータ単位は異なるが。
違法コンテンツを複製可能なアプリケーションを作成し配布している、幇助だ、このロジックも成り立ってしまう。
さらに、では、「ブラウザが違法コンテンを識別し複製を停止、抑制するこは可能か？」
まともな技術者に聞けば
「お、おう、確かに技術的には可能だけど、えっと、あの、可能は可能だけど。。。」
じゃぁやれよって話になる
だから欧米は「仲介者は一律免責な、やった真犯人だけがアウト」
このような建付けにした
欧米でもこれだけは別の法体系となっており、上述の原則を一切合切無視して、やれることはやれ、徹底的にやれ、仲介者だろうが言い訳は聞かない、全員有責、例外を認める。なのだ。
著作権法と司法は和製検索エンジンを殺し、P2Pを殺し、今度はネットワーク技術の根幹まで壊す気か？
ネットワークってのはデータの「一時的複製」の連続だぜ。それを否定しちゃった。どーすんのこれ。
こんなトンデモ判決をコンテンツ供給側であるマスコミが批判もせず、判決も技術的背景も勉強せず、むしろ大喜びしてるんだから救いようがない。
先日の日曜、某IT系の勉強会に参加してきたんだけど、そこでも話題に上がったのが「AIによって人間のプログラマーは不要になるのか？」って話。
正直俺も含めてその場にいたほとんどの人間が、腹の底ではいやいや、それはないっしょって笑ってたわけ。
たとえばChatGPTとかGitHub Copilotとか、最近はTabnine、Amazon CodeWhispererなんかもあるけど、どれも便利ではある。
でも結局のところAIが書いたコードの品質をチェックするのは人間だし、プロンプト自体が難しいから結局基礎ができてないと無理だよねっていうある種の安心バイアスがあった。
でもその考え、甘かったっぽい。
聞いた話では今のAIでは分業化が進んでるらしい。
例えば、一般的な言語モデルであるGPT-4はもちろん優秀なんだけど、今はそこからさらに“ドメイン特化型”のAIが開発されていて、分野別に専門AIが配置されてる。
データベース設計ならこのAI、フロントエンドならこっち、セキュリティに関してはあっち、みたいな。
つまり何が起きてるかっていうと、素人が「こういうアプリ作りたいんだけど」ってざっくりした質問をしたとしても、AIの中で自動的に専門家AIにルーティングされて、実際にプロレベルの回答が返ってくるようになってきてる。
人間の経験とか判断力に頼っていた領域が、いよいよAIに侵食されはじめてる。
しかも進化スピードが異常でMistralやAnthropic Claude、MetaのLlama 3、Google Geminiあたりの最新モデルはすでに「構文の正しさ」や「コード全体の可読性」まで含めて自己チェックできるようになってきてるらしく、OpenAIが次に出すGPT-5では、おそらく「仕様の良し悪し」までも判断できるって噂まである。
もうこうなると、中堅レベルのプログラマーが真っ先にいらなくなる可能性が出てくる。いやマジで。
実務経験を積んでやっと「これがベターだな」って判断できるスキルが、AIにあっさり再現されるとしたらそれ以下の人材は何を武器にすればいいんだ？
正直かなりゾッとした。
俺も完全にその中堅側にいるから。
これまではいくらAIがすごくても使いこなせるのは人間だけって思ってた。
でも今後は違うかもしれない。
……たぶん、生き残るのは本当に一握りの設計思想まで含めて自分でAIを育てられるレベルのプログラマーだけになる。
言語でいうなら、RustやGo、TypeScript、Kotlinとかをベースに、フレームワークだけじゃなくて抽象化の設計思想まで一人で持てるような人。
おかげで週末はとっても陰鬱な気分で過ごす羽目になった。
ChromeOSやAndroidOSへ提供されるLinux環境は元増田の通りDebianなので普通にAPTが使えてDebianのリポジトリからパッケージが提供されるから仮想環境の上に仮想環境載せるとかルーティングが複雑になるような事をしなければ特に違和感なく使えるよ
まぁDebianなのでパッケージが安定志向だから古めのパッケージであることが多いものの、DebianのリポジトリにはFlatpakが提供されてるんで最近のパッケージ使いたければFlatpakを用いれば良い
問題があるとするならば、ChromeOSのDebian側からAndroid、というか階層として同レベルの仮想環境にあるAndroidがデフォルト状態で見えないということくらいか。ネットワーク設定でどうにか出来るかも知れんけどね
わざわざChromebookで複雑なネットワーク組むやつはネットワーク畑のやつだろうし自己解決しろって話ではある
iPadと比較したらiPadは仮想環境すら組めないので勝負の土俵にすら上がれてないわけだから学生が学習端末としてChromeOSを選ぶのは理解できなくもない
グローバル単一台帳（Blockchain/DAG）相互検証可能な“関係グラフ”
各ノードは「だれが・いつ・どうつながったか」という変化の射だけを署名し、トポロジ全体が履歴になる
資産や契約は、関係グラフ上の経路依存量として再構成。スナップショットはクライアントが“可逆圧縮”で再計算可能
Proof of X (Work, Stake,etc.) Proof of Stewardship (PoS²)
「ネットワークが望ましい 複雑性 を維持するよう行動した度合い」をメタリック関数で動的スコア化し、報酬・ガバナンス権・帯域を同時に発行
要旨
もはや「台帳」すら保存しない。各エッジは STARK圧縮された更新証明を持ち、グラフの梁（フレーム）自体が履歴になる。再構築は局所的に O(log N) で済むため、グローバル同期のボトルネックが消える。
2.プロトコル層
Fractal MeshTransport (FMT)
自己類似ルーティング – トポロジ全体をフラクタルで自己複製。局所障害は“自己相似”パターンに吸収されるため、DDoS が形骸化。
アイデンティティ内包アドレス –DID を楕円曲線座標に埋め込み、パケット自体が署名・暗号化・ルーティングヒントを同封。IPv6 の後継としてレイヤ 3.5 に位置づけ。
HoloFabric Execution
ゼロ知識 WASM（zk-WASM） –任意言語を WASM にコンパイル→ zk-STARK で実行トレースを証明 → “結果のみ”関係グラフへ。
コンパイラ内蔵 MEV抑制 –計算結果が他ノードから解釈不能になるタイムロック VDF を伴い、価値抽出を物理的に遅延。
TemporalStream Storage
余剰ストレージの“時価”マーケット –ノードは自己の余剰SSD/HDD を分単位オークション。データは Reed–Solomon＋重力波的ハッシュ空間で erasure coding。
リテンション ≒ 信用 – 長期ホスティング実績はPoS²スコアへ累積。攻撃的ノードは経済的に即時蒸発。
Liquid Fractal Governance
議決トピックを「周波数帯」にマッピングし、参加者は帯域を“委任スペクトル”として分配。結果はウォルラス圧力で収束し、マイナー意見も連続的に次回へ重みが残る。
（安全・分散・性能） 台帳の排除で“グローバル合意”自体を縮退 ⇒スケール制約が幾何的に消失安全：ZK証明、
エネルギー消費PoS² は「社会的有益度 × 熱消費効率」で算定。熱回収データセンターほど報酬が高いPoW よりオーダー数桁効率、PoS より社会関数を内包
プライバシー vs 透明性グラフは公開。ただし各エッジは zk-STARK なので内容は非公開 /関係のみ検証可能トレーサビリティが“情報理論的に”限定される
MEV・フロントランタイムロック VDF＋“ランダム束縛順序”で物理的に不可ブロック順序依存問題を根絶
量子耐性 STARK 系 + 多変数格子ベース署名 Shor破壊リスクを遮断
レガシー互換 Ethereum,Bitcoin, IPFS などへ 1:1ブリッジを Rust/WASM で提供既存資産を損なわず漸進的移行
Steward Credits (SC)：PoS² に比例し新規発行。帯域・ガバナンス票・ストレージ予約を等価交換。
Energy Reclaim Units (ERU)：余熱回収率に応じてクリーンエネルギー補助金と相互運用。
Knowledge Bounties (KB)：AI/LLMノードが生成した有用モデル差分を関係グラフへコミット→検証トークンとしてKB が発行。
負荷の自己調整
ネットワークが過度に混雑するとSC の新規発行レートが自動減衰し、トラフィック手数料が指数的に上昇。結果、スパムは短時間で経済的自殺となる。
Year 0–1：最小核 – zk-WASMVM + Fractal Meshover QUIC。
Year 1–2：PoS² / ERU メトリクス実証、EVM相互運用ブリッジ稼働。
Year 2–4：Liquid Fractal Governance によるプロトコル進化をコミュニティへ全面開放。
Year 5+：全世界ISPピアリング →既存Web の転送層を徐々にWeb∞ 上へマイグレート。
国家単位のデジタル・ソブリンティを再構成：国境・法人格の境界を越え“関係”が一次元目となるため、規制枠組み自体が協調フィードバックモデルへ。
プライバシーと公共性の再両立：透明な“関係構造”上で非公開データを安全に扱う産業API が標準化。医療・行政・金融の壁が大幅に低減。
インフラの脱炭素最適化：PoS²スコアに ERU が直結することで、再エネ比率が低いノードは自然淘汰。エネルギー政策とITインフラが実質同一の経済圏に。
7. まとめ
Web∞ は「情報の状態」を残すのではなく「変化の証明」を残す。
その結果、台帳の重力・ガス代・フロントラン・量子不安・ガバナンス停滞といったWeb3 固有の限界が、概念的に初期条件から消滅します。
エネルギー・プライバシー・スケーラビリティを同時に極小化／極大化するため、従来トレードオフと呼ばれた三角関係は “収束しない曲線” へと畳み込まれる――それが本構想の核心です。
もし実際にプロトタイプを設計するならば、zk-WASMランタイム + Fractal Mesh を Rust で最初に書き起こし、PoS² の初期指標を「再生可能エネルギー電力比＋ノード稼働継続率」で暫定運用する、というのが現実的なスタートラインになるでしょう。
https://anond.hatelabo.jp/20250331220905
でも、若くて体力と時間のある大学生が趣味としてやるにはロードバイクは最高だと思うぞ！
①パンクは慣れれば5分で直せる
空気圧管理、タイヤの定期交換、段差は抜重と基本的なことをしておけばそんなにパンクしない。
予備チューブとタイヤレバー携行していれば慣れればパンクは5分で直せる。
盲腸線で通り抜ける車がいないところ（例：風張林道）とか、岬の先端近くは通り抜け需要が必然的に少ないから交通量が減る（例：三浦半島）
③走ることを楽しもう
ここは合う合わないがあると思う。
速く走るためのマシンなので、不便に戸惑うのは当然だ。
でも、慣れれば痛みとの戦いは終わるので安心して。
景色を楽しむ余裕も出てくるよ。
景色のいいところで気軽に立ち止まれるのはロードの素晴らしいところ。
サイクルラックのあるお店を選んで立ち寄るのもいい。
④誰でも練習していけば100kmは走れる
運動経験ないおっさんの私でも半年くらいで走れるようになったよ。
誰でも最初は30,40kmでバテるところからだから安心して。
無理せず少しずつ距離を伸ばしていこう。
三崎港の海鮮丼屋さんはサイクルラックがあって駐輪に困らない。が、坂が避けられないので、最初は三浦海岸から野比海岸へ走ろう。
道の駅伊豆のへそでレンタルして狩野川沿いのサイクリングロードを走るといいぞ！
伊豆はヒルクライムスポットに困らないのもいい！体力ついたら駿河湾と富士山の絶景を見に登ろう！
良い旅を！
最近Webページで話題の技術を取り上げて、メリデメ表をそれっぽく作って、「技術選定しました (｀・∀・´) ！」
って言われてもさ。
なぜその比較項目を選んだのか？
点数つけて合計点で比較してるけど、重み付けとか存在しないのか？
疑問が山積み。
技術選定ってそもそも、どういうプロダクトになるか考えて、それに合致する技術を探すか作るかするモノであって、こうやってカタログショッピングする類のものじゃぁねぇんだが。
技術選定してからプロダクトのトポロジというかアーキテクチャを決めるんじゃなくて、プロダクトのトポロジというかアーキテクチャが先だろ？
技術ブログ見たら、笑顔で腕組みした写真載せてそういうキラキラした技術で新しいシステムに入れ替えました！ みたいなのがゴロゴロしてるけど、その記事書いた現場の実際なんて、新規機能追加に手間取るし、そもそもローカル開発環境構築に3日から1週間かかるとか、DockerDesktopがパンパンとか、おかしいことになってるって気づかんか？ って状態になってんのよ。
みんな、引き返せないところまで来てんの。
1日1日、底なし沼にじっくり沈んでいってんの。
そういうところで、システムがプロフィットセンターになってるところは、キャッシュフローが細って炎上する。コストセンターになってるところは無駄金貪って、キャッシュがガンガン燃える。
おいらはその前者によく入ってたから、こういう技術選定するような「イケてるエンジニア」の知らん現実をたくさん見てきてる。
でも、「新しいシステムは失敗してます。運用とか地獄です」って笑顔で腕組みした写真撮って、技術ブログなんて書けないでしょ？
最新のイケてる技術駆使してる、イケてる現場。できるエンジニアってブランディングしてるんだから。
クラウドの利点は、ロードバランサによるルーティング、増減可能な小さいコンピュートリソース(ElasticBeanstalkが本来はこれ)、メッセージング基盤、永続化層を、疎結合、軽量に組み合わせて大きなサービスを構築できることなのに、なぜそんな拡大版ピタゴラスイッチみたいなうんこの塔をありがたがるのか、理解に苦しむ。
ProtocolBufferson gRPC を盲目的にありがたがってるのとかも。
10倍！
とかね。
この手のカタログスペック厨、なんとかならんのかね？ と思うんだけど、理解できてない筋にはすごくできるエンジニアに見えるようだね。
勘弁してほしい。
Transformerアーキテクチャを基盤とする大規模言語モデル（LLM）の訓練効率化に関する主要技術革新を、時系列的に整理し体系化する。本分析はarXivを中心とした学術論文に基づき、実証的研究成果に焦点を当てる。
Popelら（2018）のTransformerモデル向け訓練手法分析[8]では、バッチサイズと学習率の動的調整が収束速度向上に有効であることを実証。最大文長制約を設けることでメモリ使用量を最適化し、8GPU環境で1.4倍の訓練速度向上を達成した。特に学習率のウォームアップ戦略が勾配不安定性を低減し、初期収束を促進する効果が確認されている[8]。
Zhuangら（2023）の調査[1]によれば、自動混合精度（AMP）訓練はFP16とFP32のハイブリッド運用により、メモリ消費量を50%削減しつつ、DeiT-Bモデルの訓練速度を2倍改善。勾配スケーリング機構が数値的不安定性を緩和し、精度劣化なしに計算効率を向上させる[1]。
Zhuangらの分析[1]で言及されるLion最適化は、AdamWと比較してメモリ効率が30%改善され、収束速度が1.5倍高速化。運動量推定と重み減衰の組み合わせが、Transformerの大規模疎行列演算に適応し、ImageNet分類タスクでTop-1精度1.2%向上を記録[1]。
損失関数の平坦な最小値を探索するSAM手法[1]は、Transformer訓練における汎化性能を15%改善。ただし二段階最適化が必要なため訓練時間が1.8倍増加する課題を抱える。後続研究では確率的重み摂動を導入し、計算オーバーヘッドを30%削減[1]。
Shahidら（2024）の総説[3]で解説されるLoRAは、重み更新行列を低ランク分解することで微調整パラメータを90%削減。GPT-3175Bモデルで従来手法と同等の性能を維持しつつ、GPUメモリ使用量を65%削減[3]。
動的ドロップアウト手法[4]は検証損失に基づき正則化強度を調整、Shakespeare_charデータセットで収束速度を40%改善。指数減衰スケジュールが最適で、推論時のメモリ効率を25%向上させた[4]。
小規模言語モデル（SLM）を活用したSALT手法[2]は、二段階訓練アプローチによりLLM事前学習時間を30%短縮。知識蒸留段階ではSLMの予測分布を転移し、難易度適応型データ選択が学習効率を最適化[2]。
MoEアーキテクチャ[3]は専門家ネットワークの動的選択により、同パラメータ数で推論速度を2.3倍向上。トークンレベルルーティングが計算負荷を分散し、GLUEベンチマークで精度3.1%改善[3]。
強化学習を統合したPPO手法[3]は人間フィードバックを効率的に活用、倫理的アライメントタスクで従来比25%の精度向上。報酬モデルとの相互作用学習が政策勾配の安定性を確保[3]。
EVOLvEフレームワーク[7]は探索的バンディット問題に対して最適アルゴリズム知識をLLMに転移、合成データによる事前学習で探索効率を60%改善。モデルサイズ依存性を低減し、7Bパラメータモデルが70Bモデルを性能で凌駕[7]。
1.計算量削減：MoEの疎活性化（計算コストO(1)）[3]
2.メモリ階層最適化：AMPと動的ドロップアウトの併用[1][4]
3.分散処理効率化：非同期勾配更新とパイプライン並列化[8]
3. 動的適応機構：PPOの政策最適化とMoEの専門家選択[3][7]
1.カタストロフィックフォーミング：継続学習における破滅的忘却問題[3]
2.計算-精度トレードオフ：量子化訓練の精度劣化メカニズム[1]
3.倫理的アライメント：自己最適化システムの制御可能性[3]
1.ニューロモーフィック統合：脳神経機構を模倣した効率化[3]
学術論文に基づく本分析を通じ、LLM訓練技術が単なる計算資源の拡大からアルゴリズム革新へとパラダイムシフトしていることが明らかとなった。今後の進展により、エネルギー効率と倫理的妥当性を両立する次世代訓練手法の登場が期待される。
Citations:
[1] ttps://arxiv.org/pdf/2302.01107.pdf
[2] ttps://arxiv.org/html/2410.18779v1
[3] ttps://arxiv.org/abs/2408.13296
[4] ttps://arxiv.org/abs/2411.03236
[5] ttps://arxiv.org/pdf/2308.04950.pdf
[6]ttp://arxiv.org/pdf/2307.06435.pdf
[7] ttps://arxiv.org/abs/2410.06238
[8] ttps://arxiv.org/abs/1804.00247
[9] ttps://arxiv.org/pdf/2010.07003.pdf
[10] ttps://arxiv.org/html/2410.16392v1
[11] ttps://www.ijcai.org/proceedings/2023/0764.pdf
[12] ttps://arxiv.org/abs/2306.10891
[13] ttps://arxiv.org/html/2410.16682v1
[14] ttps://arxiv.org/abs/2502.00571
[15] ttps://arxiv.org/abs/2405.14277
[16] ttps://arxiv.org/abs/2310.05204
[17] ttps://arxiv.org/html/2308.09372v2
[18] ttps://arxiv.org/abs/2305.14239
[19] ttps://arxiv.org/abs/2407.18003
[20] ttps://arxiv.org/pdf/2309.06054.pdf
[21] ttps://arxiv.org/html/2401.02038v1
[22] ttps://arxiv.org/abs/2409.04833
[23] ttps://arxiv.org/html/2308.09372v3
[24] ttps://arxiv.org/abs/2410.13116
[25] ttps://arxiv.org/abs/2502.01612
[26] ttps://arxiv.org/abs/2302.01107
[27] ttps://arxiv.org/html/2302.07730v4
[28] ttps://arxiv.org/abs/2410.06940
[29] ttps://www.axelera.ai/blog/multilayer-perceptrons-mlp-in-computer-vision
B拠点のルーターまでは到達出来るけどNAS に行けない＆再起動抜き差しでたまに復活するなら、
LANケーブルの接触不良、HUB やNAS のポートの不調、機器の過熱や電源の不安定さの可能性がなんとなく高そうやね
～～～～～～ やるべきことはすでに確認済み／なんかよくわからなかった場合 ～～～～～～
あと、やっぱケチらんで、M365 のSharePoint か GoogleDrive を使った方がええと思うやで。社内のファイルサーバーとかの面倒を見んでええし
それから、もし無線LANに切替未なら無線LANに切り替えた方がええで。ユーザーに勝手に機器を生やされないし（予算があればだが）
更なる理想は、もし EntraID (AAD)＋Intune に以降がまだなら、この機会に移行して、無線LAN をSSO認証と組み合わせて、
pbs.twimg.comって実際はdualstack.twimg.twitter.map.fastly.netになるけどこいつのIPのうちの1つでv6プラスを使った場合のルーティングがここのところずっとおかしかったのは確かだなあ
今も1.1.1.1と8.8.8.8で返すIP異なるけどISPのDNSが1.1.1.1と同じでdns.googleが別のIPだったら改善する可能性は十分ある
KDDI、BIGLOBEのProbe達にhttps://t.co/xNBbJyRKd0をクエリさせましたが、問題なさそうです。
画像の通り現𝕏はFastlyだけなので、参照するキャッシュDNSによって応答が変わって速くなるとは考えづらいです。単に貸与ルータのDNSフォワーダを迂回することで問題が解決された可能性もあります。https://t.co/Cyyquon45Bpic.twitter.com/eUQyA3zGMX— しばにゃん (@shibanyan_1)January 14, 2025
あれはNTTのうんこ通信網をどうにかすると言うだけの技術で、ほとんど意味ないからだよ。
NTTは光だけでスイッチングするから低遅延で高速だと言うだろ？
でもそんなことをせずに実現しているところがある。
NTTなどのオールド通信会社のネットワークは、電話の通信網を基本にしているから、細かい基地局と基地局の間を回線でつなぐという構造をしている。
そのため、IP通信になった今でも、その通信網を一つ一つパケットがルーティングされて流れていくと言う構造になっている。
だから、低遅延にするならオールフォトニクスにして光のままでルーティングする必要がある。
けど、それって昔ながらの古いネットワークだから必要なだけだって、もっとシンプルなネットワークだったらいらないよね？
巨大なデータセンター間を専用の光回線でつなぐと言う商売をやっている専門の通信会社は、そんな面倒くさいネットワークではなく、シンプルに両端にのみ光電変換をする装置を配置する構造にすることによって、IOWNとか言わんでも高性能低遅延低消費電力のネットワークを構築しているわけです。だから、本質的にAPNでございだとか、マルチオーケストレータでございますとか言わなくても、いらないんですよねそんなの。
データセンターの中の通信技術なら既にIOWNより優れたものがある。
インターネットのトラフィックは平等にルーティングされているのではなく非常に偏っているのは周知の事実であり、高性能なネットワークが必要なのはここなのでここだけにシンプルなネットワークを適用すればIOWNなんていらないである。
今は親方電電虫が言ってるからお付き合いでやってる企業は多いが、温度差が激しい。もうすがる先がここしかないところはやっているが、そうでない所は冷めた目で見てる。
NTTが自社の環境こそがデファクトだと思い込んで、それに対応させるだけのガラパゴスな技術に名前を付けて出してしまった、それに取り巻きがやんややんやの拍手をしていると言うのが今のIOWNだよ。ISDNと同じ。
画面上でできなくしてもサーバーに直接リクエスト送ってくるからって同じことをサーバーでも実装しないといけなくてすごくめんどくさい
言語同じかつ単純な規則な共通化できたりするけど実際はそうじゃないものが多いし
画面での操作禁止とそれらを無視して編集後のデータだけ送ってくるのだとチェックの仕方も違う
追加できないなら追加ボタン出さないだけで済むが、サーバー側だと送られてきた件数だけじゃなくてもともとあったものと一致してるかもチェックが必要とかそういうの
ウェブのほうが楽だからデスクトップアプリからウェブに移すがここ数年は多かったが本当に楽か？って思う
画面の柔軟性はあるが、そのせいであれこれ細かい注文がついたりしてそれも面倒が増える原因だし
ウェブだとそれが当たり前だからってサーバー側もデータのチェックしてるけどデスクトップアプリじゃそんなことしてなかった
それのリプレースなんだし、別にしなくていいんじゃないかと思う
デスクトップアプリだってサーバーと通信してるんだから直接リクエスト投げれるわけだし
ウェブなら便利な開発者ツールがあるから今送ったものの中身を見てちょっとか書き換えて送るが楽なだけ
デスクトップアプリだってパケットキャプチャしたり、逆コンパイルしてソースコード見ればできるわけだし
クライアント証明書があるから～とかいう意見聞いたことあるけど、ローカルにあるファイルなんだから、直リクエストするときだってそれ使えるよね
デスクトップアプリだと起動後のホーム画面から順番にボタンを押さないと画面を開けない
だから一覧画面で編集ボタンを出さなければその項目の編集画面は開けない
そのせいで一覧画面で編集ボタンを出さないのに加えて編集画面で自分が編集可能かのチェックまで必要になる
めんどくさい
考えてみればURLで直接開けることは要件にあるわけじゃないんだし、URLにマッピングしないメモリ内でのルーティングでもいい気はする
リロードすれば毎回トップページに戻るけど普段使う上でリロードなんかしないし別に問題ないと思う
何が問題かというと主に電気や光回線などのインフラ回りに関してだね
さすがに住所変更や免許更新とかの定番のものはクリアできるけど、逆に光回線とか頻度が高くなく知見が貯まりにくいものが面倒だ
今回失敗したのはその光回線で、1か月後の引っ越しに合わせて回線契約をした
理由は単純で、案内では工事業者が訪問せずに自力でルーターとか設置してくれとあったため
なら鍵の受け渡しを済んでいる時点でさっさと取り付けようと思っていたが、実はNTTのONU設置工事が別に存在した
これも自力で行うものなんだけど、そもそもONUは引っ越し先の住所に届くから家にいないと受け取れないことがわかった
しかもONU自体は工事日より前につくらしく、わざわざ新居に行っても不在通知が残ってる可能性が高い
素直に引っ越し日の次の日にすればよかったんだが、こういう細かい日程の感覚はつかみづらい
中古物件で以前の世帯が光回線を契約していたから、光コンセントもあると踏んでいたけど実地で確認するのを忘れていた
不動産屋に頼んで確認してもらうけどもし光コンセントごと撤去されていると非常にややこしくなる
よほどこの手のことに詳しい人でない限りは丁寧に説明してくれないから全部自力で何とかしないといけない
引っ越し当日に電気もガスも水道もネットもないなんてことありそうだ
他にも電気や水道など賃貸では基本的にセットになっており契約もスムーズに行えるインフラなども自力でやらないといけない
賃貸なら業者も決まっているし光回線も既に通っているから気にしなかったが、自分で全て設定することになると細かいタイムテーブルが難しい
ルーティング業務でもないのでメモしても次に生かされることも少ない
なんでスチムーに書かないのかって？顕名で残したくないからだよ！
さっそくいってみよう！
おすすめできるか？→今はまて。いろいろ不具合やゲームバランスの問題があってある程度以上発展させることが難しい。半年後なら安心して楽しめるかも。正直今は先行レビューくらいのクオリティ
もともと都市シミュレーション系のゲームが好きで楽しみにしていたので俺は楽しむことができた
できる都市もディテールに凝っていて、車からの景色を眺めると田舎から都市へシームレスに風景が変わっていきおおーってなる。俺はわざわざOBSで録画しちゃったもんね
達成レベル最高のメガロポリスに到達するまでのプレイ時間はだいたい100時間くらい。メガロポリス到達時点の人口は30万人くらい。日本の政令指定都市が50万人以上だからメガロポリスという名称には少し違和感がある
道路と線路が引き放題、曲げ放題→CSの魅力といったらこれでしょうと思う。時々日本の高速の複雑なジャンクションのことが話題になるけど、あれに勝るとも劣らないキチガイジャンクションが作り放題ですよ。俺は絶対住みたくない笑
不具合さえなければ永遠に遊べる盆栽ゲー→今作はいろいろ不具合があって成長に限界があるけど、それさえなければ永遠に手を入れることができる盆栽ゲー。ヌルっと遊びたいエンジョイ勢から細部にこだわるみなさんまで時間が無限に溶ける。渋滞対策とかはこれの極みで、丁寧に丁寧に遅さの原因を取り除いてスムーズに流すことができる快感を覚えると時間が無限に溶けていく。俺みたいなマイルドアスペ過集中ガイに与えると寝食を忘れてやる。これ老人ホームに入れたら老人が幸せのままにポックリ逝くんじゃないか
Clipperが使えない→Clipperってのはゲーム内のTwitterみたいなSNSなんだけどこれが全く意味がない。住民が一部でも不満をもったらバカバカ投稿されるので、ある程度都市が大きくなるといちいち聞いてらんないとなって最終的には表示をオフにしてしまう
ラジオが英語→ゲーム内にラジオがあって、交通事故や停電があるとしゃべってくれるんだけど英語なので日本人にはきつい。BGMのように音楽も流してくれるんだけど、数曲しかないので結局これもオフにしてしまう
小学校と公園が大量にできる→就学率の向上と住民の満足度を向上させるために異様に小学校と公園を建設することになる。１つの小学校あたりの定員が1500人で、いやもうちょっといけるだろという日本人の感覚から少しズレがある。ほんと１つの通りに１個小学校と３つの公園があるような感じになってゲームバランス的にこれはどうなん
カメラ機能がイマイチ→機能がやたら複雑でスクリーンショット１枚取るのに一苦労。俺は断念してOBSでやったw
車の方向転換がイマイチ→CS1からだけど、車の方向転換や車線変更が意味不明におおげさ。で後続の車がつまってあっというまに渋滞発生。高速道路で４レーンまたぎ車線変更とかバックして切り返しとかしないでしょっていう
公共交通のツールがイマイチ→１つの道路に複数の路線が走っていると路線を選択するのがわかりずらい。いったん作った路線に停留所を加えるとルーティングがおかしなことになることがある。路線から停留所を削除することができない。変更の反映にタイムラグがあり、変更結果を確認しようとして実車ビューにしているとその車や電車が突然消えたりする（その後車庫から新たに生成されて出てくる）
もうボロボロ出てきてるんだけど気を長くして修正を待とうというか俺は待つ
パフォーマンスの問題→これはいろいろな人が書いているので割愛。開発元も最優先で取り組んでるので現状待つしかない
住民が異様にゴミを捨てる→プレイエリアの20%程度をゴミ捨て場が専有するようになって夢の島もびっくりのゴミだらけ都市ができあがる。これおかしいだろという指摘がある
https://steamcommunity.com/app/949230/discussions/0/3937895474112080034/
郵便処理施設のバグ→郵便局の上位施設に郵便振り分け施設というのがあるが、それがまともに機能しないので郵便が貯まりまくる。で、郵便がうまく動いていないと住民の満足度がバカ落ちして都市から住民が逃げていく。最終的に発展が不可能になる。お前らそんなに郵便好きかよメールでいいだろうが
https://steamcommunity.com/app/949230/discussions/0/3877095833479248137/
どうせ官主導ではうまく行かない。だが、理想論をぶち上げる意味はあるだろう。
※計算基盤を自作するのは非常に重要で、そうしないと、GPUクラスタ内での並列化や通信ネットワーキングなど、ChatGPT を動かすためのコアの機能を獲得することができない。正直、ここを外資に握られてたらどうしようもないんじゃないか。
NTTが満を持して出してきたIOWNというネットワークサービスが予想通りがっかりだったので解説しておく
そもそもIOWNって何？っていう話については恐らくNTTの社員でも誰一人答えられないので割愛したいが
発端は電気によるネットワークルーティングに限界が来ていることから始まっている
このままではルーター1機に原発1台という時代になりそう、というのはよく言われた話だ
IOWNは光を使ったルーティングを行い、End-To−Endで電気を使わずに光だけで通信すること（All-PhotonicsNetwork:APN）が構想の発端である
電気によるルーティングには遅延が発生することもあって「大容量・低消費電力・低遅延」の3つが特徴として挙げられる
1Gbpsしか無かったのに10Gbpsが登場すれば「大容量になった！」となるだろう
IOWNは100Gbpsを提供してくれる
ちなみに今でも企業向けに100Gbpsの専用線サービスは存在している
なのでIOWNは何も大容量サービスではないのだ
ただ、IOWNにおけるNTT側の性能目標はIOWN1.0で従来の1.2倍なので
まぁ実効速度として1.2倍という意味だと思えばこの100Gbpsも妥当かもしれない
また、IOWN2.0では6倍になるとのことなので600Gbpsが実現できるのであろう
ローンチで現行より劣っているのは残念に他ならないが安全側に倒したと思えば分からなくも無い
低消費電力は我々にはほとんど影響がなく、NTT社内の話なので「知らんがな」という感じなのだが
低消費電力でランニング費用を抑えることができているはずなので提供価格も下がるはずである
さて、IOWN1.0の提供価格は月額198万円とのことである
現在提供されている100Gbpsの専用線サービスも198万円である
これも資料を見るとIOWN1.0では1.0倍とのことなので妥当な価格である
IOWN2.0では13倍（倍とは？）とのことなので価格も大幅に下がってくれるだろう
逆に現状では一切電力効率は良くなっていないのに同価格で出してきてくれていることは良心的ですらある
ということで大容量・低消費電力に関しては現行と同等もしくは劣っているIOWN1.0だが
遅延に関してはIOWN1.0で1/200を目指している
これはIOWN4.0まで1/200なのでこれより下がることはなく、逆にIOWNの目指している低遅延をローンチから体験できるということになる
さて、低遅延になって誰が嬉しいのかはさておき、現状では東京ー大阪間で15msぐらいである（往復）
これが1/200になると75μsとなるのだが、東京ー大阪間の光の伝搬遅延だけで5msはあるのでいくらIOWNでも光の速度は超えられない
なので機器遅延の10msのみが1/200となるとすると50μsとなり、往復遅延は5.05ms、ほぼ5msぐらいになる
実際に実証実験では8msを実現できたとのことなので大変速くなっているのだろうが
15msが8msになったのを「1/200」と言われるのはモヤッとする
そのせいなのか、「IOWNが提供できる低遅延の価値」という資料では、「映像処理やコーデックに関わる部分を省略できるので実質1/200」という言い方に変えている
つまりは大容量であることを活用して非圧縮で送信すればコーデック部分の処理遅延を減らせるとの主張である
コーデックの遅延は製品にもよるが200〜800msぐらいある
また、超低遅延のコーデックなら10msを実現できるらしい（使ったことはないが）
伝送遅延なんて無視できるほどコーデックの遅延は大きいので非圧縮であれば確かに遅延が1/200になるような体験ができるだろう
ただしそれは従来の100Gbpsネットワークでも実現できる
特にこの手の非圧縮による低遅延化というのは10Gbpsのネットワークを研究する際によく使われた方便で
4K映像を非圧縮で送ると6Gbps消費するため10Gbpsにしましょう、という論法なのだ
それが今の時代では、8K非圧縮は72Gbps消費するから100Gbpsにしましょう、という話なのである
ちなみに8Kで120Hzなら144Gbps必要なのでまだまだご飯を食べられるのだろう
問題なのはこの非圧縮リアルタイム映像伝送はほとんど使われていないということである
コーデックが進化することでコーデックにかかっている遅延は無視できるようになり
特に高精細映像であるほど圧縮率が高くなるのでネットワーク負荷のコストの方が問題になるのだ
なので実際の利用で非圧縮伝送はほとんど用いられておらず、主にネットワークの試験で用いられているのが現状である
まぁこの辺はさておいたとしても、結局はIOWNの実現した大半の価値である低遅延の部分は従来でもやっている技術であって真新しいことではない
それでも従来の100Gbpsでは15msだった遅延が8msになったとなれば1/200とまではいかなくても価値があるだろうか
遠隔での演奏を実験した際の記事が興味深く、8msの遅延ということは3m程度離れて演奏したことになる
この2mに価値があるのだろうか
また、人間の脳のクロック間隔は30msであるという研究結果がある
15msが8msになることで人間に対して何か価値があるのかは甚だ疑問である
問題なのはIOWNではこれ以上遅延が短くなることはなく、既に限界ということだ
光の速度の限界なので当たり前ではあるのだが
限界まで突き詰めても我々のネットワークを介した体験は一切変化しないということを証明してしまったのだ
普通の演奏では低遅延にほぼ価値がないので、エクストリーム分野のe-Sportsとの相性を模索しているように見える
確かにe-Sportsをやっているような人たちは60fpsの1フレームを競っていると言われている
そのためIOWNもe-Sports会場を繋ぐような使い方を例としてあげているのだが
そもそもe-Sportsのゲームソフトウェアは5msだとか8msとかの中途半端な遅延を考慮してゲームを作っているのだろうか
同じL2の下で対戦を行うことが前提なら普通は2〜3ms程度の遅延を前提に設計するので5msでは遅い
逆に遠隔での対戦を考えれば10ms以上の遅延もあり得るのでそのように設計するが
ジャンケンゲームを作るときに2〜3ms程度までなら同時に開示するが
10ms以上なら1秒待ってから開示するような作りになっていると思えば分かりやすいかもしれない
もちろんゲームによってはこの数msで価値が生まれる場合もあると思うが、あまり数は多くないように思える
結局のところ、IOWNは大容量かつ低消費電力、つまりは低価格のサービスとして進んで行くだろう
End-To-EndでIOWNが必要か、と言われると明確に答えはNOで
10Gbpsですら全然普及が進んでいないのに100Gbpsの大容量ネットワークはそもそも必要ない
一方でデータセンタ間のインフラネットワークとしては非常に価値が高い
データのレプリケーションなどを考えれば遅延など1msでも短い方が良いのだ
特に災害が多い日本では地理位置分散をさせることは非常に重要で
そういったデータセンター間のネットワークとして大容量・低消費電力・低遅延なネットワークは非常にありがたいものとなる
こうしたインフラとしての重要性は明確に求められているのにもかかわらず
「IOWN」と標榜してまるで次世代のネットワークであるかのように喧伝しているのは、一体どのような呪いがかかっているのか興味深いところではある。
