逆襲のSlackware

SlackwareでのErlangのパッケージ作成について、28.4.1にアップグレードしました。 slackware.jp/packages/erlan…

@wainohito @jima0111 rsyncで落として、ISOにされると良いかと思います。 slackware.jp/techinfo/rsync…

@slackwarejp @jima0111 32bit版はcurrentのISOが無くて悲しみ(´･ω･`) やっぱ15のISOからアップデートするしかないか。

今試しているLinux一覧。 32bit向けマジ選択肢がねぇw Gentooは流石に荷が重いわ…

A single mismanaged repository can block security updates across your entire system. In Linux-based production environments, even a single third-party repository with inconsistent dependency management can cause `dnf update` to fail. The impact, however, extends far beyond that specific package. Because package managers evaluate dependency resolution as a single transaction, one unresolved dependency can block the entire update process — including critical OS-level security updates. More critically, it disrupts the ability to apply security updates in a timely and controlled manner — a foundational requirement in any secure operating environment. This issue often arises when repositories are treated as mutable distributions rather than controlled, versioned artifacts. As a result, it leads to: - Delayed application of security patches - Increased exposure to known vulnerabilities - Erosion of confidence in system maintainability and operational predictability It also undermines reproducibility, making it difficult to reliably rebuild or recover environments over time. From an operational and governance perspective, this introduces a systemic operational and security risk. A poorly managed repository does not just affect its own software — it can effectively impact the security posture of the entire system. By design, if a repository provides software that is responsible for system stability and availability, the consequences should be even more significant. This is why repository governance should be treated as part of overall security and risk management, not merely as a packaging concern. In practice, mature environments implement controls such as: - Isolating or prioritizing repositories - Mirroring and validating packages internally - Establishing controlled update pipelines and staging environments Repository reliability is not just a technical detail — it is a reflection of operational discipline and software lifecycle maturity. How is your organization ensuring that third-party repositories cannot compromise your update and security posture?

@wainohito @jima0111 currentもstableも、双方ともに、きちんと更新は続いています。 slackware.com/changelog/curr… slackware.com/changelog/stab…

@jima0111 2022で更新が止まってるだけやん(´･ω･`)

liquidctlを使い、液冷クーラー・デバイスをSlackware上でコントロール。 ファンの回転数などを適切に設定することで、静音環境にしましょう。 slackware.jp/packages/liqui…

@mb7O1AtbW715890 こちらに高速ミラーサイトを用意してあります。 slackware.jp

Slackwareの公式パッケージ更新、基本の4ステップ sudo slackpkg update sudo slackpkg install-new sudo slackpkg upgrade-all sudo slackpkg clean-system 依存関係を自分で管理するSlackwareだからこそ、install-new を飛ばさないのが安定運用の秘訣。 #Slackware #Linux

Sublime Text Build 4199にアップグレードしました。 slackware.jp/packages/subli…

Microsoft Edge 144.0.3719.92にアップグレードしました。rpmからdebを使ったパッケージ作成方法に変更しました。 slackware.jp/packages/edge.…

Wine 11.1にアップグレードしました。 slackware.jp/packages/wine.…

SlackwareでCommon Lisp環境を構築するなら、SBCL（Steel Bank Common Lisp）パッケージが実用的な選択肢です。高いコンパイル性能とANSI準拠の信頼性は、堅牢なシステム開発の基盤となります。ビルド管理の手間を省き、即座にREPLへ。強力な処理系です。 slackware.jp/packages/sbcl.…

SlackwareでTailscaleが利用可能。堅牢なOSと現代的なセキュア接続基盤の融合は、インフラ管理の柔軟性を劇的に高めます。複雑なVPN構築から解放され、セキュアな相互接続を即座に確立。保守的なシステムこそ、ネットワーク足回りは最新技術で効率化すべきです。 #Slackware slackware.jp/packages/tails…

