Ubuntu、zRAMの利用を検討中
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
Mac OS XのバイナリをGNU/Linuxで実行するソフトウェア
[Phoronix] A New Project To Run Mac OS X Binaries On Linux Mac OS X用のバイナリをGNU/Linuxで実行するソフトウェアが開発されているらしい。その名をDarlingという。 Darling - The Darling Project 名前についてだが、Mac OS XのカーネルであるDarwin用のソフトウェアを実行するので、Darlingという名前らしい。 Darlingは、Windows用のバイナリをGNU/Linuxで実行するソフトウェアであるWineと同じ仕組みで、Mac OS X用のバイナリを実行する。 すなわち、バイナリを読み込んでLinuxカーネル用に適切にメモリ上にマップし、Mac OS Xが提供しているAPIとABI互換の実装を用意し、バイナリ互換を実現するものである。Mac OS XのObjectiv
実行中のプログラムのファイルへの絶対パスを取得する方法
Microsoft Windowsならば、GetModuleFileNameのhModuleにNULLを渡せばよい。 ではGNU/Linuxではどうするのか。Linuxでは、"/proc/self/exe"が、参照したプロセスのファイルへの絶対パスのシンボリックリンクになっているので、これをreadlinkでたどればよい。 その他の環境は、以下を参照。 c++ - Finding current executable's path without /proc/self/exe - Stack Overflow Boostのfilesystemにそういう機能がほしいと思うのは私だけだろうか。 余談だが、/proc/self/exeについてググろうと、アドレスバーにそのまま入力したら、何やら70MBほどの、exeという名前のファイルがダウンロードされた。一瞬とまどったが、そういえば今の環境はG
なぜLinuxはクソなのか、なぜLinuxはクソじゃないのか
あまりにもUIをコロコロと変えすぎる。ドライバーのサポートがひどい。特にX.orgがバージョンアップするたびに、ドライバーが壊れる。X.orgのバージョンアップのたびに、ドライバーがオープンソースかどうかにかかわらず壊れる。X.orgまじでクソだ。大規模なソフトウェア、すなわち画像や音声や動画の編集ツールがない。パッケージ化の規格乱立しすぎ。 なぜ大規模なソフトウェアがないのかというと、金がないからだ。Linuxカーネルには、相当の金がかかっている。多くの企業が金を出してLinuxカーネルを開発させている。編集ツールには十分な金が出ていない。優れたソフトウェアには、金が必要である。どんな方法でもいいが、ソフトウェアの開発に金がでるようにしなければならない。どんな方法になるかは検討がつかないが、利用者が開発者に金を払う仕組みと文化が必要である。 先進的なUI、高いカスタマイズ性と選択性。ドラ
ValveのGNU/Linuxサポートが垣間見えてきた
ValveがGNU/Linuxをネイティブにサポートするという噂は聞こえていたが、なかなか音沙汰はなかった。この度、Phoronixの中の人がValveの中の人と会って、開発中の実物を見てきたらしい。 [Phoronix] Valve's Gabe Newell Talks Linux Steam Client, Source Engine SourceエンジンをGNU/Linuxに移植して、Left 4 Dead 2をネイティブに動作させているところを見学できたらしい。 話によると、ValveのGNU/Linuxサポートは真面目に開発中で、しかも、そう遠くない時期にリリースされるのだという。L4D2を選んだ理由は、コードベースが安定していて、最初の移植を試す土台として使いやすかったからだそうだ。 Valveは今後、他のSourceエンジンを使う他社のゲームや、その他のゲームについても、G
GNU/Linuxの方がWindowsより日本語サポートが優れている
今や、GNU/Linuxの方が不自由なWindowsより日本語サポートが優れている。これは純然たる事実である。 私は、UIが日本語化の質を論じているのではない。私はUIの言語を英語にしているので、UIの日本語の質についてはわからない。ただ、2012年となった今では、GNU/Linux/Xの環境の方が、圧倒的に日本語を扱う環境が優れていると考えているのだ。 まず、現行のまともなディストリは、文字エンコードをデフォルトでUTF-8にしている。このため、不自由なWindowsにおける、カオスな大量のマルチバイト文字コード混在環境の問題は存在しない。確かに、不自由なWindowsのネイティブの文字エンコードはUTF-16だが、下位互換性を保証するために、既存のマルチバイト文字をすべて継続してサポートしているために、未だにカオスな状況になっている。多くのプログラムは、嘆かわしいことに、いまだにANS
危険な誘惑
というわけで、私がGNU/Linuxに改宗してから10日たった。この間、新しい環境に慣れるため、色々と試している。必要なソフトウェアをインストールしたり、気に入らない設定を変更したりなどだ。本当に自分の好みに合うように調整しようとしたならば、結局、設定ファイルを手動でいじったり、CLIのツールを使う必要がある。これは、私にとっては、さほど問題ではない。私は自力で調べて解決するのが好きだし、英語も読めるのでドキュメントにも困らない。しかし、やはりこの状況は、一般人がデスクトップOSとして使うには、少々難しいことは否めない。 さて、ここで危険な誘惑がある。それは、現状に満足できないという状況だ。たとえば、今使っているソフトウェアは、最新のバージョンではない。たとえば、今この文章を入力するのに使っているMozcのバージョンは1.1.773.102だが、最新の安定板のバージョンは1.3.975.1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
