跟现在所有的M开发者探讨一个问题

llc

哇！怎么搞得这么严重！
可惜我现在上网条件不太行，否则可以再为ML出点力。

樱家冢

[quote:4032920e6d="paulin"][quote:4032920e6d="樱家冢"]paulin, 严重警告，本版版主在吗？麻烦删除一下paulin的帖子。[/quote]
我那天还就闲着没事一次一次点，回头想起来的时候又发了几次，我在想啊，我就不信今天还不给我发了，功夫不负有心人，终于全部成功撒～



BTW：我真使吃饱了撑着，要使落在你手里啊，死的不知道多惨哦，还是 KanKan深明大意。[/quote]
嘿嘿，小样，不要让我抓到你。

watercloud

[quote:4ceb781192="gnuisv"]不觉得Magic Linux有“脱离现实"的倾向吗？
包括自己在内，对KDE体系没兴趣，对magic控制过紧的“中文桌面解决方案”束手无策。

1、实际上Linux用户的分化很大(这是Linux弹性决定的)，针对桌面用户而言：有些人喜欢完整、好用的桌面环境，例如目前Magic主打的KDE；有些人喜欢gnome(可能更认同其系统架构)，有些人也许更喜欢fluxbox一类的简洁桌面(这些人反而开的应用更多)。对于中文而言，有的人喜欢中文界面，有的人喜欢英文，仅仅要求中文支持而已，也许有的则需求繁体中文、韩文、日文等的支持(用在工作中)。Magic似乎控制过死，定位很狭窄，更换模块的弹性不足。

2、对于应用软件，实际上很多重要的软件，都不是基于QT/GTK的，对于这些软件的中文支持，也许是专业工作者更为关注的，例如：emacs/vim/tetex/math/...

3、对于Magic Linux的目标用户，对于一般的Linux系统，其目标用户实际上也是Linux的开发者，这一点很重要，是Linux发展的基础，Magic Linux也应该如此，大家使用Magic，促进工作，在工作中完善Magic，新版的Magic Linux应该更适合现实的magic用户的工作(例如：简单的samba、打印、pdf幻灯制作、必要的wine支持等)。并不是目前的一种追求完美的(也是空洞的)中文支持，完善的中文桌面，现在的Linux体系还做不到，或者是没有必要做到，脱离大家的需求，肯定应者寥寥。为一个虚无的中文完美境界，这个目标实际上是不存在的(例如支持新版的GB18030-2000，就够晕死的)。

4、现在看来Magic开发者似乎更乐意倾听所谓”评论者“的不着边际看法，却忽略真实(潜在)用户的意见。但是实际上应该正好相反的。几个不知道哪儿的人说了几句稀里糊涂的话，就又是关站点，又是变革的。却对于事实上的用户视而不见，也没看到无效率的团队架构做出什么强力的改进。如果一句普通magic用户的报怨，整个团队就极为关注，做出类似大规模的调整，相信magic就是另外一个样子了。

希望Magic Linux依托真正的开发者，真实的用户，踏踏实实的走好。[/quote]


就是我想说的，忍了很久没说的话被你说出来了.
//hand

中文支持的好的os是基础，这个基础架的逐渐牢固后逐渐发展应用应该是比较好的策略，而不是丢掉自己的基础。

还有，一直感觉cjacker此人太内向，但没想到如此极端和不理智。(个人看法)

lanche

应该继续呀，为了革命，头断血流也无怨无悔！

zy_sunshine

jiangtao的提议不错o

做一个rebuild网站管理系统，和后台服务器相配合的一个自动编译rpm的系统。这样起码会减少包维护人员的工作。

看到当年的讨论情景，我也有些热血了。

最近在考虑Magic的几个服务器软件的整体运行框架，虽然不太成熟，但是了胜于无。

haulm

还有，一直感觉cjacker此人太内向，但没想到如此极端和不理智。(个人看法)

cjacker 是个传说，magic 却是一个现实，不指望传说能带来现实，而用现实去理解传说。

haulm

原帖由 zy_sunshine 于 2010-3-1 12:45 发表
jiangtao的提议不错o

做一个rebuild网站管理系统，和后台服务器相配合的一个自动编译rpm的系统。这样起码会减少包维护人员的工作。

看到当年的讨论情景，我也有些热血了。

最近在考虑Magic的几个服务器软件的整体运行 ...

自动编译的rpm系统是永远不可能实现的，这是因为基于源码的编译与兼容是非常复杂多变的，但是合理的人力组织却是可以实现的。把时间浪费在自动编译系统，还不如多想想如何组织和推广技术的后备力量。

zy_sunshine

这个是可以实现的，见http://www.linuxfans.org/bbs/thread-191340-1-2.html
这个系统需要社区人员提供src.rpm包的下载地址，服务器自动下载编译并放入仓库中。这样可以给社区人员提供上传包接口，而且可以增加Magic的包数量和更新速度。
如果服务器编译失败，编译者可以根据自动编译系统返回的信息进行调整，或者给予依赖包，或者调整spec

zy_sunshine

当然 "组织和推广技术的后备力量" 是重中之重。而且前阵子我给sejishikong提了一些意见，一会我给你发一封邮件吧。你看看成不成。

zy_sunshine

对于自动编译系统
社区用户提供的编译包不包含系统核心包，系统核心包还是要开发者自己来做，他们只提供上层应用程序包，主要是加大Magic仓库的包种类，使Magic更适用于日常工作。比如前几天大家讨论的音频编辑器。

这些社区提供的包为第三方包，对于官方源是不被完全信任的。当用户好评度达到一定级别就可以纳入Magic可信任包。

zy_sunshine

我看到社区中很多人都在说 Magiclinux Build System ，而我提出的这个Auto Build System构想和他这个是不一样的。

自动构建MagicLinux系统核心包是不可能实现的，而且实现价值不大。也就ALFS这帮人才来做这些工作。

whistler_wmz

原来是坟。

debian 那边都是 build daemon 上传源代码包后自动 build

zy_sunshine

嗯，上传srpm也是可以的，但是如果源码包太大，不如用户提供一个下载srpm地址，编译服务器来下载来的快，而且可以断点续传。

haulm

那个MGB编译系统也不是不可能实现，可是目前我们连MGC是如何一条线编译下来的档案都没有。
比如LFS，只有编译过程都能文字描述出来后，才有MGB的可能。

[ 本帖最后由 haulm 于 2010-7-4 08:30 编辑 ]

haulm

其实最重要的是理出重新编译MGC的顺序，然后用脚本控制编译进度，遇到编译问题则找出srpm包进行分析，所谓的自动编译系统，我想也不必想得太复杂了，它可能只是一个mgc重构的行为指导。