Go界隈で巻き起こった go:linkname 騒動について - ANDPAD Tech Blog
お久しぶりです、ANDPADボードの tomtwinkle です。 この記事はGoの go:linkname 騒動は 6/18に行われた Go Bash で話した内容を要約したものです。 そもそも go:linkname とは何かといえば internal packageやprivate var/funcなど普通はアクセスできないオブジェクトシンボルをエイリアス出来るようCompilerに指示して、アクセス可能にするcompiler directiveです。 go:linkname はprivateな変数へアクセス可能な便利なものでしたが unsafe packageのimportを必須とする通り、せっかく互換性や安全を考慮して作られているGoプログラムを簡単に破壊できる諸刃の剣でした。 詳細は発表スライドを見てください。 go:linkname 禁止騒動 Go 1.23 のリリースまで2
雰囲気でDocker Composeを触っている状態から脱するために調べたこと（2023） - Activ8 Tech Blog
エンジニアの岡村です。 自分はサーバーがメインではなく、あまり業務でガッツリ触るわけでもないのですが、最近それなりに活用するようになってきました。しかし、ネット上の日本語情報を読んでいるだけではこれの書き方が正しいのかよく分からない、と悩むことが結構あったため、色々情報を漁ってみました。 この記事は、特に自分が気になった部分の調べた結果を記事に纏めてみたものです。対象読者はdocker-composeを雰囲気でupやdownは叩けるけどComposeファイルの書き方がよく分からんとなってる人です。 Docker Composeの概要とcompose.yaml、Compose Specの関係 compose.yamlの書き方は Compose Specに準拠すればOK Compose Specの場所 推奨のファイル名はcompose.yaml compose.yaml内にバージョンを記述する
BatBadBut: You can't securely execute commands on Windows
BatBadBut: You can't securely execute commands on Windows Posted on April 9, 2024 • 10 minutes • 2109 words Table of contents Introduction TL;DR CVSS Score Technical Details Root Cause Wrapping CreateProcess Parsing rule of cmd.exe Mitigation Escaping double quotes? As a Developer As a User As a Maintainer of the runtime Conclusion Appendix Appendix A: Flowchart to determine if your applications a
Get up to speed with partial clone and shallow clone
EngineeringGet up to speed with partial clone and shallow cloneAs your Git repositories grow, it becomes harder and harder for new developers to clone and start working on them. Git is designed as a distributed version control system. This means that… As your Git repositories grow, it becomes harder and harder for new developers to clone and start working on them. Git is designed as a distributed
XZ Utilsの脆弱性 CVE-2024-3094 についてまとめてみた - piyolog
2024年3月29日、Linux向け圧縮ユーティリティとして広く利用されているXZ Utilsに深刻な脆弱性 CVE-2024-3094 が確認されたとして、研究者やベンダがセキュリティ情報を公開しました。この脆弱性は特定の条件下においてバックドアとして悪用される恐れがあるものとみられており、当該ソフトウエアのメンテナのアカウントにより実装されたソフトウエアサプライチェーン攻撃の可能性が指摘されています。ここでは関連する情報をまとめます。 脆弱性の概要 xzとは主要なLinuxディストリビューションに含まれる汎用的なデータ圧縮形式で、今回問題が確認されたのはその圧縮・解凍ユーティリティであるliblzma(API)を含むXZ Utils。CVE-2024-3094が採番されており、Red Hatによって評価されたCVSS基本値はフルスコアの10。影響を受けたライブラリをリンクしているssh
かっこいいSSH鍵が欲しい - アリ
例えばこのSSH公開鍵、末尾に私の名前(akiym)が入っています。 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFC90x6FIu8iKzJzvGOYOn2WIrCPTbUYOE+eGi/akiym そんなかっこいいssh鍵が欲しいと思いませんか？ ed25519のSSH公開鍵の構造 SSH鍵の形式にはRSAやDSA、ed25519などがありますが、最近のssh-keygenではデフォルトでed25519の鍵を生成するということもあり、ed25519を利用していることを前提として進めます。なにより、RSAの公開鍵に比べると短いので末尾部分が目立つはずです。 そもそも、ed25519のSSH公開鍵のフォーマットはどのようなものになっているか確認してみます。まずはssh-keygenコマンドで秘密鍵と公開鍵を生成します。 % ssh-keygen -t ed25
ナンプレ (いわゆる数独) の問題生成アルゴリズムの話。 | blog.dnpp.org
概要 iOS と macOS ネイティブなアプリを作った ので、技術的な話を書きます。 詳細 拠所無い事情からコンピュータサイエンスというか基本的なアルゴリズムの実装の勉強を leetcode でやっていた時期が 2023 年の 9 月頃にありまして、「折角勉強したんだし何か作るか」という気持ちでアプリを作りまして…。 リリースまでなんとか持っていった訳なんですが、実装だけならいいものの、ゲームデザインとか、 Web サイト作成とか、アイコン含むいわゆるデザイン的なものとか、そういうのも本当に 1 人で全部やってたからなんやかんや 3 ヶ月かかってしまって、まぁ大変だったんですがそこそこ満足な出来栄えになったので是非ダウンロードして触ってみてください。 数独はニコリの登録商標となっているためアプリの名称はナンプレとしていますが、この記事はアルゴリズムの技術的な解説やゲームデザインの話といっ
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
Haskell は Rust になれるのか？──2023年の Linear Haskell 体験記
追記：いくらなんでもあまりにも長いので、配列演算に焦点を絞ってより「Rustっぽさ」の気持ちを強調した姉妹編を書きました。手っ取り早く雰囲気を掴みたい方はこちらもどうぞ。 TL;DR GHC 9.0 から Haskell に入った線型型（Linear Types）の機能を一部割とガッツリ使ってみたので、Linear Haskell の現在の使い心地と将来の展望を報告するよ。 使おうと思えば使える段階にあるけれど、一部バグもあるし、まだ言語機能面で実装が追い付いていない部分もあって、快適に書けるようになるにはもうちょっと掛かるよ。それでも実用しようと思えばできるレベルにあるよ。 RustのようになるにはLinear Constraintsに期待。 更新履歴 2023/12/15 11:45 姉妹編へのリンク追加。 2023/10/01 12:30 線型性を納得してくれない場合の \eta-展
GitHub Actions could be so much better
I love GitHub Actions: I’ve been a daily user of it since 2019 for both professional and hobbyist projects, and have found it invaluable to both my overall productivity and peace of mind. I’m just old enough to have used Travis CI et al. professionally before moving to GitHub Actions, and I do not look back with joy1. By and large, GitHub Actions continues to delight me and grow new features that
Rust の DI を考える — Part 1: DI とは何だったか - paild tech blog
paild 社でお手伝いをしている yuki です。みなさんは Rust で DI をしようと思った際に困ったことはありませんか？この連載では、他のプログラミング言語で利用される DI パターンを参照しながら、Rust でそれを実装するためにはどのような工夫が必要かまでを検討します。中には Rust での実装が難しいパターンも出てくるかもしれません。その際は、なぜ難しいのかまでを検証します。 そこそこの規模のソフトウェアを実装するにあたって、ソフトウェアエンジニアが共通して利用する手法がいくつかあると思います。その中でも DI (Dependency Injection; 依存オブジェクト注入) は最もポピュラーな手法の一つであり、保守運用まできちんと耐えうるソフトウェアの設計をしたいとなったときに、まず真っ先に候補に上がる手法でしょう。 Rust ではこの DI をどのように行えばよいの
Rust の DI を考える –– Part 2: Rust における DI の手法の整理 - paild tech blog
paild 社でお手伝いをしている yuki です。前回に引き続き Dependency Injection 略して DI の話題を書いていきたいと思います。今回は Rust における DI についていろいろと考えてみました。今回紹介する実装はかなり単純な例を用いたもので、この記事からさらにみなさんのアプリケーションの実装状況に合わせていくつか工夫は必要になるかもしれません。ただ、とっかかりとしては十分なものになっていると思うので、DI でお困りの方はぜひ参考にしてみてください。 今回実装したいアプリケーションのお題について 今回紹介する技法の種別について コンストラクタインジェクション 静的ディスパッチを用いたもの 動的ディスパッチを用いたもの 静的ディスパッチと動的ディスパッチの利点・欠点 shaku （DI コンテナ）を用いたインジェクション shaku の利点・欠点 余談: DI
私がとあるOSS開発から手を引いた経緯 - Kengo's blog
ホットな話題に乗っかって、私がSpotBugsというJava向け静的解析ツールのOSS開発から手を引いた理由をまとめてみます。 自分がJavaを使わなくなった 先のブログでも指摘されている通りで、自分がそのソフトウェアを必要としなくなったというのは大きな理由になりました。Kotlinに乗り換えたことでJavaを書く機会がなくなり、Kotlinが生成したclassファイルの解析はSpotBugsには向かなかったので、SpotBugsを使わなくなりました。 SpotBugsにKotlin対応させることは技術的には可能ですが、ソースコードも考慮して解析できるdetekt（ktlint, diktat）がある世界でわざわざやることではないという感想です。 リターンが無かった 自分が使わないツールのメンテナンスを継続するには、やはりある程度の見返りを求めたいというのが自分の気持ちとしてありました。G
Keep Linux Open and Free—We Can’t Afford Not To
By Edward Screven, Chief Corporate Architect and Wim Coekaerts, Head of Oracle Linux Development—July 10, 2023 Oracle has been part of the Linux community for 25 years. Our goal has remained the same over all those years: help make Linux the best server operating system for everyone, freely available to all, with high-quality, low-cost support provided to those who need it. Our Linux engineering t
オープンソースビジネスの挑戦と現実｜Rui Ueyama
いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことではあったけれど、結論から言うと、そんなにはうまくいかなかった話ということになる。要点をまとめると次の通りだ。 「moldリンカ」というオープンソースのツールを開発して、それを元にビジネスを行おうとしていた そこそこ稼ぐことはできたものの、大きなリターンを得るのは難しかった ほとんどの企業はオープンソースを大々的に活用していても「無料のソフトウェア」にはお金を払うつもりはないし、払いたくても社内制度上できない 大きなリターンを得たいのならば、自作のオープンソース・ソフトウェアを元にサービスを立ち上げ
ソフトウェアエンジニアとしての能力を高める方法について考えてみた - joker1007’s diary
早朝の寝る前ぐらいの時間にぼやっと下記の様なツイートしたらちょっと反応を貰ったので、取り留めは無いが自分なりに考えていることを書いてみる。 人を育てるのも仕事の内というのは完全にその通りなんだが、そこにドキュメントや本があるから読みます、触って作ってみます、生きたコードを読みます、以外に学ぶ方法なんかねえし、知らねえよ。ただやればいいだけの事に説明も何も無いんだよな……。マジ分からん……。— joker1007 (アルフォートおじさん) (@joker1007) March 2, 2023 タイトルは雑に書いたけど、能力を高めるというと範囲が広過ぎるので、技術的な意味でできる事が増える、ということをテーマとして話をしていこうと思う。基本的に自分の考え方の話なのでそこは御留意ください。 ツイートした通りで、状況や対象に依って割合は変わるかもしれないが基本的にそのためにやることは3つしかないと
Mozcdic-UT (Mozc-UT)が終わった話と、代替品を開発してる話 - Chienomi
序 2023-01-12にLinux界隈に激震が走ったらしい。 Linux環境(Unix環境を含む)の日本語入力を支えていた、Mozcdic-UTプロジェクトが終了したからだ。 まず、前提として私の立場を明確にしよう。 私は2017年から、従来のMozc-UTに代わる新しい(ライセンス上の懸念のない)Mozc辞書として誕生したMozc-NEologd-UTのFcitxバインディング、fcitx-mozc-neologd-utのAURパッケージをメンテナンスしてきた。 その後新生Mozc-UTが誕生してからはfcitx-mozc-ut-unifiedとfcitx-mozc-ut-unified-fullというふたつのパッケージを加え、計3つパッケージをメンテナンスしてきた。 その後、mozcdic-ut自体がfcitx4をサポートしなくなったこと、fcitx5は既にメンテナーがいたことから私
JavaScript で CPU が Intel かどうかを判定する（ついでに JIT を検知する）
先日、次のような Tweet を見かけました TIL I discovered that TensorFlow.js uses an interesting trick to sniff your CPU architecture in WebAssembly. pic.twitter.com/LVyywIM48I — Robert Knight (@robknight_) January 4, 2023 面白かったので、なぜこうなるのかの解説と、ついでにこのテクニックを使った JIT 検知方法などについて紹介します。 JavaScript における低レイヤーの扱い JavaScript においては、挙動が比較的しっかりと仕様に定められているために、環境による振る舞いの違いはあまり発生しません。しかし、低レイヤーに降りるほど振る舞いは実装依存になり、環境差が発生する余地が出てきます。 一番
機能は追加すればいいというものではない
みなさん、新機能は好きですか。ソフトウェアへの機能追加は、ユーザ目線で単純に考えると「できることが増えていくのでよい」という響きを帯びています。しかし実際は、長く使われるソフトウェアであればあるほど、新機能を追加すべきかどうかはものすごく気を使って決めるものであって、やればいいというものではないのです。この記事の目的は、新機能の追加には細心の注意が必要だとわかってもらうことです。おもな対象読者はソフトウェアを長期間メンテしたことがないかたがたです。 みなさんが使っているOSSに新機能を追加するPRを送った場合を考えてみましょう。ここで重要なのは、PRが送られてきたメンテナやコミッタといわれるコア開発者たちの立場になって考えることです。彼らの役割は、自分たちを含むユーザがそのソフトウェアを使い続けられるようにメンテし続けることです。このメンテのコストに注目すると、機能追加は基本的にコストを上
yamlについて思うこと
yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない（複数の経路から同じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
