NGINX、商用版の重要な機能をオープンソースで無料化、オートスケールやCI/CDフックなどフルスタック化など、今後の発展についてコミットを発表
NGINX、商用版の重要な機能をオープンソースで無料化、オートスケールやCI/CDフックなどフルスタック化など、今後の発展についてコミットを発表 オープンソースのWebサーバ「NGINX」（エンジンエックス）の開発元であるF5 Networksは、オンラインイベント「F5 NGINX Sprint 2022」を開催中です。 そこでNGINX開発チームは、今後のNGIXの発展に向けて、ソースコードをMercurialからGitHubへ移行すること、有償版の機能をオープンソースへ移植して無料で利用可能にすること、単なるWebサーバ機能だけでなくCI/CD機能などを拡張することなど、3つの約束を発表しました。 GM of #NGINX @rwhiteley0 has just announced three #opensource promises that will come to life
Big Sky :: sudo の特権昇格バグはなぜ起こったのか
« Microsoft Word を Markdown に変換するコマンド「docx2md」を作った。 | Main | VimConf 2019 を終えて » Linux の sudo に root 権限を奪取できるバグが見つかった。 Linuxの「sudo」コマンドにroot権限奪取の脆弱性。ユーザーID処理のバグで制限無効化 - Engadget 日本版 この脆弱性は、sudoコマンドのユーザーIDに-1もしくは4294967295を指定すると、誤って0(ゼロ)と認識して処理してしまうというもの。0(ゼロ)はrootのユーザーIDであるため、攻撃者は完全なrootとしてコマンドを実行できることになります。 https://japanese.engadget.com/2019/10/14/linux-sudo-root-id/ 既に Ubuntu 等にはパッチが配布され始めているらしい
Sunsetting Mercurial support in Bitbucket - Bitbucket
[Update Aug 26, 2020] All hg repos have now been disabled and cannot be accessed. [Update July 1, 2020] Today, mercurial repositories, snippets, and wikis will turn to read-only mode. After July 8th, 2020 they will no longer be accessible. The version control software market has evolved a lot since Bitbucket began in 2008. When we launched, centralized version control was the norm and we only supp
COBOLをシートに手書きしていた頃。80〜90年代、OSS普及前の開発風景に学ぶこと - エンジニアHub｜若手Webエンジニアのキャリアを考える！
COBOLをシートに手書きしていた頃。80～90年代、OSS普及前の開発風景に学ぶこと インターネットが一般的ではない時代にエンジニアはどのように仕事をしていたのでしょうか。WebDINO Japanの瀧田佐登子さんに、かつてのエンジニアの姿、そしてオープンソースという概念が一般化していく過程を、貴重なエピソードとともに聞きました。 オープンソースというカルチャー、そしてそこから生み出されるソフトウェアは今やあらゆる開発活動に不可欠なものです。多くのIT、インターネット関連企業の開発は、オープンソースなくしてもはや成り立たないでしょう。 一方で、言うまでもなくオープンソースという概念がまだ一般的ではない時代もあり、そしてその時代にも開発は行われていたのです。 「オープンソース」という言葉は、1998年に『伽藍とバザール』の著者、エリック・レイモンドによって発表されましたが、この言葉が指し示
モノリシックなバージョン管理の利点 | POSTD
以下は、私がよく交わす会話の一例です。 人物A：FacebookやGoogleは、巨大なモノリシックリポジトリ（モノレポ）を使っているんだってよ。 私：みたいだね。あれは本当に便利だと思う。 人物A：僕に言わせれば最悪の愚行さ。全てのコードを単一のリポジトリに入れるのがヒドイ考えだと、FacebookやGoogleはなぜ思わないんだろうか。 私：FacebookやGoogleのエンジニアたちも小さなリポジトリには精通しているだろうけど（ 濱野純（Junio Hamano） 氏はGoogle勤務だし）、単一の大きなリポジトリの方が、きっと”ある理由”で好みなんだよ。 人物A：なるほどね。僕としては、まだちょっと違和感はあるけど、モノレポが使われる理由は分かったような気がするよ。 “ある理由”はかなり長いので、同じ会話を何度も繰り返さなくていいように、ここに書き留めておこうと思います。 シンプ
SphinxをMarkdownで使い隊
Sphinxを、MercurialとPandocを組み合わせて Markdown記法で運用できるようにしたお話。
nginxの開発MLにパッチを送る - Qiita
先日nginxでValgrindの警告を消すパッチを開発メーリングリストに投稿した時のメモ。 nginxはバージョン管理にMercurialを使っている。Mercurialには指定したリビジョンのコミットからパッチを生成するコマンドと、パッチファイルをコミットとして取り込むコマンドがあるので単なるunified diffテキストを送るよりはこれを使う方が良さげ。 パッチ作成対象のコミットは以下のリビジョンのもの。なお、これ自体は既にnginx本体に取り込まれたものなので、実際に送ったパッチやその際のやりとりについてはこちらのスレッドを参照。 $ hg log -r 5252 changeset: 5252:982678c5c270 tag: tip user: Tatsuhiko Kubo <cubicdaiya@gmail.com> date: Wed Jun 12 00:41:24 2
Git hg rosetta stone
The sympy git server is at https://github.com/sympy/sympy . The main Sympy repository may be cloned with git clone git://github.com/sympy/sympy.git. The first and the most important thing is that you should understand that git is different. For example it uses staging area (so called index) for iteratively preparing commits. This and other great and unique features of git make it the preference of
github への移行準備
以下 Bram Moolenaar 氏が vim-dev にポストした内容。 https://groups.google.com/forum/#!topic/vim_dev/Io5A_Zir–k Google Code がシャットダウンする事になったので、我々は Vim のリポジトリの 為の新しい場所を必要としている。 多くのユーザーが各々の意見を出し、github を推す声が多いようだ。 これには不都合もあり、というのも、github へ移行するということは Mercurial から git へ移行するということだからだ。 これが気に入る人もいるだろうし、そうでない人もいるだろう。 しばらくかけて慣れる必要があるだろう。 私は個人的には Mercurial コマンドの方が好きだ。使い方がより明確だからだ。 君たちは Mercurial コマンドから git への置き換え方法を見つける事が
Mercurial に関するコミュニティ由来の成果(2014年版) - 彷徨えるフジワラ
本エントリは、2014年の一年間に、ML/twitter/勉強会といったコミュニティから上がった情報／要望の中で: Mercurial 本体に取り込まれた修正の契機になったもの Mercurial 本体に取り込まれてはいないものの、何らかの成果に結びついたもの 『今後の作業のネタ』(＝ バックログ)として認識されているもの 上記に該当するものを、情報提供への感謝の意味も込めて、列挙したものです。 『気になった点に関して、情報提供をする』だけでも、十分開発に貢献できる事の証拠とも言えます。 今後も、Mercurial に関して疑問／質問／要望等があれば、お気軽に情報をお寄せください ＞ 利用者の皆様 情報をお寄せ頂く手段に関しては、"Mercurial で困った時に" をお読みください。 また、抽出が大変だったので本エントリでは列挙しませんでしたが、メッセージ翻訳に関する不具合報告／要望等も
OS毎のシステムコール実行性能 〜 その1 - 彷徨えるフジワラ
Mercurial のテストセット ("make tests") を複数の環境で実行したところ、ほぼ同一性能の CPU 上での実行にも関わらず、Mac OS X 上での実行では、仮想環境上の Linux での実行よりも、大幅に時間を要することが確認できました。 仮想環境上の実行ではクロック情報の精度がよろしくないので、計測主体が仮想環境上にあるベンチマーク結果はあまり信用できない、ということを考慮に入れても、明らかに体感できるレベルで遅い（分単位の所要時間差）ので、単純に「仮想環境上の計測誤差が、良い方向に出ている」と片付けるわけにも行きません。 そこで、幾つかのシステムコールに関して、OS 間での実行性能を計測してみることにしました。 元々の比較対象が「Mercurial のテストセット」なので、比較的影響が高そうな、以下のシステムコールを計測対象にします。 fork/exec 等による
データのためのGit（およびGithub） | オープンデータとオープンガバメントを推進する Open Knowledge Japan
（訳注：この記事は本家OKFn.org記事の日本語訳です） データのために「バージョン管理」を行う能力は重要な関心事です。様々な選択肢がありますが、最も魅力的なもののひとつは、Git やMercurial のように、コード用の既存ツールを再利用することです。この投稿では、私たちが暫くの間使用してとても効果的だということが分かったツールを利用する、データの格納とバージョン管理のための単純な「データ・パターン」について記述しています。 序章 行われた変更を格納し、それを他の人と共有する、データのバージョンとリビジョンを管理する能力、とりわけ分散的な手法は（オープン）データ・コミュニティにとって大きな便益となるでしょう。私はその理由を以前（こちらの初期の記事を参照）議論しましたが要約すると： 効率的な分散型の共同作業が可能です。私のデータセットを取り出し、変更し、それを再び私と（同時に他の人とも
Cram: It's test time
Cram is a functional testing framework for command line applications based on Mercurial's unified test format. Cram tests look like snippets of interactive shell sessions. Cram runs each command and compares the command output in the test with the command's actual output. Here's a snippet from Cram's own test suite: The $PYTHON environment variable should be set when running this test from Python.
SourceTree for Windows 1.4 をリリースしました！ | Atlassian Japan 公式ブログ | アトラシアン株式会社
どこからでもアクセスできるように、SourceTree のインストールディレクトリをお使いのパスにインストールすると良いでしょう。 翻訳版 翻訳者の募集に対する皆さんの反応のおかげで、今や SourceTree for Windows 1.4 は英語、日本語、中国語、フランス語、ドイツ語、そしてロシア語の六カ国語で利用できます。最後の三つの言語は 100% は仕上がっていないものの、主要部分は既に翻訳済みです。残りの部分の翻訳作業に加わりたいとお考えの方は、翻訳作業への参加をお願いします！ パッチファイルサポート 今後は、SourceTree 内でパッチの作成および適用を行えるため、未コミットの作業状態から構成されるパッチ、および一つあるいはそれ以上のコミット済みパッチを効果的に使用できます。SourceTree は、パッチ生成におけるあらゆるオプションを簡単なインターフェイスへと収集し、
Facebook の Mercurial に対する本気度まとめ - 彷徨えるフジワラ
Facebook のエンジニアブログで "Scaling Mercurial at Facebook" と題するエントリが 2014-01-07 に公開され、大きな注目を集めました。 また、このブログエントリについて解説した InfoQ の記事 "Facebook makes Mercurial faster than Git" や、その翻訳 "Facebook、MercurialをGitよりも速くする" も、多くの人がリツイートするなどして話題にしています。 このエントリでは、上記の記事では触れていない、Facebook の Mercurial への本気具合について、まとめてみました。 人的関与 Facebook は Mercurial の主要開発者を何人も雇用しています。最も顕著な例が、Mercurial プロジェクトのリーダーである Matt Mackall 氏その人の雇用でしょうか
Git 対 Subversion：長引く争い | readwrite.jp
ソフトウェア業界においてGitが支配的な存在ではなかった時代がかつて存在した、といつか言われる日が来るかもしれない。 2010年にはSubversionが、ソフトウェアの共同開発には欠かせないツールであるバージョン管理システムの60％以上を占めていた。Forresterによれば、この時期Gitのシェアはわずか2.7%であった。Redmonkのアナリストであるステファン・オグレディが集めたデータによると、今日ではGitのシェアは28%まで増加し、Subversionの地位を脅かしている。 Subversionのような集中型のシステムよりもGitのような分散型の方が優れているにも関わらず、マーケットがGitを受け入れるのにこんなに時間がかかっている理由は何だろうか？ これからは分散型が主流になるバージョン管理システム（VCS）は、ソフトウェア開発の変更点を記録してプロジェクトを管理するための基
本の虫: Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて
Bazaar-NG: 7 years of hacking on a distributed version control system Bazaarの開発者が、Bazaarが失敗した理由について、当時を振り返って書いている。なかなか面白い。 Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて この7年間、筆者はBazaarプロジェクトに関わってきた。筆者はプロジェクトから距離を置き始めている今この時、筆者のこのプロジェクへの関わりや、何が良くて何が悪かったのかの意見などを、振り返ってみるべきだと思う。 この回顧録には多くの複雑な詳細が出てくるので、筆者の誤りもあるかも知れない。間違いを見つけたら知らせてくれ。 黎明期 < ddaa> dscmsには2種類ある。古臭いやつと、実験中なやつ。 2004年、筆者は、 SambaのコントリビューターであるMartin Pool
"Android Studio最速入門" 第32回に関する指摘 - 彷徨えるフジワラ
連載 "Android Studio最速入門〜効率的にコーディングするための使い方" における "第32回 バージョン管理─Mercurial連携の使い方" での Mercurial 連携に関する説明で、気になる点があったので、まとめておこうと思います（筆者の方には報告済み）。 ある程度 Mercurial を使い込んでいる人であれば、多分言うまでもない話かもしれませんが、Git と併用しているような人や、Mercurial 初学者の誤解を防ぐことができれば幸いです。 あちらの記事の読者が、こちらのエントリに辿りつけるのかは、微妙なところではありますが、まぁ、そこはネット（＋検索）の力を信じることにしましょう（笑）。 リポジトリを最新の状態に保つ 1ページ目の「リポジトリを最新の状態に保つ」での: つまり，hg pullはGitでいうgit fetch相当なので，git pullに相当する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - facebook/sapling: A Scalable, User-Friendly Source Control System.
Facebook、MercurialをGitよりも速くする
