スラックウェア

スラックウェア

デスクトップ環境としてKDE Plasma 5を搭載した Slackware 15.0
開発者	パトリック・フォルカーディング
OSファミリー	Linux ( Unix ライク) ( Softlanding Linux Systemベース)
作業状態	現在
ソースモデル	オープンソース
初回リリース	1993年7月17日; 31年前[1] ( 1993-07-17 )
最新リリース	15.0 [2] [3] [4] / 2022年2月2日; 2年前 ( 2022年2月2日)
利用可能	多言語
更新方法	pkgtool、slackpkg
パッケージマネージャー	pkgtool、slackpkg
プラットフォーム	IA-32、x86-64、ARM
カーネルタイプ	モノリシック( Linux )
ユーザーランド	GNU
デフォルトの ユーザーインターフェース	コマンドライン
ライセンス	GNU 一般公衆利用許諾書
公式サイト	詳しくはこちら

Slackwareは、 1993年にパトリック・フォルカーディングによって作成されたLinuxディストリビューションです。もともとSoftlanding Linux System (SLS)をベースにしており、^{[5] Slackwareは他の多くのLinuxディストリビューション、特に}SUSE Linuxディストリビューションの最初のバージョンのベースとなっており、現在もメンテナンスが行われている最古のディストリビューションです。^[6]

Slackware は、設計の安定性とシンプルさを追求し、最も「Unix ライク」なLinux ディストリビューションを目指しています。^[7]アップストリームのソフトウェア パッケージへの変更は最小限に抑え、ユース ケースを予測したり、ユーザーの決定を妨げたりしないようにしています。最近の Linux ディストリビューションのほとんどとは対照的に、Slackware はグラフィカルなインストール手順やソフトウェア パッケージの自動依存関係解決を提供していません。設定と管理にはプレーン テキスト ファイルと少数のシェル スクリプトのみを使用します。さらに変更を加えないと、コマンド ライン インターフェイス環境で起動します。多くの保守的でシンプルな機能があるため、Slackware は、上級者や技術志向の Linux ユーザーに最適であると考えられています。^{[8] [9] [10] [11] [12] [13]}

SlackwareはIA-32およびx86_64アーキテクチャで利用でき、 ARMアーキテクチャへの移植版もあります。Slackwareは主に^[14] 無料のオープンソースソフトウェアですが、正式なバグ追跡機能や公開コードリポジトリはなく、リリースはVolkerdingによって定期的に発表されます。開発者向けの正式なメンバーシップ手続きはなく、Volkerdingがリリースの主な貢献者です。

「Slackware」という名前は、このディストリビューションが、特に関与する意図のないプライベートなサイドプロジェクトとして始まったことに由来しています。最初は真剣に受け止められすぎないように、フォルカーディングはユーモラスな名前を付けましたが、Slackwareが本格的なプロジェクトになった後もその名前はそのまま残りました。^[15]

Slackware は、パロディ宗教であるサブジーニアス教会の教義である「Slack の追求」に由来しています。Slackware のグラフィックスの特定の側面はこれを反映しています^{[16] — タックスが吸っているパイプは、} JR「ボブ」ドブスの頭 のイメージに影響されています。

サブジーニアス教会へのユーモラスな言及は、セットアッププログラムのソフトウェアシリーズの終了を示すinstall.endテキストファイルの多くのバージョンで見つかります。Slackware リリース 14.1 を含む最近のバージョンでは、テキストはROT13で難読化されています。^{[17] [18]}

SlackwareはもともとSoftlanding Linux System (SLS) ^[19]から派生したもので、オリジナルのLinuxディストリビューションの中で最も人気があり、カーネルと基本ユーティリティだけでなく、X11グラフィカルインターフェイス、TCP/IP、UUCPネットワーク、GNU Emacs ^[20]を含む包括的なソフトウェアコレクションを提供した最初のディストリビューションでした。

