第796回 LXDとIncus、今後どちらをUbuntuユーザーは使うべきか？ | gihyo.jp
Ubuntu Weekly Recipe 第796回LXDとIncus、今後どちらをUbuntuユーザーは使うべきか？ 本連載でも何度か紹介しているコンテナ・仮想マシンの管理システムである「LXD」がCanonicalの管理になった結果、コミュニティ版の「Incus」が登場しました。詳しい経緯は「LXCで学ぶコンテナ入門」の第55回「コンテナと仮想マシンのマネージャ"Incus"」に記述されています。今回は少し趣向を変えて、「UbuntuユーザーはLXDとIncusのどちらを使うべきか」という観点から、Incusを紹介します。 UbuntuとLXDとIncus 冒頭でも説明したように、LXDのコミュニティ版フォークとしてIncusが登場しました[1]。 フォークに至った詳細な流れは「LXCで学ぶコンテナ入門」が参考になりますが、かんたんに説明すると次のような時系列になります。 Lin
Rustで作るLinuxデバイスドライバ
だれでもできるシリーズとして、Rustでカーネルモジュールを実装しながら学んできましたが（役に立たないキャラクタデバイスドライバなど）、そろそろ実際に使える機能を実装したいころですよね！ 今回は、筆者が実装したネットワークPHYドライバが、Rustで実装された初めてのデバイスドライバとしてLinuxカーネルに採用された話を紹介します。 誤解：LinuxカーネルがRustをサポート「LinuxカーネルがRustをサポートした」というニュースを見て、Rustのコードがどんどん採用されていると誤解している方もいるようです。このニュースは、「LinuxカーネルをRustでも書けるようになりましたが、実際に何かを実装するかどうかは未定」という意味です。Linuxカーネルは、メモリマネージメント、ネットワーク、暗号など、数多くのサブシステムで構成されており、それぞれのメンテナが、コードの採否を判断しま
POSIXシェルスクリプトではwhichではなくcommand -vを使うべき理由（＋シェルスクリプト版which） - Qiita
重要 2022-01-30 追記 この記事で解説していた警告の出力は 2022-01-21 に取り消されました（参照 Revert deprecation of which）。そのため Debian which が GNU which に変わることは（少なくとも近い未来では）ないと思います。しかしながら which を使うよりは POSIX で規定されている command と type を使う方を推奨します。 はじめに which コマンドはシステムにインストールされてるとは限りません。実際に最小構成でインストールされてない環境として CentOS があります。一方 command -v は POSIX 規定されているので POSIX に準拠したどのシェルでも問題なく使えます。シェル上では which コマンドを使っても良いと思いますが、シェルスクリプトでは command -v を使う
第793回 自作のカーネルモジュールをRustで作る | gihyo.jp
第791回では基本的なカーネルモジュールの作り方とそれをDKMSに対応させる方法を紹介しました。今回はカーネルの新しい機能のひとつである「Rustでカーネルモジュールを作る方法」を紹介しましょう。 UbuntuカーネルにおけるRustの対応 Linuxカーネルでは、Kernel 6.1からプログラミング言語である「Rust」の機能が取り込まれました。これは「Rust for Linux」の成果で、カーネルの機能をC言語やアセンブラだけでなく、Rustでも書けるようにするというものです。メモリー安全性や強い静的型付けなどの特徴を取り込むことで、カーネルのセキュリティ問題の原因の多くを占めるメモリー関連の不具合に対して、一種の対策になることが期待されます。 あらゆるケースにおいてRustに置き換えられるというわけではありませんが、今後カーネルのコードを読み書きする上でC言語やアセンブラだけでな
ベテランエンジニアも意外と知らない「パッケージ管理システムの仕組み」 - Qiita
この記事はNuco Advent Calendar 2023の16日目の記事です。 1. はじめに 世の中には、複雑な計算や面倒な分析を1行で済ませてくれるような便利なパッケージが数多くあります。それらをインストールするときには、以下のようなOSやプログラム言語に応じた簡単なコマンドを実行していることでしょう。 あなたがパッケージをインストールする裏で、それらのパッケージを管理するシステムが地獄のような処理を人知れず行なっていることはご存知でしたか？ 本稿ではそんな縁の下の力持ちであるパッケージ管理システムが、一体どのような仕組みで動いているのか、その全貌を明らかにしていきたいと思います！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方
LTS版「Linux」カーネルのサポートが短縮へ--背景にメンテナーの苦悩
現地時間9月19日からスペインのビルバオで開催されていた「Open Source Summit Europe」で、Linuxカーネル開発者であり、LWN.netの編集責任者を務めているJonathan Corbet氏が、Linuxカーネル関連の新しい点や今後の動きについて発表した。 ここではその中から、今後の大きな変更点の1つを紹介したい。それは、Linuxカーネルの長期サポート（LTS）が6年から2年に短縮されるということだ。 LinuxカーネルのLTS版には現在のところ、6.1と5.15、5.10、5.4、4.19、4.14の6つがある。これまでであれば、4.14は2024年1月にサポートが終了し、別のカーネルが追加されていた。しかし今後は、4.14とその次の2つのバージョンのサポートが終了しても、別のカーネルがそれに取って代わることはない。 なぜだろうか。Corbet氏は単純なことだ
Linux システムコール 徹底入門
Linux システムコールについて調べたことをまとめる。システムコールの仕組みを理解すると、 OS とアプリケーションがどのように連携して動いているのかを理解できるようになります。 システムコールは CPU に依存する処理が多いため、 x86_64 に絞ります。 検証環境]# cat /etc/redhat-release CentOS Linux release 8.0.1905 (Core) ]# uname -a Linux localhost.localdomain 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Tue Sep 24 11:32:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux ]# cat /proc/cpuinfo | head processor : 0 vendor_id : GenuineInte
Linuxを再起動することなくカーネルにパッチを当てる「ライブパッチ」の技術的な仕組みと、その種類とは［PR］
Linuxを再起動することなくカーネルにパッチを当てる「ライブパッチ」の技術的な仕組みと、その種類とは［PR］ Linuxのアップデートパッチは脆弱性の大小にかかわらず、ほぼ毎月のように登場しているのが現状です。 パッチの適用を放置することは脆弱性を放置することにつながるため、脆弱性対策のパッチが公開されたならば、迅速なパッチの適用が望まれます。特に最近ではセキュリティの脆弱性を突かれたことで深刻な被害を被る企業などの事例が社会的な注目を集めるようになっており、迅速なパッチ適用の重要性は高まってきています。 一方で、ビジネス上の要請としては計画停止であってもサーバの停止は最低限で済ませることが望ましいとされています。計画停止であっても、数分から長いときには数十分かかるLinuxサーバの再起動を伴うアップデート作業を可能な限り回避したいという要望は変わらないでしょう。 ITの現場はこの、セキ
リーナス・トーバルズ氏、「LinuxでAMDのfTPM機能を無効化するのはどうか」と発言
Linuxの開発者であるLinus Torvalds氏は7月31日（現地時間）、メーリングリストに「Let's just disable the stupid fTPM hwrnd thing（バカなfTPMを無効化しよう）」と題したメッセージを送信した。AMD Ryzenプロセッサが内蔵するfTPMのバグがLinuxカーネルに問題を起こしており、fTPMを使う機能を無効化すべきだという。 リーナス・トーバルズ氏、「AMDのfTPM機能を無効化するのはどうか」と発言 画像はASUS YouTubeから Ryzenプロセッサにはセキュリティ機能としてfTPM（IntelではIntel PTTを内蔵）が内蔵されており、Windows 11のインストールにおいては要件としても掲出されている。このAMD fTPMのハードウェア乱数生成器にバグが存在していたことが発端となっており、一部の環境でシステ
オラクルもRed Hatに反論。RHELクローンOSへの非難は、競合他社を減らして儲けようとしているからではないか － Publickey
オラクルもRed Hatに反論。RHELクローンOSへの非難は、競合他社を減らして儲けようとしているからではないか Red Hatは先月（2023年6月）、Red Hat Enterprise Linux（RHEL）のソースコードの一般公開を事実上終了させる措置を発表し、さらにRHELのクローンOSを提供しているベンダを「オープンソースに対する脅威だ」と非難する内容をブログで明らかにすることで、RHELのクローンOSの存在を否定する意志を明確にしました。 参考：Red HatがクローンOSベンダを非難、「付加価値もなくコードをリビルドするだけなら、それはオープンソースに対する脅威だ」と これによってRHELのクローンOSを開発する作業は従来よりも困難になりました。 RHELはエンタープライズLinuxにおける事実上の標準となっており、クローンOSもそのエコシステムの一部になっている現状にお
あの日見たLinuxのディレクトリやコマンドのフルネームを僕達はまだ知らない - Qiita
はじめに Linux利用歴はそこそこありますが、よく使うディレクトリやコマンドのフルネームを全て知っているかというと、そうでもないなと思ったので、今回はそれについてまとめてみました。 特にLinux初学者の方にとっては、各ディレクトリ名やコマンド名は何の略称かを知っておいた方が、覚えやすいと思うので、ぜひ参考にしていただければと思います。 注意事項 本記事では、よく使うディレクトリやコマンドの中で略称になっているもののみを取り上げています。すべてのディレクトリやコマンドを網羅しているわけではありません。 略称のフルネームがすべて明確に文書化されているわけではありません。これらの略称は、元々UNIXや他のプラットフォームで使用されていたものや、開発者やコミュニティの独自の規則や慣習に基づいています。 Linuxディストリビューションによっては、独自の命名規則や用途を持っている場合もあります。
apt-key is deprecated への対応
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). package 署名の公開鍵の管理方法が変わったみたいです リポジトリごとに公開鍵を別に管理する方が安全だということで例えば PostgreSQL の debian 向けドキュメントには2022年10月15日時点で次のように記載されています # Create the file repository configuration: sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list' # Import t
第765回 高度なことが簡単にできる多機能バックアップツール、Restic［前編］ | gihyo.jp
今回はGo言語で書かれた、オープンソースでマルチプラットフォームなバックアップツールであるResticを紹介します。前後編に分かれており、今回はインストールとバックアップ方法2種類を解説します。 Resticとは 第653回で紹介したDéjà DupはDuplicityというバックアップツールのフロントエンドです。しかしバージョン43.0以降はバックエンドをResticへ変更できるようになっています。 図1 Déjà Dupの実験的機能。なおこのタブは表示されない場合もある Duplicityは高性能ではあるもののコマンドラインオプションが複雑で使用するのは難しく、Duplyというコマンドラインのフロントエンドまであるくらいです。 ではこのResticはどうなのかと思って調査したところ、後発（とはいえ最初のリリースは8年前）だからか洗練されており、かつGo言語で書かれているのでメンテナンス
Microsoft、オリジナルディストリビューション「Azure Linux」の一般提供を開始 | gihyo.jp
Linux Daily Topics Microsoft、オリジナルディストリビューション「Azure Linux」の一般提供を開始 Microsoftは5月23日（米国時間）、開発者向けの年次カンファレンス「Microsoft Build 2023」において、Azure上のコンテナワークロードに最適化されたLinuxディストリビューション「Azure Linux」の一般提供（GA）開始を発表した。Hyper-VをベースにしたAzureクラウドおよびエッジ環境にデプロイし、複数のコンテナを実行するように設計されており、「Azure Kubernetes Service（AKS）」のコンテナホストとして利用される。 Introducing the Azure Linux container host for AKS - Azure Infrastructure Blog Azure
Linuxのローダを自作する
概要 Linuxのスタンダードなローダ、ld-linux-x86-64.so.2 の挙動を理解するために、ld-linux-x86-64.so.2を置き換え可能な https://github.com/akawashiro/sloader を2年ほど前から開発しており、ある程度動くようになってきました。 目次 ローダとは何か ld-linux-x86-64.so.2 の問題点 sloader sloader の現状 sloaderの実装 libc.so内のシンボルの解決 ロードされたプログラムのためのTLS領域の確保 sloaderの課題 お願い ローダとは何か Linuxで実行可能なバイナリファイルをexecve(2)を使って実行するとき、その実行パスは大きく2つに分類されます。 Linux カーネルが直接、バイナリファイルをメモリ空間にロードする。 バイナリが指定したローダ[1]がバイ
第52回 Linuxカーネルのコンテナ機能 ― cgroupを使ったI/O制限 | gihyo.jp
第37回で説明した通り、cgroup v1には様々な問題点が指摘されており、その問題を解決すべくcgroup v2が実装されました。 cgroup v1では、各コントローラがバラバラに実装されており、コントローラ間の連携が取れませんでした。これが原因で、リソースを制限するにあたって一番表面化していた問題が、ディスクI/Oに対して制限をかける際の問題でした。cgroup v1ではblkioコントローラでI/Oに対する制限をかけられましたが、限定的な制限しかかけられませんでした。 LinuxでのI/O コントローラ間で連携ができないため、blkioコントローラを使ったI/O制限が限定的になってしまう理由を説明するために、Linuxでディスクへファイル入出力する際の仕組みを簡単に説明しておきましょう。もう少し詳しい仕組みが知りたい方は『［試して理解］Linuxのしくみ』など、関連する書籍や文書を
LinuxコンテナをFreeBSDで動かす「Linux containers on FreeBSD」、containerd 1.7.0で正式サポート
LinuxコンテナをFreeBSDで動かす「Linux containers on FreeBSD」、containerd 1.7.0で正式サポート コンテナランタイムのもっとも代表的な実装としてCloud Native Computing Foundation（CNCF）が開発を主導するのが「containerd」です。 その最新版として3月11日付でリリースされた「containerd 1.7.0」に「Linux containers on FreeBSD」が正式な機能として組み込まれました。 Linux containers on FreeBSDは、LinuxコンテナをFreeBSD上で実行する際に、FreeBSDのファイルシステムの代わりLinuxファイルシステムにマウントする機能だと説明されています。 FreeBSD上でLinuxコンテナを実行可能に FreeBSDには以前からシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Watchexec
【Ubuntu日和】 【第32回】フォントと日本語入力の、ホントの話
apt-get update only for a specific repository
