「KB」を含む日記

■anond:20240524181214

四六時中スマホで動画を見てる時代に、画像一枚数kbの容量の差がなんだって？

今時の人達のスマホ動向を知らないのはお前の方だろ

Permalink | 記事への反応(1) | 18:13

ツイートシェア

■Cat.6A規格対応ケーブルまとめ anond:20240422112615

オーム電機

サンワサプライ

表記がカテゴリー6e対応と古い
　

バッファロー

Cat.6A規格対応と表記があるものはなし。伝送帯域はCat.6A対応や、10G対応などの表現はある。
　

I-O DATA

Cat.6A関連のケーブルは取り扱いなし
　

 注意事項

伝送帯域がCat.6A対応というのは、500MHz帯でのLAN通信に対応していて、10Gリンクできる可能性が高いという事かなと思います。
それだけでCat.6Aの規格を満たすわけではないと考えます。
　

 参考資料

JEITA Cat.6A 最新規格動向と関連情報
この3ページ目に載っている﹁ツイストペア情報配線システム標準化Gメンバー企業の製品であれば安心して使用できるが、残念ながら業務メーカーで一般向け商品はほぼ販売していないと思われます。
その他のページの内容も、高度で難解ですが、役立ちます。
https://home.jeita.or.jp/upload_file/20170526155527_9x5o4Lc1Eh.pdf
　

LANケーブルの品質について︵ブックマークコメントへの返信︶

既定の速度でリンクして、その周波数帯で通信できるのは最低限として、その上でノイズ耐性など様々な条件を満たさないと安定した通信ができません。
規格を満たしていない場合LANケーブルを束ねるとエラーになったり、ノイズが多い環境で通信が不安定になったりします。
　

 公開後の更新履歴

修正したいのにずっと反映されなくて困っていましたが、ハイパーリンクを追加するとエラーになるんですね。教えていただいてありがとうございます。
4/24 23:45 LD-GPAT/BKを削除、サンワサプライの製品を追加。ハイパーリンクを追加するとエラーになる事を教えていただいた。
4/25 0:15 修正完了
4/25　品質について追加。
Permalink | 記事への反応(3) | 19:11 
ツイートシェア

■anond:20240313081729

vim-tinyとnanoってどっちが容量少ないのかなと思って調べたけど

なのか

nanoにもnano-tinyがあるけどこれはインストール後サイズ 239.00 KBとかだな

使ったこと無いからどんなもんかわからんが・・・

参考: Debian 12 (Bookworm) - Debian Main arm64

Permalink | 記事への反応(0) | 08:58

ツイートシェア

■貧困論とか研究・調査してたのコレで？

この人の挙げてる文章じゃ底辺や低学歴が「特に」ゲームを好むかなんて殆ど言えてない上に

それを示していると思われる唯一のソース『非行原因に関する総合調査』も

高校生の非行少年と一般少年でゲームよくやってる人の割合が34.3％、33.4％と殆ど違わない表が出てくる…あかんわ…

第４回 非行原因に関する総合的研究調査【PDF形式】

テレビゲーム、携帯用ゲームの頻度（PDF：337 KB)

https://web.archive.org/web/20220424003543/https://www8.cao.go.jp/youth/kenkyu/hikou4/pdf/2-1-3-7.pdf

更に貧困層の子どもが人生が貧しくなる原因はゲームばかりやってるからってのに至っては

胡散臭い伝聞しか呈示出来てない…なんなんだこの人…？

Permalink | 記事への反応(3) | 10:43

ツイートシェア

■anond:20230603195553

車にひかれて死んだネコの地縛霊。 必殺技はパンチを素早く繰り出す﹁ひゃくれつ肉球﹂。ちょっとめんどくさがり屋さんで、気まぐれな性格だが頼りになる一面も！？アイドルユニット﹁ニャーKB﹂をこよなく愛している。口癖は、﹁オレっち、○○ニャン！﹂
Permalink | 記事への反応(0) | 19:57 
ツイートシェア

■

https://b.hatena.ne.jp/entry/4736080561518980709/comment/TakamoriTarou

今時、文書の保存に関しては、ストレージなんぞタダみたいなもんなのに

https://www.security-next.com/145617

3月24日21時から同月31日23時59分にかけてシステムに登録された10万3389件のファイル

Amazon S3

https://aws.amazon.com/jp/s3/pricing/?nc=sn&loc=4

アジアパシフィック（東京）

0.025 USD/GB/月

一週間で、10万ちょいくらいのファイル

添付ファイルと言ってる感じはExcelかWord、もしくは画像か

ひとつのファイルで 100kB くらいと想定

これを書いてる時点で米ドルは 134.84円

支払い総額を一般化すると ΣY(k) = [JPY/W]*k*(k+1)/2