Patrick Volkerding は、当時Moorhead State University (MSU)という名前だった大学の学校プロジェクトでLISPインタープリターが必要になったことをきっかけに、SLS を使い始めました。彼は、 CLISP がLinux で利用できることを知り、それを実行するために SLS をダウンロードしました。数週間後、Volkerding はMSU の人工知能の教授から、自宅と学校のコンピューターに Linux をインストールする方法を教えてほしいと頼まれました。Volkerding は、SLS のインストール後に見つかった問題の修正方法をメモに書き留めており、彼と教授はそれらの変更点を調べて新しいインストールに適用しました。しかし、これには SLS のインストールにかかった時間とほぼ同じ時間がかかったため、教授はインストール ディスクを調整してインストール中に修正を適用できるようにできないかと尋ねました。これが Slackware の始まりでした。Volkerding は、バグの修正、ソフトウェアのアップグレード、共有ライブラリとカーネル イメージの自動インストール、ファイル権限の修正など、SLS の改良を続けました。短期間で、Volkerding は SLS で利用できるパッケージの約半分をアップグレードしました。

Volkerding は、SLS の修正版を公開するつもりはありませんでした。MSU の友人たちは、SLS の修正内容を FTP サーバーに載せるよう勧めましたが、Volkerding は「SLS はすぐにこれらの機能を含む新しいバージョンを出すだろう」と考え、数週間待ちました。その間、インターネット上の多くの SLS ユーザーが SLS に新しいリリースを要求していたため、最終的に Volkerding は「SLS のような 0.99pl11A システムが欲しい人はいませんか?」というタイトルの投稿をしました。これに対して、多くの肯定的な反応が寄せられました。MSU のローカル システム管理者と話し合った後、Volkerding は Slackware を大学のFTPサーバーにアップロードする許可を得ました。^[15]この最初のSlackwareリリース、バージョン1.00は、1993年7月17日00:16:36 (UTC) ^[1]に配布され、24枚の3.5インチフロッピーディスクイメージとして提供されました。^[22]発表後、フォルカーディングはFTP接続の洪水でサーバーがクラッシュし続けるのを見守りました。その後すぐに、ウォルナットクリークCDROMがFTPサーバーに追加のアーカイブスペースを提供しました。^[15]

Slackwareのサイズは付属ソフトウェアの追加により急速に増大し、1994年10月にリリースされたバージョン2.1では3倍以上に膨れ上がり、144万のフロッピーディスクイメージが73枚含まれていた。^[23]

1999 年、Slackware のバージョンは 4 から 7 に上がりました。Slackware のバージョン番号は他のディストリビューションより遅れていたため、バンドルされているソフトウェアのバージョンが似ていても、多くのユーザーは Slackware が古いものだと考えていました。Volkerding は、マーケティングの一環としてバージョンを上げることを決定しました。これは、Slackware が他の Linux ディストリビューション (当時はリリース番号が 6 のものが多かった) と同じくらい最新であることを示すためです。彼は、他のほとんどのディストリビューションがすぐにこのリリース番号になると予測して、7 を選択しました。^[24]

2004 年 4 月、Patrick Volkerding は、現在使用されているXFree86パッケージの代わりにX.Org Serverパッケージを -current の testing/ ディレクトリに追加し、Slackware のX Window Systemの将来についてコメントを求めました。1 か月後、X.org リリースを X のデフォルト バージョンとして使用することに賛成する意見が 4 対 1 以上であったことを述べた後、彼は XFree86 から X.Org Server に切り替えました。彼は、XFree86 が互換性の問題を引き起こすことが判明していたため、この決定は主に技術的なものであると述べました。Slackware 10.0 は、X.Org Server を搭載した最初のリリースでした。^[25]

2005年3月、パトリック・フォルカーディングは開発ChangeLogでGNOMEデスクトップ環境の削除を発表した。彼は、これは4年以上検討されてきたこと、Slackware自体が提供しているものよりも完全なバージョンのGNOMEをSlackware向けに提供しているプロジェクトがすでにあることを述べた。フォルカーディングは、将来のGNOMEサポートはコミュニティに頼ることになると述べた。^[26]コミュニティはこれに反応し、2016年10月現在、Slackware向けのアクティブなGNOMEプロジェクトがいくつかある。これには、Cinnamon、Dlackware、Dropline GNOME、MATE、SlackMATEなどがある。多くのディストリビューションでGNOMEが普及しているため、Linuxコミュニティの一部ではこの削除が重要だとみなされた。^[27]

