有一些Linux老手不屑于wine, 有一些人很需要wine, 本文不争论wine好还是不好的问题, 只是从技术和社区两个出发点来讨论问题.
从技术的视角来看. 有一些朋友可能对wine有这样一些误解:
- 认为从windows上copy过来的native dll比wine的builtin dll好, 有事没事就装一大堆native dll, 有事没事就用winetricks
评: 这是不对的.
- 首先, wine设计的目标是完全脱离Windows, wine的开发中并没有刻意去和Windows的native dll做到二进制兼容, Wine的目标用户是没有Windows的用户.
- 如果一个软件在纯builtin dll的情况下有问题, 那就必须给Wine报一个bug. 只要Wine没有做到out of box (开箱即用), 就可以给Wine报bug.
- 如果装了native 的dll, 哪怕你出问题了去报bug, wine开发者也不会接受. 这里有技术上的原因, 也有法律上的原因. 技术上, 使用native dll, 调试的时候跟踪到native dll里就没有调试符号信息了, 因此调试的难度加大了. 可能有的朋友会说可以反汇编, 但是这又有法律上的限制, 对Windows的dll进行反汇编是有法律风险的, wine的开发者都会尽量避免这么做.
- 认为Wine很难用,需要各种复杂的配置.
评: 这是不对的, wine设计的目标就是work out of box, 任何额外的配置都可能是bug. 不管是改动一个dll, 还是修改一下注册表, 都属于额外的配置, 都可以搜索一下有没有已知的bug, 没有的话可以去报bug
- 认为有些Windows程序只能在某个特定的老版本中运行, 不能在新版本中运行, 从而不敢升级.
评: 这是不对的. 确实有很多程序在旧的wine中正常而在新的wine中出问题, 但这是暂时的, 出现这种情况千万要报一个bug, 这种情况叫做 regression, 只要报了bug, 开发者一定会优先处理. 软件开发最应该避免的就是regression, 但是regression是难以避免的, 而开发者又不一定是用户, 所以有些regression需要用户去发现, 去报bug.
- 认为Wine终端输出的fixme是bug
评: 这是不对的, 大部分的fixme都是无害的,不用担心. 但是如果真的有bug要报, 记得提供完整的终端输出, 又开发者来诊断. 如果想自己排查解决问题, 那很好, 去看源代码.
- 认为Wine效率低, 占用内存大, 占用cpu高.
评: 不完全对. Wine的效率一直在改进中, 从原理上看, Wine中运行的Win32程序的效率是接近原生linux程序的效率的. 但是, 有时候一些进程间通信的地方效率可能会低, 涉及到DirectX的地方效率也可能会变低,这就很难说了. Wine的DirectX效率不高, 有时候原因在于Linux显卡驱动的bug, 有时候是Wine本身实现不够完美. 幸运的是, 效率问题也是bug, 如果你发现某个程序在Wine中的效率和Windows中的效率差别极大, 那就应该去给Wine报一个bug. 至于Wine占用的内存, 理论上也是很小的, 远远比虚拟机小, 如果你发现Wine运行某个程序占用内存极大, 可能是有内存泄露的bug, 也应该去报一个bug. 同理, 如果某个程序在Wine中占用CPU很高,远超过在Windows下,也应该报一个bug.
- 认为Windows程序在Wine上无法运行是程序的错, 不是Wine的错
评: 掩饰自由软件的缺点, 并不会给自由软件带来改进, 也不会给自由软件带来更多用户. Wine有很多bug等着我们去报, 认认真真报一个bug并耐心跟进, 才是推动开源软件进步的务实的手段. 只要是用户空间的程序, 如果可以在Windows下正常运行却在Wine下出错, 那就一定是bug. 大部分时候是Wine的bug, 但也有可能是Linux内核的bug, 显卡驱动的bug, 声卡驱动的bug, opengl的bug等等. 如果是后者, 报一个wine的bug还能改进其他自由软件, 何乐而不为呢?
从社区的角度来看, 我认为下面这些做法也是有一定的误导的:
- 辛辛苦苦研究出怎么在Wine上运行某个程序, 在论坛上分享, 却没有去报bug
评: 钻研精神可嘉, 分享精神可嘉.
- 但是, 这种分享经常带来误导
- 如上所说, Wine应该是out of box的, 而这类 "技术分享", 恰恰给人带来wine很难用的错觉
- 使用开源软件,就应该用开源的方式思考问题. 辛辛苦苦研究出workaround的步骤, 正好是报告bug的第一手的好材料. 只有把自己遇到的问题报告给上游, 把自己找到的workaround方法报告给上游, 才能改进开源软件本身, 才能真正一劳永逸地解决问题, 真正免除新手的痛苦.
- 最佳的做法, 就是去给Wine报一个bug, 然后在做这类"技术分享"的时候, 强调"这是wine的一个bug, 我给上游报告了, 感兴趣的朋友可以一起跟踪这个bug. 目前可以用下面的方法来暂时避开这个bug, 以后如果新版本的Wine修复了这个bug, 就不需要这一步workaround了."
- 这种做法, 不仅帮助新手暂时解决问题, 还树立了一个榜样, 告诉新手发现问题应该及时给开源软件报bug.
- 指责Wine如何如何, 甚至指责使用Wine的人如何如何
评: 使用自由软件是每个人的自由, 选择什么样的自由软件, 并没有高低之分.
一个例子是:
A: "求助, wine office不成功, 怎么办?"
B: "用Libreoffice不行么? 何必用M$ Office呢?"
C: "要用M$ office, 回去用你的Windows吧"
实际上, 可能连B也不知道, 如果Libreoffice打开MS Office文档格式出问题, 也 *可以* 并且 *应该* 给Libreoffice报一个bug.
如果B这样回答, 也许会更好: 有没有试过Libreoffice? 如果想尝试Libreoffice, 就要注意可能会有些文档格式不兼容的问题, 但是如果你发现了这样的问题, 可以去给Libreoffice报一个bug, 将 *样本文档* , *正常截图* 和 *错误截图* 三者一起提供给开发者. 如果你不知道怎么报bug, 可以发到论坛上, 让大家协助你报bug.
至于C, 我们就不去评论他了. 如果有人告诉A, 使用开源软件遇到问题是正常的, 但是我们可以去改进开源软件, 最直接有效的方法就是去报一个bug, 这就好多了.
最后吐嘈一下, 有一些所谓开源爱好者,只是伪开源爱好者, 不懂开源, 还打击和误导新手. 跟大家共勉, 希望能和大家一起进步
更新一下: 有心报bug的朋友, 千万不要报了之后就不管, 要及时跟进, 答复开发者的测试要求. 如果报bug跟盖烂尾楼一样, 那么得到修复的机会就很小了, 一定要对自己报的bug负责任.
...學習了...