Wineのビルドオプションを-O3から-O2に変更したところ、SteamのDL中断問題が解決。過度な最適化が通信処理等に副作用を及ぼす実例です。「動かない高速化」より「確実な安定性」を。コンパイラオプションの選定は、ベンチマークだけでなく実挙動での判断が必要です。 slackware.jp/packages/wine.…

「FreeBSD」と「Slackware」--硬派な上級者向けOSの決定的な違い japan.zdnet.com/article/352423…

@ToukaShiro_NW LAMPとして使ってる分には、めっちゃ楽です。 どのあたりで苦労されているのですか？

サーバでslackwareなんて使うものは無いよ...jumphost位ならまだ行けるけど実運用にはかなりくせが強すぎて辛いよ!!

@mito70950481 オリジンのミラーサーバとのrsync同期中によるエラーかと思うので、もうしばらく時間をおいてみて下さい。

mirror.slackware.jp/slackware/slac… からslackpkg -batch=on -default_answer=y upgrade-allすると One or more errors occurred while slackpkg was running: poppler-25.09.0-x86_64-1.txz: md5sum になるな... #slackware

遂にinitrdが終焉を迎えるのか。 Slackwareも、initramfsへ移行しないといけない。 phoronix.com/news/Initrd-Li…

Such a peaceful life. 😊

本当です。 slackware.com/changelog/curr…

testingにカーネルの6.16.0が入りましたね。 Linus Torvalds氏は「穏やかで問題の少ないリリースだった」とコメントしており、安定志向のアップデートですが、内部では着実な機能追加や将来に向けた基盤整備が進められています。 【Rust言語統合の進展】 ドライバーコアやPCIデバイスサブシステム向けRustバインディング追加など、カーネル内でのRustサポートが強化されました。これにより、Rust製ドライバーやカーネルモジュールの開発・保守がより容易になります。 【ファイルシステムの高速化・強化】 - XFS 大規模なアトミック書き込みがサポートされ、データ整合性や書き込みエラー防止が向上しました。大規模ストレージやデータベース用途での信頼性がアップしています。 - Ext4 コミットパスの高速化、大きなフォリオ（ページ単位管理）のサポート、bigallocでのマルチブロックアトミック書き込みなど、多くの性能・信頼性向上が施されています。順次I/Oワークロードで約37％の速度向上効果が確認されています。 【セキュリティ・機密メモリー管理の強化】 Intel Trusted Execution Technology（TXT）、Trusted Domain Extensions（TDX）のサポート追加。 AMD Secure Encrypted Virtualization/Memory Encryption（SEV-SNP）への対応強化。 これにより、物理・仮想環境での機密コンピューティングが実現し、仮にクラウド環境が侵害されてもユーザーデータの保護が期待できます。 【プロセッサ・ハードウェア対応の進化】 Intel Advanced Performance Extensions（APX）にカーネルが対応（32本のx86レジスター利用可）。新世代CPU（Lunar Lake/Granite Rapids等）での性能向上に寄与します。 新たな「CONFIG_X86_NATIVE_CPU」オプションの導入により、ユーザーや開発者が自分のCPUに最適化したカーネルビルドが可能となります。 NVIDIA Blackwell/Hopper GPUやIntel Wildcat Lake向け新世代GPU/CPUのサポート強化。 【ネットワーク・IOの最適化】 DMA-BUFからTCPペイロードをゼロコピーで送信可能となり、GPU・AIアクセラレーター等による高速ネットワーク処理がCPU負荷なく可能になりました。 OpenVPNのネイティブネットワークプロトコルも改善され、WireGuardとの差が縮まっています。 【そのほかの注目点】 オーディオデバイスにおいて、USBオフロード機能が追加され、PC本体がスリープ中でもオーディオストリーミングが継続可能。 AF_UNIX ソケット経由でのコアダンプ送信にも対応し、運用時の可用性や保守性が向上。