刚才试了一下debian，发现太麻烦了

Jockey

对比代码行毫无意义，Slackware部分你只要知道installpkg、slack-desc和doinst.sh
Debian那得知道dpkg{-deb}、control、p{re,ost}inst、p{re,ost}rm、conffiles...起码，概念多了去了。你觉得作者编写该shell脚本时，若都是从0开始，逐步摸索，哪个模块是最快掌握的？Slackware的还是Debian的？

AutoXBC

deb 难打原话里有没有，checkinstall 实现的复杂度原话里有没有。嘴硬如此，就算我指出 debian 的抽象是用户需求的完备描述且并无冗余，看起来也毫无意义。可以预见的，后面有个 slackware 理念更简洁在等着我。K.I.S.S 是个万用筐，你装你的，我装我的。

Jockey

LS很激动啊，是不是觉得我说Debian复杂就是在批评Debian，非黑即白吗？

BTW. 复杂也不是冗余啊，e.g. Algol 68正交吗？正交；复杂吗？复杂。别串概念啊...

AutoXBC

加减乘除复杂么？这里有四种运算，对应运算律就更多了。完全可以用加减定义出二则运算，因为乘除是对多次加减的抽象；而在更大的域上，减运算是对负数加法的抽象。那么是否应该变四为一，因为这样更简单，答案是否定的，随着数学从初等变成高等，抽象的概念变得更多了，运算规则也更难理解。

当一种需求真实存在时，抽象不是复杂化，相反，是一种简化操作，为了使四则变成二则，就必须忍受连续一百次的加法，这并不简单。p{re,ost}inst、p{re,ost}rm、conffiles 每一个配置文件都对应了一个真实存在的需求。conffiles 无非是处理配置文件覆盖问题，这个需求 slackware 拒绝抽象，结果就是 doinst.sh 中必须包含 config() 函数，因为需求的真实存在是不能通过声明简洁就真的可以简化掉的。

类似的 p{re,ost}inst、p{re,ost}rm 对应了安装删除操作的之前和之后四个时刻需要执行的脚本。而 slackware 只处理 post-install 这个动作，其余的需求就可以无视么？

我之前也读过 arch 的包配置说明，debian 里的概念都有对应，只不过没有像 debian 一样通过几部完备的手册详细说明。结果就是 AUR 里的包良莠不齐，其品质甚至不如 ubuntu 的 ppa。捎带的，arch 论坛的怪问题也是最多的，arch wiki 也要不停修改。拒绝抽象，拒绝规范化的结果就是需要不停处理具象的故障。

另外，我比较不爽的是一个问题被我回答了你就开始回避它，然后转移到一个新问题，比较没意思。

Jockey

你太激动了，先冷静一下吧...这时候你说话一般不是自己...
我在这边觉得APT复杂，希望你在那边不要觉得自己被冒犯了，这个因果关系是很奇怪的。

BTW. 那个问题我没回避，只是没必要提及，它仅是我所说的一个方面，无关痛痒。
BTW-2. AUR上的PKGBUILD一般下载后我会自己编辑，轻松简洁得坑爹般，改到我觉得优美为止，我不清楚PPA是否能这么轻松优美地让我定制？

iMouse

gentoo在旁观，灌水

Jockey

LS不用旁观，src distro是另外的阵营，别胡乱扯进来。

Havanna

两人明显站的角度不同
一个站在最终用户角度，一个站在打包者角度
在打包者角度来说，debian的复杂度显然大于arch & SLK
而站在最终用户角度来说，大都均是主观意识的判断。

总的来说，随着学习曲线坡度减少，判断随之改变

wangjunhuashuo

Post by Havanna;2145606
两人明显站的角度不同
一个站在最终用户角度，一个站在打包者角度
在打包者角度来说，debian的复杂度显然大于arch & SLK
而站在最终用户角度来说，大都均是主观意识的判断。

总的来说，随着学习曲线坡度减少，判断随之改变

说到底LINUX只是少数人用的东西，其实我倒没资格在这里说的，它不易用，发行版太多自然产生诛多的冲突，各个发行版思想的不同，还是不要放一起比的好。罗卜青菜各有所爱吧！

木人

debian 的确是好系统 。 slackware 光盘发行方式 更是 懒人的最佳选择。
他们都是 "方便" 的，只是 各自有各自的方便。

我对debian 最不理解的是他所谓的依赖。 某个包虽然有新版本。可一但源里更新了。
我就很难继续让老版本待下去了。
比如。 系统 一直好好的。 喜欢用 mysql 4.1 可一旦5.0被加入源。 就需要更新它。
如果不更新， 其他好多包更新就会受到阻止。