如果冲突了就提bug，如果真的是个问题他们会解决，我给Debian提了很多bug，几乎都有回复
2012/8/14 Plain_Text :
>
>
> 日常编写 C 应用程序一般都调用 glibc 提供的接口。按理来说, glibc 提供
> 的 texinfo 文档应该是权威。但为何 Linux Kernel 社区发布的 man2, man3 里
> 也包含了大量相同的文档？没认真比较过两者，不过既然是不同的社区（两者还有
> 些微妙的矛盾）提供，难免会有一些冲突的地方吧。应该以哪个为准？
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian
OK,
我看了一下http://www.kernel.org/doc/man-pages/，明白你的意思了。该网站下确实有很多库函数的man。是否与glibc提供的man有冲突还得分析。不过，真要是不一样了，就读源代码吧，毕竟这是开源的好处之一。此外，如果碰到两个上游软件提供同样的文件时（这种情况确实有），选择哪一个也是发行版打包人的工作，你还能为发行版，比如debian，的开发做出贡献呢。
2012/8/19 Zhi Li :
> 哎~~~
> 我已经说的够清楚的了，还说我混淆概念。
> Kernel是内核，glibc是库。
> Kernel管的是什么？是系统调用。
> glibc管
哎~~~
我已经说的够清楚的了，还说我混淆概念。
Kernel是内核，glibc是库。
Kernel管的是什么？是系统调用。
glibc管的是什么？是库函数。
有很多系统调用和库函数是同名的，但它们并不是一回事。
2012/8/18 Plain_Text :
>
>
> 2012-08-17(Friday) 16:52:04 +0800, Zhi Li :
>
>> 可见man2讲的是kernel提供的系统调用，man3讲的是库函数，这两个是有一点点区别的。应用程序一般不会去直接调用系统调用，应用程序调用libc，libc再调用kernel提供的系统调用。库函数一般和系统调用一一对应，
glibc 不是 Linux 必须的吧。 Linux 最早是有自己维护 libc 的，想必当时就有了自己的 man-pages，后来
glibc 流行了，估计又做了相应的修改，一直延续下来？ （可以参考下 man libc）
我没怎么读过那些 info。但直观上想，Linux 提供的 libc 文档很可能更注重接口，而 glibc
的文档则会突出它自己的实现（可能更细致）。如果哪天大家不用 glibc 了，Linux 的 man-pages
改一改就又跟上了时代。而对用户来讲，不管怎么变，只要跟以前一样 man 一下就可以了，感觉还是很方便的。
至于“不一致”的地方，只靠怀疑是不够的。不
2012-08-17(Friday) 16:52:04 +0800, Zhi Li :
> 可见man2讲的是kernel提供的系统调用，man3讲的是库函数，这两个是有一点点区别的。应用程序一般不会去直接调用系统调用，应用程序调用libc，libc再调用kernel提供的系统调用。库函数一般和系统调用一一对应，但也有例外，比如exec在libc库中有数个函数，但对应系统调用仅有一个。再比如printf没有一个直接对应的系统调用，当然它最终要通过调用write来实现功能。
> 结论是：1. 不矛盾，一个讲的是系统调用，一个讲的是库函数；2. man2主要是kernel提供的，man3
我来试着谈谈我的看法：
首先从`man man`中可以看到：
1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/p
man2 来自内核, man3 来自libc
2012/8/15 Plain_Text :
>
>
> 2012-08-15(Wednesday) 14:26:49 +0800, wd :
>
>
>> 建议你有功夫发这种帖子，不如花时间两个文档都看看，看看是不是真的有区别，区别在什么地方，有错误就报告给社区。
>
>
>
> 张三与李四是两个技术牛人，对某项技术各自写了一本书。一个小菜鸟想学习
> 该技术，但是时间和精力都有限，于是想从两个牛人的书中挑选出一本来做参考。
> 小菜鸟想：“如何两个牛人联合起来共同写一本书，该多好呀！这样，我就不用在
> 两者之间犹豫该选哪一本了。”可是
2012-08-15(Wednesday) 14:26:49 +0800, wd :
> 建议你有功夫发这种帖子，不如花时间两个文档都看看，看看是不是真的有区别，区别在什么地方，有错误就报告给社区。
张三与李四是两个技术牛人，对某项技术各自写了一本书。一个小菜鸟想学习
该技术，但是时间和精力都有限，于是想从两个牛人的书中挑选出一本来做参考。
小菜鸟想：“如何两个牛人联合起来共同写一本书，该多好呀！这样，我就不用在
两者之间犹豫该选哪一本了。”可是，他知道这没有可能性：因为两个牛人有些矛
盾，不愿意共同写书。于是该小菜鸟向其他人请教，问问其他人：“两个牛人的书，
哪本更权威？
建议你有功夫发这种帖子，不如花时间两个文档都看看，看看是不是真的有区别，区别在什么地方，有错误就报告给社区。
2012/8/15 Plain_Text :
>
>
> 2012-08-15(Wednesday) 11:47:31 +0800, Dongsheng Song
> :
>
>> 典型的 FUD ( http://zh.wikipedia.org/zh/FUD )，请用事实来说话!
>> 纵然真的看不惯对方，这2个社区也不会指鹿为马,故意说错。
>
>
> 并没有说他们故意将文档弄成不一样，但如果两个社区不相互交流，肯定会出
不互相交流是你觉得呢，还是有实例？
> 现一
2012-08-15(Wednesday) 11:47:31 +0800, Dongsheng Song :
> 典型的 FUD ( http://zh.wikipedia.org/zh/FUD )，请用事实来说话!
> 纵然真的看不惯对方，这2个社区也不会指鹿为马,故意说错。
并没有说他们故意将文档弄成不一样，但如果两个社区不相互交流，肯定会出
现一些问题。更不是对他们进行污名化，两者有矛盾是客观事实。从所谓的 GNU/Linux
命名之争以及 Free Software, Open Source Software 之争即可看出。
--
To UNSUBSCRIBE
典型的 FUD ( http://zh.wikipedia.org/zh/FUD )，请用事实来说话!
纵然真的看不惯对方，这2个社区也不会指鹿为马,故意说错。
2012/8/15 Plain_Text
>
>
> 2012-08-14(Tuesday) 19:07:41 +0800, wd :
>
>
> > 你发现冲突了？
>
>
> 我在顶楼是这样写的：“没认真比较过两者，不过既然是不同的社区（两者还
> 有些微妙的矛盾）提供，难免会有一些冲突的地方”。除非 man-pages 是从 glibc
> texinfo 直接转换而来，否则难免会有不一致的地方。因为两个社区独立维护，互
你何以认为 man2 和 man3 都来自 linux kernel?
2012/8/15 Plain_Text :
>
>
> 2012-08-14(Tuesday) 19:07:41 +0800, wd :
>
>
>> 你发现冲突了？
>
>
> 我在顶楼是这样写的：“没认真比较过两者，不过既然是不同的社区（两者还
> 有些微妙的矛盾）提供，难免会有一些冲突的地方”。除非 man-pages 是从 glibc
> texinfo 直接转换而来，否则难免会有不一致的地方。因为两个社区独立维护，互
> 相看不惯对方，缺少交流。就好比原有的 OpenOffice.org 社区分裂成 A
2012-08-14(Tuesday) 19:07:41 +0800, wd :
> 你发现冲突了？
我在顶楼是这样写的：“没认真比较过两者，不过既然是不同的社区（两者还
有些微妙的矛盾）提供，难免会有一些冲突的地方”。除非 man-pages 是从 glibc
texinfo 直接转换而来，否则难免会有不一致的地方。因为两个社区独立维护，互
相看不惯对方，缺少交流。就好比原有的 OpenOffice.org 社区分裂成 Apache
OpenOffice 和 LibreOffice 之后，两者独立开发，肯定各有各的优点，也各有各
的缺点。
--
To UNSUBSC
你发现冲突了？
2012/8/14 Plain_Text :
>
>
> 日常编写 C 应用程序一般都调用 glibc 提供的接口。按理来说, glibc 提供
> 的 texinfo 文档应该是权威。但为何 Linux Kernel 社区发布的 man2, man3 里
> 也包含了大量相同的文档？没认真比较过两者，不过既然是不同的社区（两者还有
> 些微妙的矛盾）提供，难免会有一些冲突的地方吧。应该以哪个为准？
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-chinese-gb-requ...@lists.debian.org
> w
14 matches
Mail list logo