五年後には支払い総額は 281,940円

五年後の容量は 2564 GB

ただ置いてあるだけで、月に8642円が出ていく

一般企業だったら気にしないであろう金額ではある

まあ件のシステムでホワイトリスト形式でファイルを消しているのは容量を節約しているのではなくてセキュリティ的な側面だろうとは想像するが

効果のほどははっきりしないとしてもね

Permalink | 記事への反応(0) | 12:37

ツイートシェア

■海外の囲碁リーグに参加中の日本棋院チーム、1勝もできずに終わるか

日本チームと台湾チームが韓国KBリーグに今年から海外チームとして参加中

野球のように2リーグに分かれそれぞれ6チーム在籍

日本 14戦0勝14敗 リーグ最下位

台湾 14戦3勝11敗 リーグ最下位

本日、両リーグ最下位の日本チーム対台湾チームの戦い

日本は最終戦

1勝できずに終わるかどうかがかかっている

参加メンバー

関航太郎天元（21） 日本16位 2勝7敗 N高出身

平田智也八段（28）日本18位 2勝5敗 声優の照井春佳の嫁

大西竜平 七段（22）日本15位 0勝4敗

小池芳弘 七段（25）日本21位 0勝6敗

広瀬優一 七段（21）日本22位 3勝7敗 N高出身

張瑞傑 六段（23）日本58位 0勝3敗

酒井佑規 四段（19）日本36位 2勝7敗

福岡航太朗 四段（17）日本38位 5勝4敗

https://kb-league.syuusaigo.com/result/

本日の先発

・酒井佑規 四段（19）日本36位 2勝7敗

・小池芳弘 七段（25）日本21位 0勝6敗

・福岡航太朗 四段（17）日本38位 5勝4敗

・広瀬優一 七段（21）日本22位 3勝7敗 N高出身

チーム内からそれぞれ4人が対戦ごとに選出されて戦う

2勝2敗なら延長戦5人目で決着。5人目は再登板あり

https://twitter.com/mhlpanda_limino/status/1652614599521505281

配信

韓国公式放送（評価値あり）

https://www.youtube.com/live/4XVnyrcZ8CE?feature=share

日本チーム応援放送（評価値なし）

https://www.youtube.com/live/cbySIJu0crs?feature=share

Permalink | 記事への反応(0) | 20:48

ツイートシェア

■https://anond.hatelabo.jp/20230426234414

何度か試してみたところ数百KBに留まったこともあるのですが、多くの場合私の環境ではアクセスしただけで100MB以上保存されます。
変なブラウザ拡張機能も入れて無い(EvernoteとGmailくらい)ので、原因に察しがつかないのです…。
仕方ないので、ウィンドウを閉じるときに常に Cookie を削除の対象に[*.]tbs.co.jpをぶち込みました。
Permalink | 記事への反応(0) | 00:10 
ツイートシェア

■TBSのニュースサイトヤバない？(追記)

はてぶの上位にちょいちょい載ってるTBS系のニュースサイト、newsdig.tbs.co.jpについて。
https://b.hatena.ne.jp/site/newsdig.tbs.co.jp/

何がヤバいかって、くっそ巨大なCookie(LocalStorageとかも含むのか知らんけど)をしこたま保存してんのよ。
気付いた時点では640MBも占有してた。別に巡回チェックしてるわけでもなく、話題に挙がってたら見てみることもある程度のアクセス頻度なのだが。
Chromeユーザーはアドレスバーに↓コピペして確認してみてくれ。
chrome://settings/content/all?searchSubpage=tbs.co.jp&search=cookie

試しにCookie消去してから、ただ開いただけでサイト上で何の遷移もしてないのに279MBも保存された。

次点ではpresident.jpが553MB消費してた。(こっちも話題に挙がってたら見てみることもある程度。)
(その次にはGoogleが数百MBオーダーで消費してたけど、これはGoogleドライブのオフラインキャッシュとか考えれば妥当。他に数百MBオーダーで消費してるサイトは無かった。)

多くのサイトは数バイト～KBオーダーなのに、こいつら何保存してんのか不気味すぎる。

(追記)
各自の環境の消費量を教えてくれた方々や有意義なコメントを下さった方々ありがとうございます。
始めにお断りしておくべきだったかもしれませんが、自分はソフトウェア系ではありますが、Webエンジニアではありません。認識が浅かったり、古かったり、そもそも間違ってる可能性もあります。
CookieじゃなくてCacheStorageやんけと突っ込みもいただいていますが、﹁LocalStorageとかも含むのか知らんけど﹂と書いておいた意図は(どのような技術要素かはどうでもよくて)ユーザー端末に保存されるデータボリュームについての話を意図しています。ChromeのCookie絡みの設定画面での表示なのでこのような書き方をしましたが、解り難かったのならごめんなさいね。冗長ながらも認識齟齬を招かないように平易な表現で書くと、﹁ユーザの明示的な承諾なくユーザー端末に保存されるデータがデカイんだが﹂って話です。