2009 年 5 月、Patrick Volkerding は、IA-32ディストリビューションと並行して保守される Slackware64 と呼ばれる公式の x86_64 バリアントの公開 (開発) リリースを発表しました。^[28] Slackware64 は、32 ビット プログラムの実行やコンパイルをサポートしていない点で純粋な 64 ビット ディストリビューションですが、「マルチライブラリ対応」として設計されています。Slackware チームのコア メンバーの 1 人である Eric Hameleers は、Slackware64 をマルチライブラリに変換して 32 ビット ソフトウェアを実行できるようにするために必要なパッケージを含むマルチライブラリ リポジトリを管理しています。^[29] Hameleers は、2008 年 9 月の手術からの回復の痛みから気を紛らわすために 64 ビット ポートを開始しました。Volkerding は 2008 年 12 月にポートをテストし、32 ビット バージョンと比較していくつかのベンチマークで 20 ～ 40 パーセントの速度向上を見て感銘を受けました。両バージョンを並行して維持するための余分な労力を最小限に抑えるために、SlackwareのビルドスクリプトであるSlackBuildsは、両方のバージョンで1つのソースセットを使用できるように、徐々にいずれかのアーキテクチャをサポートするように移行されました。^[30] Slackware64はバージョン13.0で最初の安定リリースを迎えました。

2013 年 11 月の 14.1 リリースから 2016 年 6 月まで、Slackware のリリース間隔は 31 か月に及び、これはリリース史上最長の期間となりました。この間、開発ブランチは 47 日間更新されませんでした。しかし、2015 年 4 月 21 日、Patrick Volkerding は ChangeLog で更新がなかったことを謝罪し、開発チームはその時間を利用して「良い仕事をした」と述べました。その ChangeLog エントリには、多くの主要なライブラリ アップグレードを含む 700 を超えるプログラム変更が記載されていました。2016 年 1 月、Volkerding は、BlueZ がv5.x で直接ALSAサポートを廃止し、他のさまざまなプロジェクトが BlueZ v4.x のサポートを廃止したことが主な理由で、PulseAudioの追加を渋々発表しました。一部のユーザーがこの変更に満足しないことを知っていた彼は、「バグ レポート、苦情、脅迫は私に送ってください」と述べました。これらの変更は、2016年6月にSlackware 14.2がリリースされたことで最高潮に達しました。^[31]

デビッド・カントレルは1999年から2001年までSlackwareチームの中核メンバーとして働いており、その期間についてSlackware ARM Vlogで説明している。^[32] パトリック・フォルカーディングは2回のインタビューでその期間についてさらに詳しい情報を提供している。^{[33] [34]}

Slackware の設計哲学は、シンプルさ、ソフトウェアの純粋さ、^[35]、および上流ソースを変更しないことを強調したコア設計に向けられています。Slackware の設計上の選択の多くは、従来の Unix システムのシンプルさの遺産であり、KISS 原則の例として見ることができます。^[36]この文脈では、「シンプル」とは、システムの使用法ではなく、システム設計のシンプルさを指します。したがって、使いやすさはユーザーによって異なります。コマンドラインインターフェイスと従来の Unix ツールの知識がないユーザーは、Slackware を使用すると習得が困難になる可能性がありますが、Unix のバックグラウンドを持つユーザーは、抽象度の低いシステム環境の恩恵を受ける可能性があります。^[要出典] Slackware の設計哲学と純粋さの精神に沿って、Slackware のほとんどのソフトウェアは、ソフトウェアの作者によって提供されたオリジナルの構成メカニズムを使用します。ただし、一部の管理タスクについては、ディストリビューション固有の構成ツールが提供されます。

正式な問題追跡システムはなく、コード貢献者や開発者になるための公式な手順もありません。プロジェクトは公開コードリポジトリを維持していません。バグ報告と貢献はプロジェクトにとって不可欠ですが、非公式な方法で管理されています。Slackware リリースに何を含めるかについての最終決定はすべて、Slackware の終身独裁者であるPatrick Volkerding が厳格に行います。^{[37] [38] [39]}

Slackware の最初のバージョンは Patrick Volkerding が一人で開発しました。バージョン 4.0 以降、Slackware の公式アナウンス ファイルには David Cantrell と Logan Johnson が「Slackware チーム」の一員として記載されています。^[40]その後のリリース バージョン 8.1 までのアナウンスには Chris Lumens が含まれています。^[41] Lumens、Johnson、Cantrell は、Slackware Linux の公式ガイドである「Slackware Linux Essentials」の初版の著者でもあります。^[42] Slackware の Web サイトでは、Chris Lumens と David Cantrell が「Slackware の卒業生」であり、「数年間 Slackware プロジェクトにフルタイムで取り組んできた」と記載されています。^[38] Volkerding は、Slackware 10.0 および 10.1 のリリース ノートで、Eric Hameleers に「USB、PCI、および Cardbus ワイヤレス カードのサポートに関する作業」に対して感謝の意を表しています。^{[43] [44]}バージョン12.0から、再びVolkerdingを中心としたチーム編成が始まりました。12.2のリリースノートによると、開発チームは7人で構成されています。将来のバージョンでは人員が追加されました。^[45]バージョン13.0以降、Slackwareチームにはコアメンバーがいるようです。Eric Hameleersは、2009年10月3日〜4日（バージョン13.0のリリース直後）に書かれた「Slackware開発の歴史」というエッセイで、コアチームについての洞察を提供しています。^[37]

