主题：关于Linux的推广——普通用户篇 -- 万斤
家园 没有承诺，没有文档，自己想改就改， 你还称其为规范……看来我们对规范和标准的认识不是很相同。
这样吧，换个说法：windows 业界做的很规范，不过呢， Linux 方面做的更规范，这样你总接受吧？
家园 TX，没有公布不等于没有 Windows是商业软件，不是什么都必须公布的。
就是你说的FSSTND目前版本是2.3，这些改动也没有通知过UNIX/Linux业界外的任何人吧？就算是U/L业界内是不是所有人都听Free Standards Group的呢？
家园 强辩……你难道是微软雇员？微软做的规范不规范 日后你可以自己慢慢体会。
家园 冤枉。我的意思是说规范不是标准，自己人同意就算了 没有必要强逼着别人用。
FHS再怎么着也没有上升到ISO的高度，也就是U/L关了门自己用的。
Windows也是一样。M$每年出的白皮书可不比U/L少，也没人闹着说要U/L也遵守的。
至于说M$做的规范到底规范不规范，这个评价从何而来？
家园 这里说的是微软应该不应该向程序员承诺不随意变更 api 接口、目录结构。
微软起码应当通过文档明确哪些接口是要在以后的版本中淘汰的。这就是规范、标准。这甚至是要一个程序员最起码的要求。
这些， sun 能做到， rh 能做到， ibm 能做到；连 gnu 这样的非盈利机构也能做到， m$ 却做不到，甚至根本不想做。
你看看你在说什么？举 FHS 只是当作一个例子，一个标尺，我不是在说让 m$ 使用 FHS，我是在说 m$ 至少应当达到这样的水准（承诺不作大的变更，成立非盈利组织，以保持决定不受商业因素影响──我简直就是在对牛弹琴……）。
这是完全从程序员的角度出发的。如果你连这都不明白的话，…… Tais-toi! 回贴要看贴！不要凭你的想象！
家园 晕死，FHS和API有何关系？ 我怎么知道你提出FHS是想讨论API？你这话题转移的够宇宙第一速度了。
Windows的API难道没有文档？Windows(,office,....) SDK是干什么用的？Gates写的穿越小说还是山海经？
至于说到让微软“成立非盈利组织，以保持决定不受商业因素影响”，这才是对牛弹琴呢。你不会忘记M$是个商业组织吧？让商业组织“不受商业因素影响”，你也真会想。。。。。。
你前一个帖子批评M$
设计操作系统时不理会业界的规范，自成一体....然后又提出FSSTND。我不理解成你"在说让 m$ 使用 FHS"才是回帖不看贴呢。何况我还多讨论了一段Windows目录结构一致性。分歧就是，你觉得 windows 做得很有规范（估且这么说吧）；我不那么觉得
TX，你自己回帖也看贴，看看自己上一个回的是什么贴，不要自己飞到地球外面去还说别人不明白。。。。
家园 ......如果你指望微软帮你解决软件的移植性，那我无话 可移植性是怎么出来的，是通过各种各样的标准来实现的，各种各样的标准是怎么来的，是许多业界大牛坐在一块，讨论，最终相互妥协的结果。对程序员来说，什么最重要，标准。如果你想自己的程序可以通行于各种平台，了解各种相关的标准是必修课。微软作为一整套方案的提供商是有义务参与到标准的制定中来的，也有义务让自己的产品符合相关的标准。这样才可能实现真正的程序可移植。
你写程序的时候没遇到配置文件、临时文件应该放在哪里的问题，并不说明别人不会遇到。 FHS 至少是提供了一个标准。所以，尽管这不是 api ，但对我来说，这是写程序首先考虑的。如果你觉得这还很难与 api 联系起来，那我无语。
关于向下兼容性
VB.Net 与 VB 6.0 是完全不同的概念。我就学过 VB 6.0 ，最后， .Net 推出时你知道我的反应是什么吗？你举微软兼容性的例子，很可惜， vista 还有 .Net 都是微软的行动，微软完全无视旧产品的用户群。他今天可以抛弃 VB6 的用户，明天一样可以抛弃 .Net 的用户。.Net 1.0与 .Net 1.1 都是不完全兼容的，这你知道吗？
另外， SDK 是 Software development kit 软件开发工具（估且这么译吧），不是什么文档，也不是什么标准……你到底在说什么？微软 api 是有文档，但与 SDK 应该是两回事吧？我多问一句 Windows 98 下有那个目录什么（Documents and Setting）吗？只有 XP 一代才有的吧，是不是到了 Vista 以后又有了很多的变化？如果是这样，你凭什么认为微软做的很规范？我简直就不明白一个只用了不到两代的东西，（我不清楚有没有正式文件形成），没有任何第三方担保的东西，也值得相信？
至于你说的什么十多年前某些在 95 上可以跑的程序一样可以在 2008 上跑，我只问你一句，你玩过老游戏吗？一些程序实际上在 xp 上运行的很好，但在 2003 上就死机，这种事情，你怕也听说过吧？怎么解决可移植性是一个问题，但微软的把戏是邪路。 我随手找个 Linux 上的基础命令，可能都比什么从 win95 开始的 windows 程序要长寿几倍。
你的那些都是微软的标准宣传手段，还都是过时的，老兄，现在是二十一世纪了， windows 2008 是出来了，一路上，VB 程序员不知道被微软消灭了几代了。ANSI C 程序员则屹立不倒。你还在相信那些宣传实在是可笑的很。
提 FHS ，只是想向你揭示一下微软的短处，如果你非要把微软的短处说成是长处， I'm fine. 这只不过是一次失游说的失败而已，我不觉得受损失的是我。
家园 M$肯定不能解决移植性，但实际上业界也没有统一标准 你想用U/L系的某个东西来一统天下，目前看来只是个奢望而已。顺便说一下，M$大概不打算让自己的产品符合U/L的标准，相反，它大概想让U/L的向它看齐。
从DOS开始，M$就用%temp%来定义临时目录，直到目前都是这样。在任何版本的Windows下，下面的units都可以得到各种系统目录。这点相信不会给程序员带来任何困扰。
Windows目录: Use "GetWindowsDirectory"Windows下的system目录: Use "GetSystemDirectory"
temp目录: Use "GetTempPath"
当前目录: Use "GetCurrentDirectory"
你说的老程序在2003上会死机的问题，是一部分而不是全部。如果按照2003的库重编译一次，估计也不见得会死机吧。U/L用重编译的把戏实现移植，对用户而言（用户可没有源代码）才算是邪路；对程序员而言也算是地狱了。我开发了一个程序，为了适应不同distribution的用户，我得安装不同的Linux，编译N多次，发布M多个不同的二进制版本。。。。。
对了，说到这个问题，我还真没试过二进制程序是否可以运行于不同的Linux distributions——比如我在Ubuntu下编译的程序可以直接在RH下运行吗（假设都是同一台x86,又是同一个Linux kernel）？如果这点都做不到，就别跟Windows谈兼容性问题了。
我随便找个DOS的命令dir就长寿到今天，即使M$的文件系统建构从FAT到FAT32到NTFS。比Linux本身的寿命都长很多。如果Win内部没有规范他是怎么做到这点的？
至于说到ANSI C，似乎QT用的也不是ANSI C而是ANSI C++的语法吧？仍然坚守ANSI C的程序员（除了做嵌入之类的少数）要么是超级大牛，要么大概已经没饭吃了。Linux在进步，Java也进步了，就不许Windows也进步一下从VB到VB.NET？进步的代价就是用户要持续学习。
.NET的兼容性我没有发言权，但从wiki的文章上对.net的Criticism来看似乎没有涉及兼容性问题。所以我不得不说这是你个人的感觉了。
你说向我揭示的M$的短处完全没有说服我，即使我也不算M$的忠实用户。当然，如果你坚持不顾事实鄙视M$，我也没有损失:-)
家园 我说的是微软应当学习那种态度，鸡对鸭讲的情况 还要持续多久？微软的产品线不光是操作系统，我的意思也不是让 windows 变成 Linux ， OK ？我向你提到 FHS 为的是讨论微软在这些方面有什么相关的对程序员有利的举措。历史不能代表未来，不能因为微软过去勉强保证了软件的兼容性认为微软在未来也可以继续保证向下兼容。更何况，现在微软产品的向下兼容性已经很差了。而你的回答无法让这个讨论继续。对此我感到很意外。
而让我感到更意外的是，你不是介绍自己使用 .Net 编程兼容性方面的经验，而是引用什么 wikipedia ？你知道你在做什么吗？老实说，我有段时间很迷恋为维基撰写条目，（当然都是些与我专业相关的条目）。如果没有自己的经验，至少也应该拿出大拿们的相关发言吧？
使用微软提供的编程语言写出的程序，可移植性有多差，那是不言而喻的。如果你真的在跨平台编程上遇到了难题，想要快速解决，你应该学习是 (Sun) Java ，根本不是什么 Linux 编程。 但是如果你想在 Linux 上布署程序，学习一下 Linux 系统的维护是很正常。不要把编程与系统管理、维护看到一回事。
无论 tex 、 gcc 、 emacs 、 vi 都是可以在 windows 上运行的，而且我正在这么使用它们。 tex 甚至是用 pascal 写的。为什么 VB 写出的程序无法移植到 Unix 上？微软的提供的解决方案不是万能的，出现这种尴尬，原因很多。至少我觉得这是微软在对待开源、文档、用户等等一系列问题上的态度导致的。
算了，不空对空了，回答几个问题吧:
包的维护工作一般不是直接由上游程序员做的，包管理是另外一回事，你写了一个程序，给出源代码和编译方法就行。其余的事，在你的程序没有足够流行之前，没必要；如果程序足够的流行，更没必要。如果一直没有人愿意为你打包，我看也就算了吧。以 rpm 来说，你的软件如果有人为你打包，是件很有面子的事。至于进入发行版，那你就是牛人。
对用户而言，如果是使用 QT 写的源代码，很简单， qmake & make 就行了。就算一般的程序也就是 ./config & make 。在 Linux 的世界中二进制发布程序，也不是没有，但会被人极度 X 视。你不信任用户，用户自然不会信任你。所以，实在看不出来有什么必要使用二进制发布，当然不是说不可以。二进制发布，最常见的例子，你下载过 jre/jdk 的二进制发布包没有？退一步 google earth 呢？
另外，即使是像打包 rpm 这样的工作，只是一个 spec 的问题。你最多提交 src.rpm 包就足够了。编译是个自动化的工作，你的程序比 gcc 还牛不成？如果你连一个 spec 都不想写的话……
长寿也不是那么比的对吧？你怎么知道 dir 的源代码就没有重写过？关于你提到的用所谓 windows 2003 的库重新编译一遍，我很怀疑，你做过吗？怎么做的？介绍一下？
至于长寿的程序，很简单的一个例子就是 compat-gcc 。如果是 gcc 2.x 的最后一个版本，不算上 patch 的话，是十年以前的事了（想想真的是过眼云烟），但是至少我还是需要这个版本的 gcc 。如果你注意一下的话，像 tex 这样的程序，其实更加古老，尽管最新的版本是在零八年三月放出的，但从八二年（对的就是八二年，我都没想到会这么老）以来，这个程序没有过大的变动。如果你对 Knuth 还有一点敬意的话。
同一个二进制程序是否可以运行于不同的机器，你用 QT 写的 GUI ，结果，人家的机器上没 QT 当然不行了。你的抱怨很搞诶。随手写个 hello, world 就完事，还要提问……
QT 是用 C++ 写的没错，不过 QT 有不同的 bindings （绑定） python, C# , Ruby , java, Ada, pascal, Perl, PHP, Haskell ，写 QT 的 GUI 可能要一点 C++ 的常识，但是你还是可以用别的语言调用啊？叫你用 QT ，又不是让你去写 QT ……难道说我一定要懂 C++ 才能用 QT ，什么逻辑……如果你不是很了解 QT 的话，或是没有用过的话，这也许还有情可原。
最后，有人与程序只是为了做个台阶，向更高层的什么管理人员跳。但是也有很多人平平凡凡的写了一辈子的程序。我更喜欢做后者。
家园 分歧在于你不理解商业软件和GPL的界限 你的发言一向引以为豪的是只要重新编译源代码就可以万能了，以至于认为“实在看不出来有什么必要使用二进制发布”。问题在于，
1. 非GPL的商业软件可能给用户源代码吗？Linux是基于GNU的不谈了，别的不说，Linux的父辈，UNIX本身及其上面的商业软件，有几款是给出源代码的？你知道除了开源软件，还有商业软件存在吗？你知道商业秘密是什么意思吗？
2. 普通用户会构建编译环境编译源代码吗？
一致性检查，依赖性检查，版本兼容性检查。似乎编译前需要确认和做的事情很多吧，不是简单的一个make就能搞定的事吧？
普通用户会吗？你父母辈会吗？如果程序员光是在意自己的面子和感觉，不顾用户体验，他就不是合格的程序员。
Windows下，直接copy来一个小游戏，QQ就可以运行。如果你要告诉你的父母，要想玩一个麻将游戏，需要先下载安装gcc环境，再看软件说明下载安装某某库，或许还要安装autoconf和automake，或者其他的各种工具，然后，才能运行rpm安装这个游戏。。。blahblah。让我猜猜，你父母1000%会放弃，直接招呼邻居老张老李去了。这大概就是即使Linux免费，用户也宁愿用Windows的原因。
同一个二进制程序是否可以运行于不同的机器的问题，就算我愿意写hello world，我手上也没有多个linux版本测试。看起来你是做Linux开发的，比我方便的多，有空不妨你可以试试。记住，我可没让你写需要库的hello world pro.
我确实没有玩过QT，上面的帖子里说过的。我拿出QT来是说ANSI C也进化到C++了，你又扯出python什么的干什么？晕。既然C可以到C++，为什么VB不能到VB.NET？
至于说到.NET和大拿的问题。我承认我没有.NET编程经验。那么请问你有什么大拿抱怨过.NET兼容性差？
说到底，我们的分歧还是在于你不理解什么叫做商业软件，并坚持商业软件也要向开源软件一样，公开这个遵守那个，甚至提出让商业组织“不受商业因素影响”。不说你幼稚，起码也属于鸡同鸭讲了。
Windows能够存在到今天，被众多机构和个人接受，说明其在软件开发和用户体验方面做的并不差。对于程序员而言，也没有太多M$的程序员抱怨兼容性或者找不到API文档的问题吧。既然M$自成体系，为什么Gates一定要学习GNU这个针对非商业软件的做法？如果说UNIX比Windows古老，Windows就一定要学习UNIX就更是可笑。对Gates来说，他可能根本不需要考虑跨平台的问题——他为什么要考虑与对手兼容？
家园 你承认你没有 .Net 编程经验，同时也对 QT 一无所知，
而且，从你的回贴看，你对 Linux 下的软件开发也所知无多。
Are you kidding me?
家园 跨OS移植算不上“超级大难题” 跨平台软件有很多，最熟知的如Firefox。可以说只要开发者想做，都可以把软件做成跨平台的，不是什么难事。只是有些软件一开始开发时就没有考虑跨平台而已。
家园 是个实用性和必要性的问题。而且业界也没人捧着GNU当圣旨 如果从设计之初就考虑跨平台，当然一切都好办。但如果让已有的软件跨平台移植，90%都得重新架构，所以我才说算是“超级大难题”。不是难在技术实现上，是难在是否有这个必要和是否值得。
但如果有人捧着GNU到处招摇，不说盖子，就是UNIX/Linux内部的软件商，能有几家同意呢？
家园 说90%需要重新架构夸张了 Office和photoshop都有mac版。可以说只要设计不是太烂的软件作跨平台移植并不是非常困难的事。很多软件没有跨平台，最主要原因是其他平台的市场份额不够，开发商不屑去做而已。
家园 嘻嘻，你说的可都是有钱有势的业界老大呢 不清楚M$是怎么整得Office可以移植的（我一直以为是神话），但Windows下的（大型软件的）开发使用的那些工具，难得有几个可以兼容UNIX/Linux的。
我说90%只是形容一下“很多很多很多”，呵呵，倒没有数据支持这么说。但我可以说大部分软件在设计之初就没有考虑跨平台，在事后考虑移植的时候，软件的设计在移植能力上估计没几个算不烂的。也是啊，既然Linux上没这个份额，设计的时候干嘛还费事费人工去考虑这个呢
不过我对这点确实不懂，有空请科普一下，如果一个软件需要考虑跨平台，应该在开发之初应该多考虑什么？首先选个好用的跨平台编译器是肯定的，然后呢？