で、各自の環境で﹁ユーザの明示的な承諾なくユーザー端末に保存されるデータ﹂が数GBオーダーにも及ぶという事例が少なからず報告されて、自分の環境だけではない事象だということが判りました。
さらにtbsとpresident以外にもいくつかのサイトが同様に肥大化していることも知れました。

結果的にはid:hinaloeさんの解説が解りやすかったです。ありがとうございます。
https://blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/
CacheStorageがChromeの表示と、実際のディスク消費量と一致していないことが原因であると理解しました。
追試してみたところ私の環境ではChromeの開発者ツールでの表示が74MBで実際のWindowsのファイルシステム上は33.9MB消費されました。
実際のストレージの消費は表示値の半分程度ということになり、id:hinaloeさんの1.4GBに対して5MBのように実際の約0.3%という結果とは大きく乖離がありますので、各環境で大きく違いそうな気がします。
気になる方は↓を各自ご確認いただくとよいかと思います。
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage
※配下のどのディレクトリが対象サイトのものなのか一意に特定する情報が無さそうなので、Chrome開発者ツールのApplicationタブの左上の方にあるService Workersを選択すると、右側にReceived YYYY/M/D HH:MM:SSみたいな表記が有るので当該時刻に変更されたタイムスタンプを持つディレクトリを特定するような感じになるかと思います。

ついでに開発者ツールを触っていて気付いたベースで書いておくと、
●ApplicationタブでCacheStorageの各アイテムのResponseヘッダのexpiresを見ると概ね1か月後が指定されている
● 開いてもいない記事の画像がCacheStorageに格納されている(スクロールすると下の方に載ってる)
●Networkタブで確認すると、ページのロードが一見完了したように見えても延々と動画の断片や画像らしきデータが転送され続けている(動画の断片のexpiresは即時指定のためCacheStorageには入らない模様)
といった感じで、ユーザが見たものをキャッシュしているのではなくて、先読みしてるような挙動に思えます。
ロード時間短縮でUX改善を狙ったものかもしれませんが、個人的にはそれを1か月も保持し続けるのは過剰な感じがしますが世の中的にはどうなんでしょうね？
あと、スマホの場合の挙動どうなってんすかね？

(追記2)
hinaloe氏の投稿で紹介されているStackOverflowの投稿やそのリンク先のChromiumのバグレポートのやり取りまで目を通してみると、特に理由の説明なく平均7MBがパディングされると書かれた投稿があります。
https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses
https://bugs.chromium.org/p/chromium/issues/detail?id=796060

該当するソースコードは↓のようです。
https://source.chromium.org/chromium/chromium/src/+/main:content/browser/cache_storage/cache_storage_cache.cc
この中で、ComputeRandomResponsePadding()という関数を呼び出しておりその実体は↓のようです。
https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:storage/common/quota/padding_key.cc;drc=332f92aab4a32607f7813ac1a824f6ff0d86c369;l=47

この関数は符号無し64bit整数の乱数(つまり、0～18446744073709551615のいずれか)を14431 * 1024 = 14777344で割った剰余(つまり、0～14777343≒約14MiB)を返却します。
これがパディング値として採用されることになりますが、乱数が正規分布している前提で、平均すると(最大値14MiBの半分で)約7MBになるよねってことだと思われます。

故にChromeの設定画面から確認できるCookie等(LocalStorageとかCacheStorageとか諸々含む)のサイズは、概算してCacheStorageに存在するファイル数×平均7MBが過大計上されていることになりそうです。
これでChromeの設定画面から確認できるサイズと、実際のファイルシステム上で消費されているサイズの違いは合理的に説明できますが、TBS等の特定のサイトだけデカくみえる理由の説明にはならないのです。
つまり、以下のような可能性がありそうです。
(一)Chromeの設定画面から確認できるサイズほど巨大ではないが(他のサイトと比較して)相対的にデカイ？
(二) ComputeRandomResponsePadding()の結果が顕著にデカくなる乱数が生成される個別要因がある？
(三) それ以外
なんなんすかね？
Permalink | 記事への反応(27) | 22:10 
ツイートシェア

■anond:20230407202623

個人で開発してるならこのくらい気分が乗ったら実装するよね

でも実際は、BTチップ・外観・その他実装のために必要なもの全部お金かかるんだよね

思考実験というならKB対応させるためにどうしたらいいか考えなよ～

つまらないレスしてないでさぁ

Permalink | 記事への反応(1) | 21:19

ツイートシェア

■囲碁・観る碁ガイド。これさえ見とけば囲碁界を楽しめる！