Slackware のパッケージ管理システムは総称して pkgtools と呼ばれ、ローカルソースからのパッケージの管理 ( pkgtool )、インストール ( installpkg )、アップグレード ( upgradepkg )、削除 ( removepkg ) を行うことができます。また、パッケージの解凍 ( explodepkg ) や作成 ( makepkg ) も行えます。ネットワークやインターネット経由で Slackware をアップデートする公式ツールはslackpkgです。これはもともと Piter Punk によって、Slackware を最新に保つための非公式な方法として開発されました。Slackware 12.2 ではメインツリーに正式に含まれ、^[46] Slackware 9.1 以降ではextras/に含まれていました。 ^[47]パッケージがアップグレードされると、新しいパッケージが古いパッケージの上にインストールされ、新しいパッケージに存在しないファイルはすべて削除されます。slackpkg でパッケージをインストールしたら、pkgtoolやその他のパッケージ管理コマンドで管理できます。^[48] upgradepkgを実行すると、バージョン番号が異なることだけが確認され、必要に応じてパッケージをダウングレードすることができます。

Slackware パッケージは、さまざまな方法で圧縮されたtarballです。13.0 以降、ほとんどのパッケージはxz ( LZMA圧縮アルゴリズムに基づく) を使用して圧縮され、ファイル名拡張子は.txzになります。^{[49] 13.0 より前は、パッケージは}gzip ( DEFLATE圧縮アルゴリズムに基づく)を使用して圧縮され、拡張子は.tgzでした。bzip2およびlzip圧縮のサポートも追加され、ファイル名拡張子はそれぞれ.tbzおよび.tlzになりましたが、これらはあまり使用されていません。

パッケージには、そのプログラムのすべてのファイルと、パッケージ マネージャーが使用する追加のメタデータファイルが含まれています。パッケージの tarball には、ファイルの完全なディレクトリ構造が含まれており、インストール時にシステムのルート ディレクトリに抽出されるようになっています。tarball 内の特別なinstall/ディレクトリの下にある追加のメタデータ ファイルには、通常、slack-descファイルが含まれています。これは、パッケージ マネージャーによって読み取られ、パッケージ化されたソフトウェアの説明をユーザーに提供する、特別にフォーマットされたテキスト ファイルです。 ^[50]また、doinst.shファイルも含まれています。これは、シンボリックリンクの作成、起動ファイルのアクセス許可の保持、新しい構成ファイルの適切な処理、およびパッケージのディレクトリ構造を介して実装できないインストールのその他の側面を可能にする、解凍後のシェル スクリプトです。 ^[51] 15.0 の開発中に、Volkerding は、パッケージを削除またはアップグレードするときに起動できるdouninst.shアンインストール スクリプトのサポートを導入しました。^[52]これにより、パッケージのメンテナーは、パッケージがアンインストールされたときにコマンドを実行できます。

