タグ

2022年7月3日のブックマーク (4件)

  • KDDIの通信障害についてまとめてみた - piyolog

    2022年7月2日、設備障害によりKDDIの携帯電話サービスで障害が発生しました。ここでは通信障害に関連する情報をまとめます。 通信障害発生から復旧発表まで3日以上 au携帯電話サービスがご利用しづらい状況について 障害発生同日8時以降から1時間おきに障害報告が公表されていた。 障害発生・復旧の状況は以下の通り。 対象地域 障害発生日時 復旧作業終了時間 復旧完了日時 西日 2022年7月2日 1時35分頃 2022年7月3日 11時頃 2022年7月5日15時36分 東日 2022年7月2日 1時35分頃 2022年7月3日 17時30分頃 2022年7月5日15時36分 影響を受けたのは全国の個人・法人向けのau携帯電話、UQ mobile携帯電話、povo、au回線利用事業者の音声通信、ホームプラス電話、ホーム電話、auフェムトセル、SMS送受信。7月3日11時時点の概算では約3

    KDDIの通信障害についてまとめてみた - piyolog
  • auなどの通信障害【まとめ】“全面的な復旧判断は5日夕方に” | NHK

    携帯大手のKDDIは、2日未明に発生したauの携帯電話などの大規模な通信障害について、発生から62時間以上がたった4日午後4時時点で全国でほぼ回復したと発表しました。 KDDIは4日午後8時から技術担当の専務がオンラインで記者会見を開き、全面的な復旧の判断は5日の夕方になるという見通しを示しました。 吉村専務 障害長引いた原因「何らかの原因で負荷減らず」 KDDIの技術担当の吉村和幸専務は、音声通話やデータ通信がほぼ回復したと発表するまでに62時間以上かかるなど、通信障害が長引いた原因について「当初はきのう行った復旧作業の結果、システムへの負荷が減ると見込んでいたが、何らかの原因で実際には負荷が減らず、調査を行っていた」と述べました。 そのうえで、吉村専務は、4日の午前中になってシステムの負荷の原因が明らかになったため、昼すぎに必要な措置をとったところ、負荷が下がり、音声通話やデータ通信が

    auなどの通信障害【まとめ】“全面的な復旧判断は5日夕方に” | NHK
  • 本の原稿のバージョン管理を始めて20年たちました - golden-luckyの日記

    の編集ではテキスト原稿のバージョン管理しか勝たん」という信念を押し通してきて、そろそろ20年近くになりました。厳密には19年くらいだと思うので、タイトルは誇張です。 久しぶりに編集者にとってのバージョン管理に言及したくなったので書いてみました。 目次です。 なんで「テキスト原稿のバージョン管理」の話をしなくなったか 「誌面レイアウトしたPDFとか紙に赤字を入れる」で編集するのもう無理… そこでテキスト原稿のバージョン管理 具体的にどうすればいいのさ 前提からつらつら書いていたらやたらに長くなりそうだったので、全部捨てて書き直したのに、それでもそれなりに長くなってしまった。 最後の節に書いた「 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する 」というヒントだけでも持ち帰ってもらえればうれしいです。 なんで「テキスト原稿のバージョン管理」の話をしなくなっ

    本の原稿のバージョン管理を始めて20年たちました - golden-luckyの日記
  • 「GitHubの利用を中止しよう」 SFCが提言、AI開発ツールに疑念

    GitHub.comの利用をやめようと言われても、多くのソフトウェア開発者やGitHub.comのユーザーにとって、それはかなり困難で突拍子もない提案のように聞こえる。この便利なサービスなしには日々の生活が成り立たなくなっているユーザーは世界中にたくさんいる。 Software Freedom Conservancyは6月30日(米国時間)、「Give Up GitHub: The Time Has Come! - Conservancy Blog - Software Freedom Conservancy」において、同組織におけるGitHubの使用を中止するとともに、他のFOSSプロジェクトGitHubからほかのサービスに移行するのを支援する長期計画を実施すると伝えた。 Software Freedom Conservancyは現在のGitHubの取り組みに疑問を呈しており、AI支援

    「GitHubの利用を中止しよう」 SFCが提言、AI開発ツールに疑念