主にEmacsの話になりそう。C++や競技プログラミングの話もするかも。
Rustをまがりなりにも触れている身として、またGuix Systemを利用する身として、Guix System上でRustプロジェクト関連の諸々、たとえばビルドや実行を行いたいところだ。 Guix SystemはFilesystem Hierarchy Standard(以下FHS)に準拠しない上に ld がライブラリの場所をほぼ全く知らないため、Rustのプロジェクトがビルドできなかったり、ビルドできても実行できなかったりする。これはgcc系統のライブラリ、たとえば libgcc_s.so.1 がみつけられなかったり、自身でビルドしたsysライブラリ自体がみつけられなかったりするためだ。 ...
いままでRustのパッケージはすべてGuixのパッケージと一対一対応していた。そのため、あるRustパッケージをビルドするためには、 #:cargo-inputs として引数に渡されている依存パッケージをすべてビルドする必要があった(たしかビルドしないというオプションはあったはずだが)。一方Rustのビルドプロセス上、すべての依存はソースコードを利用してコンパイルされるため、依存パッケージがバイナリへビルドされている必要は全くなかった。また、Rustパッケージに対応するGuixパッケージの数も依存の数に応じてどんどん増えていってしまうなど、管理上の問題も多数あった。 ...
序文 前回の記事では、パッケージの作り方を扱いました。パッケージを作ったら、今度は自分のEmacsに導入したいと考えるでしょう。これを行う方法もいろいろあります。 Emacsのパッケージマネージャを以下に列挙してみます。 GNU GuixやNix、aptなどの汎用パッケージマネージャは除いています。 中央集権型 package.el(標準) 分散型 el-get(ただしpackage.elを透過的に利用可能らしい) Cask elpaca straight.el quelpa この分類は、パッケージのビルドがどこで行われるかに着目しています。適当なレシピ、つまりパッケージ定義が与えられた下で、中央集権型はサーバーにおいてビルドされたパッケージをダウンロードするタイプ、分散型はローカルでビルドするタイプのパッケージマネージャです。 ...
序文 Emacsは完全に素のまま使うと若干不便なところがたくさんあるので、 Emacs Lispを利用してカスタマイズすることがあるかと思います。 単にEmacsの変数を触る程度であれば問題はありませんが、自分の欲しい機能を設定ファイル init.el に直接書いていると、 保守の観点であまりよろしくありませんし、人に使ってもらうのも大変になってしまいます。 ...
更新履歴 2023-06-09: チャンネルの依存のintroduction節の書き方の変更 序文 前回の記事では、ビルドを伴うパッケージの作成を行いました。しかし、どうしてもビルドがうまくいかないこともあります。特に前回触れたインポーターがまだない他の既存パッケージマネージャで管理されたソフトウェアや、そもそもインポーターが介在する余地のないような独自のビルド手順を持つソフトウェアなどで、まだGNU Guixの公式チャンネルに実装されていない依存が大量にある場合には、多大な労力が必要になります。さらに言うと、我々が利用しているソフトウェアはソースが公開されているとは限りません。そのようなプロプライエタリなソフトウェアをソースコードからビルドすることは当然不可能です。このような場合、GNU Guixでソフトウェアの管理を行うことは不可能なのでしょうか。 ...
序文 前回の記事では、フォントのパッケージ定義を通じて、パッケージ定義の流れを解説しました。この記事では一歩進んで、ビルドを伴うパッケージの定義を行っていきます。 実はGNU Guixはその思想上、この「ビルド」というプロセスをきちんと行うことを大切にしています。 前回の記事で、ハッシュ値を確認することで偽物を掴まされていないことを確認するプロセスがあることを説明したと思いますが、その一方で配信元がウイルスやマルウェアなどの悪意のあるコードを仕込んでいる場合は感知することはできません。これを防ぐための究極の方法は、ソースコードから直接ビルドすることです。公開されているソースコードからビルドすれば、ソースコードを確認することで悪意のあるコードが混入していないかを確認することができます。一方公開されているバイナリを直接インストールする方法の場合、悪意のあるコードが混入していることを確認する術はありません。元のソースコードが公開されていても、そのバイナリがそのソースコードからビルドされたことを確かめられないので無意味です。 このような理由で、GNU Guixはあらゆるパッケージを自分の手元でビルドすることを信条としています。もちろんサイズが大きいパッケージをたくさん使うような場合、全てビルドするのは大変な場合もあります。そのため、「このサーバーのビルドしたパッケージは信用できるので、ビルドする代わりにバイナリからインストールする」というのを実現する機能があります。この機能はSubstitutesと呼ばれています。デフォルトではGNUのサーバーだけが登録されています。詳しくは公式マニュアルをご覧ください。また、この機能はあくまでも「ビルド手順をパッケージ定義として示した上で、その手順と全く同一の手順を踏んでいるであろうバイナリを提供するサーバーを信用する」という機能であることに注意してください。ビルド手順の記述を省略するようなことはできません。そのへんに落ちているバイナリから直接インストールする機能は次回の記事で説明します。 ...
序文 GNU Guixでは、簡単にパッケージを作り、自分でそれを利用することができます。 GNU Guixでは、パッケージ定義群は「チャンネル」という名前がついています。 各々が自分だけのチャンネルを作り、それを公開するなりローカルに保持するなりし、Guixにそれを教えてあげることで、 そのチャンネルを経由してパッケージを利用することができるようになります。 ...
はじめに GNU Guix System(以下Guix System)とは、GNUの開発するLinuxディストロのひとつで、GNU Guix(以下Guix)という パッケージマネージャと密結合している。GuixはSchemeで管理できるパッケージマネージャで、 隔離された環境によるビルドやロールバック可能な操作が特徴で、再現性と環境の隔離に重点を置いている。 これをWindowsの入ったx64のPCにインストールする。面倒なので新しいディスクを用意してそちらにインストールした。 Windowsのディスクはそのまま残したので、起動時にF12を連打してブートディスクを選択すればWindowsも起動できる。 ...
結論 下記URLにある pdfcrop.sh をつかう。 pdfcrop.sh -m 0 input.pdf output.pdf 。 https://tex.stackexchange.com/questions/42236/pdfcrop-generates-larger-file はじめに 電子書籍リーダで読む場合、LaTeXで吐いたPDFとかだと、あきらかに余白が大きい。 製本するならそれでもよいが、電子書籍リーダで読むなら余白は邪魔なだけだ。 これをばっさりなくしたい。 ...
基本的には参考にあるサイトに準拠しています。 必要なもの USBハブ (USB端子が1つしかないため、以下の2つを同時に接続するために必要) USBキーボード (途中までSurfaceにもとからついているキーボードは使えません) USBメモリ (Ubuntuのブート用) ブート用のUbuntuをUSBメモリに用意する 基本ここのとおりにやればよい。あらかじめ作っておいてある人もいそう。ここ以外にもたくさん文献があると思うので ここでは説明しない。 ...