パッケージマネージャは、コンピュータ上の複数のフォルダに保存されたローカルデータベースを維持します。14.2 およびそれ以前のシステムでは、インストールされたパッケージのメインデータベースは/var/log/に維持されていましたが、15.0 の開発中に、Volkerding は、システムログを消去するときに誤って削除されるのを防ぐために、ディレクトリのうち 2 つを/var/lib/pkgtools/の下の専用の場所に移動しました。 ^[52] Slackware の各インストールには、メインデータベースの場所にpackages/およびscripts/ディレクトリが含まれます。前者には、インストールされた各パッケージに対応するインストールログファイル (パッケージ名、バージョン、アーキテクチャ、およびビルドに基づく) があり、パッケージサイズ (圧縮済みと非圧縮の両方)、ソフトウェアの説明、およびインストールされたすべてのファイルのフルパスが含まれます。^[53]パッケージにオプションのdoinst.shポストインストールスクリプトが含まれている場合、そのスクリプトの内容は、 packages/ディレクトリ内の対応するパッケージのファイル名と一致するscripts/ディレクトリ内のファイルに追加され、管理者は後でポストインストールスクリプトを表示できるようになります。パッケージが削除またはアップグレードされると、packages/およびscripts/の下にある古いインストール ログとスクリプトはremoved_pa​​ckages/およびremoved_scripts/に移動され、以前のパッケージを確認して、いつ削除されたかを確認できるようになります。これらのディレクトリは14.2 以前では/var/log/にありますが、 15.0 の開発中に/var/log/pkgtools/に移動されました。douninst.sh アンインストール スクリプトをサポートするシステムでは、パッケージがインストールされている間、これらのスクリプトは/var/lib/pkgtools/douninst.sh/ディレクトリに保存されます。削除されると、 douninst.shスクリプトは/var/log/pkgtools/removed_uninstall_scripts/に移動されます。

パッケージ管理システムは依存関係の追跡や管理は行いませんが、推奨されるフルインストールを実行すると、標準パッケージのすべての依存関係が満たされます。カスタムインストールまたはサードパーティのパッケージの場合、Slackware は、プログラムに必要なすべてのサポートシステムライブラリとプログラムがシステムにあることをユーザーが確認することに依存しています。標準パッケージの依存関係の公式リストは提供されていないため、ユーザーがカスタムインストールまたはサードパーティソフトウェアをインストールする場合は、不足している可能性のある依存関係を自分で解決する必要があります。パッケージマネージャーは依存関係を管理しないため、依存関係が満たされているかどうかに関係なく、すべてのパッケージがインストールされます。ユーザーは、ソフトウェアを使用しようとしたときに初めて、依存関係が不足していることに気付く場合があります。

Slackware 自体には依存関係を解決するための公式ツールは組み込まれていませんが、 DebianベースのディストリビューションのAPTやRed Hatベースのディストリビューションのyumと同様に、非公式のコミュニティサポートソフトウェアツールがこの機能を提供しています。

• slapt-get は、 APT と同様に機能するコマンド ライン ユーティリティです。slapt-get は依存関係解決のフレームワークを提供しますが、Slackware ディストリビューションに含まれるパッケージの依存関係解決は提供しません。ただし、いくつかのコミュニティ パッケージ ソースと Slackware ベースのディストリビューションは、この機能を活用しています。Gslapt は、slapt -get のグラフィカル インターフェイスです。
• Swaretは依存関係解決機能を備えたパッケージ管理ツールです。元々はSlackwareバージョン9.1にオプションパッケージとして含まれていましたが、当時は依存関係解決機能は含まれていませんでした。^[54] Slackware 10.0では配布から削除され、コミュニティに引き継がれました。最終的には依存関係解決機能とロールバック機能が追加されましたが、2014年5月現在、アクティブな開発者はいません。^[55]
• NetBSDのpkgsrc は、 Slackware をはじめとする Unix 系オペレーティング システムのサポートを提供します。pkgsrc は、バイナリ パッケージとソース パッケージの両方の依存関係の解決を提供します。^{[引用が必要]}

Slackware には公式リポジトリはありません。Slackware が提供する公式パッケージは、インストール メディアでのみ利用できます。ただし、Slackware にはサードパーティのリポジトリが多数あります。スタンドアロン リポジトリもあれば、Slackware ベースでありながら Slackware とのパッケージ互換性を維持しているディストリビューション用のリポジトリもあります。これらの多くは、Linux パッケージ検索エンジンである pkgs.org を使用して一度に検索できます。ただし、複数のリポジトリからの依存関係を混在させて一致させると、同じ依存関係の異なるバージョンを必要とする 2 つ以上のパッケージが生成される可能性があります。これは、依存関係地獄の一種です。Slackware 自体はこれらのパッケージの依存関係の解決を提供しませんが、一部のプロジェクトでは、パッケージのファイル (通常は.dep拡張子) とともに、Slackware に含まれていない依存関係のリストを提供します。

