TL;DR
这些事情会发生:
- 下游企业 Linux 必须改变获取源码的方式
- RHEL 的 1:1复制因为 RHEL 源码的限制而变得困难
这些事情不太可能发生:
- 红帽不按照许可协议向用户提供其产品源码
- EPEL 受到源码获取限制的直接影响
这些事情会发生:
这些事情不太可能发生:
OCI 镜像就是 Docker 和 Podman 用的镜像。首先是用法:
podman run -it --arch riscv64 docker.io/imbearchild/fedora-rv64
该镜像内置中科院软件研究所 PLCT 的 Riscv64 软件源,而不是 Fedora 官方源,因为 Fedora 官方源没有 Riscv64 支持。为了易于使用,镜像本身会尽量与 Fedora 官方镜像的内容保持相似性。
继续阅读“Fedora Riscv64 OCI 镜像”有时候会看到这种言论:GPL 太邪恶了,一旦你用了 GPL 许可协议下的源码,你自己的修改就必须是 GPL 开源的。不像 BSD 或者 MIT —— 你可以随意修改代码,而且随意使用 —— 这才是真正的自由。
我觉得这就是 BSD 目前的生态不及 Linux 的原因之一 —— 得不到保障的自由终究是有限的。
GPL 给用户全部的自由,除了从此以后没有放弃自由的自由。而 BSD 给了用户全部的自由,就是不保障以后如何。BSD 协议正是 BSD 生态的阿喀琉斯之踵。还有,请读者不要误解,本文仅仅是谈许可协议带来的不同,不是谈操作系统设计哪个更好的。
继续阅读“BSD 与 GPL:圣人与常人”我最近拜读了“清华牛仔”王垠的两篇文章,一篇是他的成名作的成名作《完全用Linux工作》,另一篇则是他的《谈 Linux,Windows 和 Mac》。我读毕后的感想是:“‘清华牛仔’在写这两篇文章的时候是不是溜大了?”
继续阅读“谈“清华牛仔”的“皈依者狂热””Fedora 项目最近打算更改编译选项,给几乎所有程序在加上帧指针(Frame Pointer)。我个人反对这一提案,不过当我知道这个提案的时候,这个提案已经通过了。我写这篇文章是为了让社区的朋友们理解 Fedora 作出这一决定的理由,并告诉读者为什么我不赞成这一提案。
继续阅读“Fedora 38 的帧指针”最近,我给我自己找到了许多理由在虚拟机内跑开发环境。
继续阅读“Alpine Linux 使用 VSCode 远程开发”有许多用户会把 Fedora Kinoite/Sliverblue 和 openSUSE MicroOS Desktop 比较。这两个发行版有许多共同的特征——其中最显著的就是他们都是不可变的 Linux 发行版。
继续阅读“卧龙凤雏:Fedora Kinoite 与 openSUSE MicroOS”维基百科是这样介绍 MicroOS 的:
继续阅读“MicroOS 与 Wayland 尝鲜记录”MicroOS是一个极简、自我维护且事务性的系统,专为边缘计算与容器运行时设计,但也能作其他用途,比如桌面系统。
著名 Fedora 用户,Manjaro 的伟大劝导者,V2RayA 的幕后大老板,让 Arch 吧吧主赞不绝口的天才少年,竹林里有冰,在8月16日中国上海的新型冠状肺炎疫情中,为了完全探索自己的大脑,装上了 Arch,今年18岁。
继续阅读“一位巨人的离开”戴高乐说过一句名言:“管理一个生产365种奶酪的国家真是难上加难”,那要搞清楚有超过300个发行版的 Linux 则是难上加难的平方。而我,就是要告诉你他们难在哪里。
继续阅读“Linux 发行版劝退指南”