タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
ゲームの「10年プレイしない」実績解除のために時間をすっ飛ばした結果「2038年問題」にぶつかってSteamのフォント表示が大混乱
PCゲームのダウンロード販売・ストリーミングプレイのプラットフォームであるSteamで、表示されるテキストが突然ランダムなフォントになるという報告が話題になりました。その報告をしたユーザーによると、フォントがランダムに変化した原因には「2038年問題」が影響していたとのことで、その経緯と結果に注目が集まっています。 The stupidest shit just happened to me: @Steam started picking a random font I had in my user fonts dir: FG Virgil, the @excalidraw font. I have no idea why, but this is wild... pic.twitter.com/IDRqRwFs1s— bµg (@insouris) Investigating why S
2038年問題はUNIX時間のオーバーフローに伴ってプログラムが誤動作するというものですが、既にほとんどのプログラムで解決済みとされています。しかし、ゲーム開発エンジニアのエイドリアンさんがMicrosoftのドキュメント上に2038年問題を引き起こすコードが掲載されているのを発見。そのコードをコピーしたプログラムでは2038年問題が発生してしまうと警告を行っています。 Year 2038 problem is still alive and well | Silent’s Blog https://cookieplmonster.github.io/2022/02/17/year-2038-problem/ UNIX系のOSでは時刻情報を扱う際に1970年1月1日0時0分からの経過秒数として表される「UNIX時間」を利用しています。かつて、UNIX時間はシステム内部において符号付き32ビ
headless曰く、 Linuxカーネル5.6（Linuxカーネル5.4/5.5にバックポートされる可能性も高い）の32ビット版で2038年問題（Y2038）への対応が初めて行われたという（Arnd Bergmann氏のメーリングリスト投稿、Phoronix、The Register）。 Y2038はUNIX時間が2038年1月19日3時14分7秒（UTC）以降、符号付き32ビット整数で表現できる範囲を超えてしまうという問題だ。OpenBSDは2014年にY2038対応しているが、Linuxの場合64ビットシステムでは64ビット整数が標準のため影響は少ないものの、カーネルとユーザー空間が分かれていることから32ビットシステムでの対応は簡単に進められる問題ではなかったという。なお、2038年に32ビットPCが使われていない可能性は高いが、32ビットの埋め込みシステムが多数残っている可能性も
Ubuntu Weekly Topics Ubuntuにおける2038年問題との戦い・暗号化設定の調整、SmartNICとUbuntu Ubuntuにおける2038年問題との戦い・暗号化設定の調整 Foundation Teamの開発レポートを見ると、いくつか興味深い作業を読み取ることができます。まず注目するべきはarmhf time_tという見出しのついた作業を、複数のエンジニアが進めている点です。これは内容からして「2038年問題への対応（32bit Arm）」であろうことがわかります。この文脈で2038年問題について知っておくべきこととしては次の通りです。 伝統的なUnix環境では、システム時刻はepoch time（1970年1月1日午前0時0分0秒）からの経過秒数で保持している。この系において、整数オーバーフローによる巻き戻りが発生すると、「時刻が突然1970年に巻き戻
Debianプロジェクトのプロジェクトリーダー Steve Langasekは2月2日、Debian開発者向けメーリングリストに「64-bit time_t transition in progress」というタイトルで投稿し、2038年問題（Y2038）に対応するための作業の進捗について報告を行った。Debianは現在、2025年以降のリリースが予定されている「Debian 13 "Trixie"」の32ビットアーキテクチャが2038年以降も動作できるように取り組んでおり、とくに32ビットarmアーキテクチャへの対応にフォーカスすることを明らかにしている。 64-bit time_t transition in progress -lists.debian.org C言語で時間を表現するための型として使われている「time_t」は、世界標準時で1970年1月1日午前0時0分0秒からの経過
「2038年問題」への対応進むLinux
Steven J. Vaughan-Nichols （Special to ZDNET.com） 翻訳校正： 村上雅章 野崎裕子 2020-02-21 06:30 2038年1月19日（火）の協定世界時（UTC）午前3時14分8秒に世界は終焉（しゅうえん）を迎える。と言ってもこれは「ヨハネの黙示録」に記されているような意味合いのものではない。この時点から、Linuxや旧版の「macOS」といった、32ビット版のUNIXベースのOSが使用している時刻の保存領域が桁あふれを起こす結果、負の数値を刻み始めるのだ。これは良いことではない。こういったOSが稼働している32ビットコンピューターは誤動作するだろう。だが幸いなことに、Linuxの開発者らは既に準備を整えている。 この問題は、UNIXにおける時刻の計数方法に端を発している。UNIXとその親戚筋にあたるOS、つまりLinuxやmacOS、その
Linuxカーネル5.10ではXFSファイルシステムの2038年問題(Y2038)への対応が行われるようだ(Phoronixの記事、 The Registerの記事、 Darrick J. Wong氏のメーリングリスト投稿)。 Y2038は2038年1月19日3時14分7秒(UTC)以降、UNIX時間が符号付き32ビット整数で表現できる範囲を超えてしまうという問題だ。Linuxの場合、64ビットシステムでは64ビット整数が標準のためY2038の影響は小さく、32ビットシステムでもLinuxカーネル5.6でY2038に対応しているが、タイムスタンプに符号付き32ビット整数を使用するファイルシステムのY2038は32ビットシステム・64ビットシステムの両方が影響を受ける。 Linuxカーネル5.10のXFSファイルシステムではinodeのタイムスタンプとクオータ有効期限のタイプスタンプのデータ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2038年問題を再発させるコードが多数の場所にコピーされてしまっている
Linuxカーネル5.6、32ビット版で2038年問題への対応が行われる | スラド Linux
Ubuntuにおける2038年問題との戦い・暗号化設定の調整、SmartNICとUbuntu | gihyo.jp
Debian、32ビットの「2038年問題」に対応へ | gihyo.jp
Linuxカーネル5.10、XFSファイルシステムの2038年問題に対処 | スラド Linux
tech.dentsusoken.com
qiita.com/shamokit
karapaia.com
comic-days.com
senior.noteta.net
news.denfaminicogamer.jp