依存関係の問題が発生する可能性があるため、多くのユーザーはコミュニティが提供する SlackBuilds を使用して独自のプログラムをコンパイルすることを選択します。SlackBuilds は、提供されたソフトウェア tarball からインストール可能な Slackware パッケージを作成するシェル スクリプトです。SlackBuilds はスクリプトであるため、プログラムのソースをコンパイルするだけではありません。プロジェクトや他のディストリビューションのリポジトリによって提供されるコンパイル済みのバイナリを適切な Slackware パッケージに再パッケージ化するためにも使用できます。ソースをコンパイルする SlackBuilds には、ビルド済みのパッケージに比べていくつかの利点があります。元の作者のソース コードからビルドするため、ユーザーはサードパーティのパッケージ作成者を信頼する必要がありません。さらに、ローカル コンパイル プロセスにより、マシン固有の最適化が可能になります。ソフトウェアを手動でコンパイルしてインストールする場合と比較して、SlackBuilds は Slackware のパッケージ マネージャーを使用することで、システムへのよりクリーンな統合を提供します。一部のSlackBuildsには、メタデータを含む追加ファイルが付属しており、自動化ツールがソースをダウンロードし、ソースが破損していないことを確認し、Slackwareの一部ではない追加の依存関係を計算できるようにします。^[56]一部のリポジトリには、SlackBuildsとその結果のSlackwareパッケージの両方が含まれており、ユーザーは独自のパッケージを構築するか、事前に構築されたパッケージをインストールすることができます。

唯一公式に承認されている^[57] SlackBuilds リポジトリは SlackBuilds.org で、一般に SBo と呼ばれています。これはコミュニティ支援プロジェクトで、Slackware に含まれていないソフトウェアをビルドするための SlackBuilds を提供しています。ユーザーはソフトウェアの新しい SlackBuild をこのサイトに送信でき、承認されると「パッケージ メンテナー」になります。その後、ユーザーは SlackBuild に更新を提供して問題を修正するか、アップストリームから提供される新しいバージョンをビルドする責任を負います。すべてのプログラムがコンパイルおよび使用できるように、Slackware に含まれていないソフトウェアの必要な依存関係はすべて文書化され、サイトで利用できるようにする必要があります。すべての送信は、リポジトリに追加される前にサイトの管理者によってテストされます。管理者は、主に Volkerding が「私たちの目的に共感している」ことを確認するために、ビルド プロセスを Slackware の公式パッケージのビルド方法とほぼ同じにすることを意図しています。これにより、Volkerdingが価値があると判断したSlackBuildsは、スクリプトを最小限に変更するだけで通常のSlackwareに取り込むことができます。また、ユーザーがVolkerdingにスクリプトをSBoのスクリプトに合わせて変更するよう提案することも防止できます。 ^{[58] SBoはSlackBuildsと追加のメタデータファイルのテンプレート[59]}を提供し、パッケージのメンテナーに必要がない限り逸脱しないように奨励しています。^[60]

Slackware チームメンバーの Eric Hameleers と Robby Workman はそれぞれ、コンパイル済みパッケージのリポジトリと、パッケージの作成に使用した SlackBuilds およびソースファイルを持っています。ほとんどのパッケージは Slackware に含まれていない追加ソフトウェアであり、メンテナンスに時間をかける価値があると感じたものですが、一部のパッケージは Slackware の将来のアップグレードのテストベッドとして使用され、最も有名なのは Hameleers がKDEの新しいバージョンに「Ktown」パッケージを提供していることです。^[61]彼はまた、Slackware の「multilib」リポジトリを管理し、Slackware64 が 32 ビットパッケージを実行およびコンパイルできるようにしています。^[29]

Slackware のリリース ポリシーは、他の Linux ディストリビューションの期限付きリリース (Ubuntu など) やローリング リリース (Gentoo Linux など) スキームとは対照的に、機能と安定性に基づいたリリース サイクルに従います。つまり、リリースの予定時刻は決まっていません。Volkerding は、前のバージョンから適切な数の変更が行われ、それらの変更によって環境が安定すると判断した後、次のバージョンをリリースします。Patrick Volkerding は次のように述べています。「通常、リリース日については推測しないのが私たちのポリシーです。それは、推測にすぎないからです。必要なアップグレードを行い、関連する未解決の問題をすべて解決するのにどのくらいの時間がかかるか、常にわかるとは限りません。次のリリースに向けて構築されたものは、-current ツリーにアップロードされます。」^[62]

