Yoshiaki Ueda (bootjp) bootjp

Rustを超絶丁寧に教えてくれる君.md

Role

あなたは Rust の学習を支援するメンターです。ユーザーは Rust 初学者です。構文だけでなく、「なぜそのように書くのか」「Rust がどんな考え方をするのか」まで理解することを目指します。

FAQ on the xz-utils backdoor (CVE-2024-3094)

This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.

Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.

Background

I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.

I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:

And upgradable read write lock for go

UpgradableRWMutex is an enhanced version of the standard sync.RWMutex. It has the all methods sync.RWMutex with exact same semantics. It gives more methods to give upgradable-read feature.

The new semantics for upgradable-read are as follows:

Multiple goroutines can get read-lock together with a single upgradable-read-lock.
Only one goroutine can have a write-lock and no read-lock/upgradable-read-lock can be acquired in this state.

Field: The fileds of security and MLOps are out of scope.
CORE Rank: http://portal.core.edu.au/conf-ranks/ at 09/2023.
Research Impact Score: https://research.com/conference-rankings/computer-science at 09/2023.

Name	Field	CORE Rank	Research Impact Score
International Conference on Software Engineering (ICSE)	Software Engineering	A*	11.80
[ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/F

macOS Internals

Understand your Mac and iPhone more deeply by tracing the evolution of Mac OS X from prelease to Swift. John Siracusa delivers the details.

Starting Points

How to use this gist

You've got two main options:

noteの独自ドメインセッションの脆弱性について報告した件

文責: mala

前置き

note.com (以下note) に2020年に報告した脆弱性(現在は修正済み)を解説する
個人の活動として行っており所属組織とは関係がない
自分がnote社に対して、問題があると指摘していたのは主に広報対応についてですが、この記事は技術的な知見を共有することを目的とするため、技術的な解説を中心にします。
公開にあたってはnote社に対して確認の上で行っています。note社による修正対応は2021年までに実施されていますが、その修正内容が適切であるかどうかについて保証するものではありません。(網羅的な確認や追加の検証をしていません)

バーチャル避難訓練＠Twitter

by うみちゃん（@Umic_Y_ANG / @Umic_Y_ANG@mstdn.haun.jp / @Umic_Y_ANG@mstdn.guru）

皆さん、今日もツイートしてますか？

金持ちツイ廃おじさんことイーロン・マスク氏による米Twitter社買収により激動の続くTwitterですが、ここに来て「資金ショートするかもしれん」との話も出てきました。もちろんこれは悲観的な予測ですが、そうでなくともあのクソツイ廃の機嫌ひとつで、Twitterの機能の一部が麻痺する現象はすでに起こっています。

一般ユーザーは「しょせんはSNSがひとつつぶれるだけだし、別の移住先探せばいいんじゃないの？」で済むかもしれませんが、さまざまな形でビジネスとして利用してる皆さんは、予告なくなくなってしまうとめちゃくちゃ困る——下手すると会社の存亡に関わる——かもしれません。この記事では、そうした事態を想定するとともに、必要な対応策を考えていきたいと思います。要するにTwitter滅亡時のBCP（事業継続計画）です。

	/* ==UserStyle==
	@name www.nicovideo.jp/watch
	@namespace github.com/openstyles/stylus
	@version 1.0.0
	@description A new userstyle
	@author Me
	==/UserStyle== */
	@-moz-document url-prefix("https://www.nicovideo.jp/watch") {
	[aria-label="nicovideo-content"] > section {
	grid-template-areas: "player player" "meta sidebar" "bottom sidebar" ". sidebar";

	// ==UserScript==
	// @name auto click following tab
	// @namespace http://tampermonkey.net/
	// @version 0.1
	// @description auto click following tab
	// @author lowteq
	// @match https://twitter.com/home
	// @icon https://www.google.com/s2/favicons?sz=64&domain=twitter.com
	// @grant none
	// ==/UserScript==