Keᷟiͣzᷤoͭuͦ@6ͩ4ͦ0ᷠ0 @keizou@mstdn.guru

日之出海運株式会社の船舶は運行者が鶴見サンマリン株式会社のようだから傭船企業(船舶および船員などを貸し出す船主企業)か

鶴見サンマリンのオーナーはJXTGエネルギー株式会社(東証1部 5001)、有名どころだとENEOSブランドを抱えてる石油系のグループ企業

それらのグループトップはJXTGホールディングス株式会社(東証一部 5020)

というところまで調べてやめとく

特定した

IMO: 9154165
MMSI: 431101172
Call Sign: JG5489
Flag: Japan [JP]
AIS Vessel Type: Tanker
Gross Tonnage: 2591
Deadweight: 3881 t
Length Overall x Breadth Extreme: 89.95m × 15.8m
Year Built: 1996
owner: 日之出海運株式会社
WebSite: http://www.hinodekaiun.jp

タンカーってこれか

https://don.inux39.me/@inux39/100666081406519567

4999トンクラスのタンカーだけれど、どこの連絡橋なのかわからなくて船名が特定できない

船尾が明瞭に見える画像か、GoogleMapで海難座標を教えていただけたら詳細がわかるかも

バージョン管理ツール「Git」は一体どういうものなのか？ - GIGAZINE https://gigazine.net/news/20180904-git-version-control-system/

GIGAZINEでGitの記事が出てるんだけど・・・何故GIGAZINEなんだ違和感がすごい

船の錨泊は風による触れ回りがあるので、荒天時になると安全そうないい感じの錨泊ポイントが早い者勝ちになってしまい、遅れてくると狭くて窮屈なポイントへ錨を下ろすしかなくなり、何かのきっかけで錨鎖が走り出すと風の圧力と慣性力で止まらなくなるのだ

そうなると船はてんやわんやになり、機関に非常に高い負荷が掛かる緊急全速力(全速力の上の普段使わない出力)で慣性移動を何とか弱めて、タグボートが来るまで堪えて、緊急全速力とタグボートの牽引力で何とか再錨泊する

もちろんタグボート側もこんな荒天時にそんな仕事したくないわけで、海上無線などで船もしくは海保からオーダーがあると絶望するけど、港を壊されたり座礁されたりするよりはマシなので助けに向かう

Wi-Fiが二重ルーター状態になっているかを確認するツールは？【自宅Wi-Fiの“わからない”をスッキリ！】 - INTERNET Watch https://internet.watch.impress.co.jp/docs/column/homewifi/1141132.html

思ったとおり「二重ルーター」へメチャクチャつっこみ入れられてる

いしたにさんまでジンバルにいってしまったｗ

Android版ドコモメールの一番クソな部分ってアプリ名が内部的に半角カナな点だよね

開発者頭おかしいんじゃねえかと思う

そこまですんのか中国ブログ

Mastodon pub-relayの補足

これまで色々と情報が錯綜していて理解が難しかったのですが、裏で実験したり正式リリースで正確な情報がわかりました

1. pub-relayが設定されているMastodonインスタンスはローカルタイムライン情報を指定したリレーサーバへ送信する
2. リレーサーバは様々なMastodonインスタンスから送信されたローカルタイムライン情報を結合してMastodonインスタンスへ返す
3. Mastodonインスタンスへ返された結合ローカルタイムライン情報は連合タイムラインに表示される

本来、連合タイムラインはMastodonインスタンス内に居るユーザがリモートフォローしているユーザのトゥート情報を表示するものですが、pub-relayが設定してあると誰もリモートフォローしてなくとも連合タイムラインへ様々なユーザのトゥートが表示されるようになります

ちなみに現在のpub-relayの仕様では、pub-relayを適用したMastodonインスタンスは強制的にリレーサーバ機能を持つようになります。

現在、Mastodon界隈では「大量フォローインポート攻撃」が問題視されています。

これはMastodonのアカウント引っ越し機能であるフォロー情報のインポート/エクスポートを用いて、Mastodonサーバへ過剰な負荷を与えるという攻撃手法です。

アカウント引っ越しための機能が悪用され、それが脆弱性となっている状況です。

Mastodonサーバはフォロー情報のインポートがあるとフォローリクエストに応え、トゥート情報をインポート先のMastodonサーバへ送信するという処理が行われますが、この際に数十万ユーザ単位情報がインポートされるとそれだけ送信のための負荷が掛かります。

更には新たに大規模な連合が組まれる事態となるため連合タイムラインの負荷と合わせて一気に強力な負荷が送信側に発生するという事態になるのです。

つまり、大量のフォロー情報がインポートされるMastodonサーバは攻撃のための踏み台でしかなく、その周辺で連合が接続されているMastodonサーバへ攻撃を仕掛けるという手法です。