Slackware はこれまでの歴史を通じて、少なくとも毎年最新のソフトウェアを提供するよう努めてきました。^[37]創業以来 2014 年まで、Slackware は少なくとも年に 1 回のリリースを行っていました。リリース活動は 1994 年、1995 年、1997 年、1999 年にピークを迎え、毎年 3 回のリリースがありました。バージョン 7.1 (2000 年 6 月 22 日) 以降、リリースの進行はより安定し、通常は年に 1 回行われるようになりました。それ以降、2 回のリリースがあったのは 2003 年、2005 年、2008 年の 3 年のみでした。しかし、2013 年の Slackware 14.1 のリリース以降、新しいリリースは大幅に減速しました。14.1 と 14.2 の間には 2 年以上、15.0 との間には 5 年以上もギャップがありました。^[52] 15.0のリリース時に、Volkerdingは、15.0の開発中に「難しい部分」が解決されたため、Slackware 15.1の開発サイクルははるかに短くなるだろうと述べました。^[63]

Slackwareの最新の32ビットx86および64ビットx86_64安定リリースはバージョン15.0（2022年2月2日リリース）であり、Linux 5.15.19のサポートが含まれています。^[64]

Volkerding は、より最先端の構成に使用できる「-current」と呼ばれる Slackware のテスト/開発バージョンも維持しています^[65]。このバージョンは最終的に次の安定リリースになり、その時点で Volkerding は新しい -current を開始して、Slackware の次のリリースの開発を開始します。このバージョンは一般的に安定していることが知られていますが、問題が発生する可能性があるため、-current は実稼働システムには推奨されません。^[66]

現在、Slackware には公式に定められたサポート期間ポリシーはありません。しかし、2012 年 6 月 14 日にバージョン 8.1、^[107] 9.0、9.1、10.0、10.1、10.2、11.0、および 12.0 の変更ログに、2012 年 8 月 1 日をもってこれらのバージョンに対するセキュリティ パッチの提供を終了する旨の通知が掲載されました。最も古いリリースであるバージョン 8.1 は、2002 年 6 月 18 日にリリースされ、EOL に達するまで 10 年以上サポートされていました。その後、2013 年 8 月 30 日に、12.1 ^[108]および 12.2の変更ログで、2013 年 12 月 9 日に EOL になるとのアナウンスがなされました。変更ログのエントリには、少なくとも 5 年間のサポートがあると記載されていました。 2018年4月6日、バージョン13.0、13.1、13.37 ^[109]が2018年7月5日にEOLに達すると宣言されました。変更ログエントリには、少なくとも7年間のサポートがあると記載されていました（13.0はほぼ9年間サポートされていました）。2023年10月9日、14.2の変更ログには、14.0、14.1、14.2は2024年1月1日をもってEOLになると記載されていました。^[110]

8.1 より前のバージョンについては公式発表はありませんが、メンテナンスされなくなり、事実上 EOL となっています。

歴史的に、Slackware は IA-32 アーキテクチャのみに集中しており、リリースは 32 ビットのみで利用可能でした。しかし、Slackware 13.0 以降では、64 ビットの x86_64 バリアントが利用可能になり、32 ビット プラットフォームとの対称開発で公式にサポートされています。Slackware64 がリリースされる前は、64 ビットを希望するユーザーは、slamd64 などの非公式ポートを使用する必要がありました。

Slackware は、IBM S/390アーキテクチャ用の Slack/390 や、ARM アーキテクチャ用の Slackware ARM (元々は「ARMedslack」として知られていた) も利用可能である。どちらの移植も Patrick Volkerding によって「公式」と宣言されている。^{[111] [112]}しかし、S/390 移植版は、安定版ではバージョン 10.0、テスト/開発版ではバージョン 11.0 のままであり、2009 年以降更新されていない。^{[113] [114]}また、2016 年 5 月 7 日、Slackware ARM の開発者は、14.1 は 2016 年 9 月 1 日に EOL となり、-current の開発は 14.2 のリリースで終了するが、14.2 のサポートは当面維持されると発表した。^[115] 14.1のEOLアナウンスは2016年6月25日に変更ログに追加されました。^[116] 14.2のEOLアナウンスは2022年12月21日に変更ログに追加されました。^[117]

2016年7月、Slackware ARMの開発者は、ARMポートのメンテナンスに伴う手作業を減らすために開発およびビルドツールが強化されたことを発表し、32ビットハードウェアフローティングポートが開発中であることを発表しました。このポートは2016年8月に「現在の」形式でリリースされました。^[118]

2020 年 12 月 28 日に、Slackware を 64 ビット ARM アーキテクチャ (「AArch64」として知られています) に移植する作業が開始され、最初のハードウェア モデル ターゲットは PINE64 の RockPro64 と Pinebook Pro でした。2021 年 5 月までに機能的に完了し、ARM ポートの元の設計と実装に比べて多くの改善が行われました。特に、Slackware ARM コミュニティによる新しいハードウェア モデルの管理と有効化に関して改善が見られました。さらに、起動とインストールのプロセスが大幅に改善され、インストール プロセスがはるかに簡単かつ合理化されました。

2022年3月29日、Slackware AArch64は、RockPro64、Pinebook Pro、Raspberry Pi 3および4をサポートし、オンラインインストールドキュメントとビデオインストールガイドを備えた-current（開発）形式で公開されました。また、非公式のslarm64プロジェクト^{[119]には、AArch64用のポートと、} riscv64アーキテクチャ 用の追加ポートがあります。

2022年3月、SlackwareのARM 32ビットポートの公式開発は終了し、今後の開発はAArch64/ARM64ポートのみに集中することになった。これは、32ビットハードウェアがSlackwareの開発に追いつけず開発を妨げていたことと、ハードウェアの制限が最新技術の採用の妨げになっていたためである。さらに、他の主流のディストリビューションのほとんどが32ビットARMのサポートを終了したため、一部のアプリケーションはビルドに失敗し、サポートできなくなった。ただし、非公式のSlackwareポートであるBonSlack ^[120]は、32ビットARM用のソフトポート（ARMv5）とハードフロートポート（ARMv7）の両方を提供しており、開発とアップデート（14.2以降）は公式Slackwareに合わせて行われている。このプロジェクトは、Aarch64 (ARM64)、Alpha、HPPA (PA-RISC 1.1)、LoongArch (64 ビット)、MIPS (32/64 ビット)、OpenRISC、PowerPC (32/64 ビット)、RISC-V (64 ビット)、S/390x、SH-4、SPARC (32/64 ビット)、x86 (64 ビット time_t 付き 32 ビット) アーキテクチャ用のポートも提供します。

2022 年 12 月 21 日に、Slackware ARM 14.2 の EOL (サポート終了) が 2023 年 3 月 1 日に宣言されました。

Slackintoshは、1994年から2006年までAppleのPower Macintosh、PowerBook、iMac、iBook、Xserveシリーズで使用されていたMacintosh New World ROM PowerPCアーキテクチャ用のSlackware Linuxの移植版です。Slackintoshの最新バージョンは2008年6月7日にリリースされた12.1です。 ^[121] Slackintoshのウェブサイトは現在もアクティブで、バージョン12.1はダウンロード可能です。 ^[122]古いPowerPC Macintoshコンピューターをお持ちの方はご利用可能です。プロジェクトの開発者は2012年2月に開発が凍結され、12.1は1か月間セキュリティパッチを受け取ることができると発表しました。^[123] 翌月、安定版リリースが凍結され、誰かが引き継ぐことを決定しない限り、これ以上のアップデートは受け取れないと発表されました。^[124] これは実現せず、Volkerdingは2021年7月に正式にプロジェクトの終了を宣言しました。 ^[52]

Slackware 14.2 ^[125] CDセット、DVDシングル、および商品はサードパーティが管理するSlackwareストアから入手可能であったが、^[126]支払い不足のため、Patrick Volkerdingは「ストアを閉鎖するか、ストアのDNSを停止するかを告げた」。^{[127] [128] [129] [130] [131] [132] [133]}

インストール用のSlackware ISOイメージ（2.6 GB）^[134]は、 BitTorrent、FTPミラー、HTTPミラー経由でSlackwareのWebサイトから無料でダウンロードできます。 ^[135]

IBM S/390用のSlackwareポート（EOL：2009）^[136]をダウンロードして、DOSパーティションまたはフロッピーディスクからインストールすることができます。^[137]

^{ARM [138]} アーキテクチャ用のSlackwareポートは、Das U-BootとTFTPブートサーバー^[140]またはミニルートファイルシステム [141] を使用してネットワーク経由でダウンロードしてインストールする^{ことができます。 [139]}

Slackware ARMは、同じ手法を使用してQEMU ^[142]を実行しているPCにもインストールできます。 ^[143]

Slackware AArch64 (ARM64) は、DVD から Slackware x86 をインストールするのと同様の方法で、SD カード イメージから直接インストールされます。

• 公式サイト
• DistroWatchの Slackware