Chinaunix

标题: 【FreeBSD操作系统设计与实现】勘误汇总 [打印本页]

作者: 雨丝风片    时间: 2006-03-20 09:01
标题: 【FreeBSD操作系统设计与实现】勘误汇总
不断更新中。。。

【英文版勘误】
http://www.mckusick.com/book/FreeBSDerrata.html

【中文版勘误】

目前发现有值得商榷的翻译内容的页面有:
前言第5页、44、48、49、78、79、80、111、116、117、118、119、120、157、167、260、261、454、466

目前提交勘误信息的人有:gvim,雨丝风片,billypeng ,japonensis。。。



【前言5页】上数第6行:(雨丝风片)
[本书]:
以及4CD套装,其中包含伯克利的所有BSD版本和BSD源代码的受控史。
[原文]:
and a 4-CD set containing all the release and the source-control history of BSD from Berkeley.
[雨丝风片]:
我看到这里,吓了一跳,以为是BSD源代码“受到控诉的历史”。去查原文,才发现是source control历史,此处当指整个Berkeley时期的BSD版本控制系统生成的代码修改记录等历史信息。所以我觉得译文应当是“以及一套由Berkeley提供的含有BSD所有发布版本和源代码控制历史的4CD套装。”

【44页】上数第17行:(gvim)
3.1.4内核入口 一节(对应 3.1 Entry to the Kernel)里的最后一段,有一句话"对于系统调用来说,其参数为该系统调用号和一个异常处理结构",原书是"For a system call, they are the system-call number and an exception frame. " 这里将frame翻译成结构,虽然没有什么不妥,可我一开始还真没看明白。翻到原文一看,原来是指的"异常处理堆栈栈桢"这个意思。不知大家有没有什么意见。

【44页】倒数第9行:(gvim)
"计数器和程序状态长字"改为"处理器状态长字"(原书勘误)

【48页】上数第18行:(gvim)
3.4节印刷书P48,中间的“hardclock()所做工作如下:”的最后一个profclock应为statclock。

【49页】上数第3行:(gvim)
p49页第三句上面有句话:"剖析统计时钟就设为以1拍的速度来运行,这个速度已经相当于逼近主系统时钟(在PC上是每秒1024拍)的速度了"。这里我没有理解"1拍的速度","拍"是相对于一个时间段来说的频率,比如系统1秒钟100拍(p47倒数3行),而这里找不到"1拍"的参照物,所以我查了下。原话是这样"When one or more processes are requesting profiling information, the profiling clock is set to run at a tick rate that is relatively prime to the main system clock (1024 ticks per second on the PC). " (在3.4 Statistics and Process Scheduling下面最后一段)。我觉得这里的a是修饰的rate,而不是当成1来翻译。所以我觉得是否原文大意应为:“剖析统计时钟就设为一个逼近主系统时钟节拍的速度(在PC上是每秒1024拍)来运行”

【78页】上数第5行:(gvim)
原文为"Mutexes must have the information and storage space to support priority propagation",翻译的是"互斥锁必须带有信息和存储空间,以此支持优先级",很明显,没有表达出"priority propagation"的原意

【78页】上数第11行:(gvim)
"However, it is always safe to use these forms of locks in an interrupt thread without fear of deadlock against an interrupted thread on the same CPU. "漏译了这一整句话。我翻译的是"然而,在中断线程中使用这些形式的锁总是安全的,不必担心和同一CPU上的另一个中断线程发生死锁。"

【79页】上数第1行:(gvim)
"正在运行的线程获得一个互斥锁"改为"运行的内核线程获得"

【80页】上数第4行:(gvim)
"下半部"改为"上半部"

【111页】上数第7行:(雨丝风片)
[本书]:
3. 当放置操作所请求的页面不在主存内的时候,如何选择要从主存里删除的其他页面——替换策略(replacement policy)。
[原文]:
3. How the system selects pages to be removed from main memory when pages are unavailable for a placement request—the replacement policy
[雨丝风片]:
这里的unavailable的意思并非“所请求的页面不在主存内”,要被放置的页面现在当然不在主存内,这里的意思是主存内现在没有可用的(空闲)页面来满足这次的放置操作了,于是就需要从主存中选择一些页面挪到备份存储设备上,腾出地方来满足这次放置操作的要求。

【116页】上数第10行:(雨丝风片)
[本书]:
为了避免在一段地址范围内混入不相关地地址段,可以用子映射来覆盖那段地址范围。
[原文]:
To avoid intermixing of unrelated allocations within an address range, that range is covered by a submap, and only the appropriate subsystem can allocate from that map.
[雨丝风片]:
此处漏掉了最后半句话的翻译,影响了对句子完整意思的理解,前半句的翻译也不准确。全句的翻译应为:“为了避免各种不相关的分配混杂在同一个地址区间里,我们可以用一个子映射来覆盖这个区间,并且只有恰当的子系统才能在这个映射中进行分配。”
(注:即通过子映射来实现子系统级的专区专用。)

【116页】下数第2行:(雨丝风片)
[本书]:
这段内核地址空间由子映射管理,子映射的头指向被引用的vm_map结构。
[原文]:
This piece of the kernel address space is being managed via a submap headed by the referenced vm_map structure.
[雨丝风片]:
这里译成“子映射的头指向。。。”不妥。子映射的vm_map结构体是由vm_map_entry结构体里的sub_map指针指向。由于作者此处在专讲vm_map_entry结构体,因此只是说这个子映射是由指向的vm_map结构体开始的,其完整意思应该是“这个子映射是由(vm_map_entry结构体中的sub_map指针)指向的vm_map结构体开始的。”

【117页】上数第5行:(雨丝风片)
[本书]:
虚拟内存系统实现了一套基本函数来分配和释放内核所使用的虚拟内存范围,这个范围有页对齐和页取整两种方式。
[原文]:
The virtual-memory system implements a set of primitive functions for allocating and freeing the page-aligned, page-rounded virtual-memory ranges that the kernel uses.
[雨丝风片]:
range直译为“范围”似觉不妥。整句可译为:“虚拟内存系统实现了一组基本的函数,用以分配和释放内核所使用的需要按页对齐和按页取整的虚拟内存区域。”

【117页】倒数第16行:(雨丝风片)
[本书]:
可调页的地址范围是按需分配物理内存的,而且该内存可以由pageout(页面调出)守护进程回写到后备存储器上,这可以作为该守护进程的正常替换策略的一部分。
[原文]:
A pageable range has physical memory allocated on demand, and this memory can be written out to backing store by the pageout daemon as part of the latter's normal replacement policy.
[雨丝风片]:
首先,“按需分配”亦可理解为要多少给多少,不能准确传达原意。其次,将内存写出也不是“可以”作为替换策略的一部分,它本来就是一部分。整句另译如下:“可进行调页的区域是在需要的时候才分配物理内存的,作为常规替换策略的一部分,这种内存可由pageout daemon写出到备份存储中。”

【117页】倒数第11行:(雨丝风片)
[本书]:
kmemfree()回收内核中固定的内存
[原文]:
Kmem_free() deallocates kernel wired memory
[雨丝风片]:
函数名中遗漏了一个下划线。

【117页】倒数第6行:(雨丝风片)
[本书]:
因此,推荐用此方法分配内核内存而不是固定大小的大型结构,用下一节介绍的区域存储分配程序处理后者效果会更好。
[原文]:
So it is the preferred way to allocate kernel memory other than large, fixed-size structures that are better handled by the zone allocator described in the next subsection.
[雨丝风片]:
“内核内存”和“大型结构”之间是包含关系,这里却译成了互斥关系,完全看不到原文中“other than”的意思了。整句另译如下:“因此,除了大型的、固定尺寸的结构由下一节介绍的zone分配器来处理更为合适之外,分配内核内存应当首选这种方法。”

【118页】倒数第10行:(雨丝风片)
[本书]:
存储分配程序的速度慢还会造成另一个问题,就是让那些频繁使用内核接口的程序员放弃把存储分配程序作为首选方法,而代之以通过维护他们自己的内存分配池来创建自己的存储分配程序。
[原文]:
Another problem with a slow memory allocator is that programmers of frequently used kernel interfaces will think that they cannot afford to use the memory allocator as their primary one. Instead, they will build their own memory allocator on top of the original by maintaining their own pool of memory blocks.
[雨丝风片]:
这一节讲的是内核的内存分配程序,而不是用户级的内存分配程序,受其影响的自然也应当是内核程序员,而非用户级的程序员。“那些频繁使用内核接口的程序员”应译为“那些会被经常用到的内核接口的程序员”。

【118页】倒数第7行:(雨丝风片)
[本书]:
如果它们都有自己的空闲链表,那么两个链表所关联的内存总和就是两个子系统分别运行时所使用的内存之和的最大值。而如果它们共享一个空闲链表,则两个链表所关联的内存总和就可能是同两个子系统分别运行时使用内存最多的那个子系统的一样。
[原文]:
If they have their own free lists, the amount of memory tied up in the two lists will be the sum of the greatest amount of memory that each of the two subsystems has ever used. If they share a free list, the amount of memory tied up in the free list may be as low as the greatest amount of memory that either subsystem used.[雨丝风片]:
这一段把“和”和“最大值”译得比较混乱,不能清晰地表达出愿意。这段的意思就是讲甲、乙两个子系统各有各的空闲队列,于是甲的空闲块不能给乙用,乙的空闲块不能给甲用,这就造成了空闲块的浪费。原文另译如下:如果它们都有自己的空闲链表,那么这两个链表所占据的内存数量就是每个子系统曾经使用过的最大内存数量的和。如果它们共享一个空闲链表的话,这个空闲链表占据的内存数量就只相当于内存用量最大的那个子系统的值了。

【119页】上数第2行:(雨丝风片)
[本书]:
通常,这个区域会返回一块可以使用的内存。只有当区域内所有的内存块都已经投入使用的时候,区域存储分配程序才会再创建一组内存区域。
[原文]:
Usually, the zone will have an available piece of memory that it can return. Only if every piece of memory in the zone is in use will the zone allocator have to do a full allocation.
[雨丝风片]:
这两句译得离原意太远了。另译如下:一般情况下,区域内都能够找到一块可供返回的内存。仅当区域内的所有内存块都已被使用时,区域分配器才会进行一次完整意义上的分配。


【119页】上数第9行:(雨丝风片)
[本书]:
此时的分配算法就切换到速度较慢,但是对于分配大于一页的内存效率比较高的策略上来。2-幂算法分配大小为1、2、4、8、...,n个页面,而大块算法按页面倍数分配内存,分配大小为1、2、3、4、...,n个页面。
[原文]:
The algorithm switches to the slower but more memory-efficient strategy for allocation sizes larger than a page. This value is chosen because the power-of-2 algorithm yields sizes of 1, 2, 4, 8, . . ., n pages, whereas the large block algorithm that allocates in multiples of pages yields sizes of 1, 2, 3, 4,. . ., n pages.[雨丝风片]:
此处完全把前后语句的因果关系给译没了,使人不知所云。另译如下:如果分配的尺寸大于一个页面,算法就会切换成比较慢的但内存效率却更高一些的策略。之所以选择这个数值,是因为2-幂算法此后分配的尺寸将是1、2、4、8、...、n个页面,而大块算法则将按页面的整数倍分配1、2、3、4、...、n个页面。


【119页】上数第14行:(雨丝风片)
[本书]:
首先把需要分配的大内存取整为页面大小的倍数.
[原文]:
Large allocations are first rounded up to be a multiple of the page size.
[雨丝风片]:
应把"向上"取整的含义明确地译出来:大型的内存分配首先会被向上取整为页面尺寸的倍数.


【119页】上数第19行:(雨丝风片)
[本书]:
因为在释放一块内存时并不指定其大小,所以分配程序需要一直跟踪其所释放的内存片的大小.
[原文]:
Because the size is not specified when a block of memory is freed, the allocator must keep track of the sizes of the pieces that it has handed out.
[雨丝风片]:
此处把hand out译为释放简直就是颠倒黑白.另译如下:由于在释放一块内存的时候不会指定其大小,因此分配程序必须对它分配出去的内存块的尺寸进行跟踪.


【119页】倒数第12行:(雨丝风片)
[本书]:
如果采用太过标准的策略,那么这些分配请求的内存就会增加一倍.
[原文]:
The size of these requests would be nearly doubled if the more typical strategy were used.
[雨丝风片]:
"the more typical strategy"显然是有所指的,它说的就是前面提到的按2的整数次幂的分配策略,此处译为"太过标准的策略"反而不知所云了.另译如下:如果采用那个较为典型的策略,这些请求的尺寸就会被扩大为原来的两倍.


【119页】倒数第1行:(雨丝风片)
[本书]:
它们往往会被放大,因而容易浪费空间.
[原文]:
They tend to be large and hence wasteful of space.
[雨丝风片]:
不知"放大"从何说起?另译如下:它们可能会很大,从而浪费空间.


【120页】上数第2行:(雨丝风片)
[本书]:
因为它们个个都会浪费内存,它们浪费的内存加到一起就会比纯粹的内存用量大得多.
[原文]:
Because they are individually wasteful of space, collectively they waste too much space compared to a denser representation.
[雨丝风片]:
什么是"纯粹的内存用量"?不知所云.另译如下:因为它们各自都很浪费内存,和紧密的内存分配方式比起来,它们总共浪费的内存就太多了.


【120页】上数第15行:(雨丝风片)
[本书]:
会超过把它们放入完整的内存池在效率上获得的好处.
[原文]:
outweighs the efficiency gains from keeping them in the general pool.
[雨丝风片]:
"完整的内存池"为何物?此处显然说的是不区分大小和类型的"大杂烩"内存池,应译为"通用内存池".


【157页】倒数第6行:(雨丝风片)
[本书]:
对于一个有4KB大小的虚拟页面以及32位页表项的4GB地址空间来说,需要用100个页表项,即4MB来描述整个地址空间。
[原文]:
For a 4-Gbyte address space with 4-Kbyte virtual pages and a 32-bit page-table entry, 1 million entries, or 4 Mbyte, would be needed to describe an entire address space.
[雨丝风片]:
少了一个“万”字,1000000就成了100了。。。

【167页】上数第3行:(雨丝风片)
[本书]:
5.1 支持虚拟内存对一个机器意味着什么?对于支持虚拟内存的机器一般需要哪4种硬件设备?
[原文]:
5.1 What does it mean for a machine to support virtual memory? What four hardware facilities are typically required for a machine to support virtual memory?
[雨丝风片]:
“facilities”这个东西在这儿翻译成“设备”让我很是琢磨了一阵,书中并没有把虚拟内存对硬件的要求细化到具体“设备”这一级,因此,我觉得这里翻译成“对于支持虚拟内存的机器,一般要求提供哪4种硬件功能?”比较好。

【167页】上数第8行:(雨丝风片)
[本书]:
5.4 什么是写时复制?在大多数UNIX应用中,系统调用fork后面几乎总是会立即跟着执行一次exec系统调用。为什么在实现fork时使用写时复制技术显得特别有吸引力?
[原文]:
5.4 What is copy-on-write? In most UNIX applications, the fork system call is followed almost immediately by an exec system call. Why does this behavior make it particularly attractive to use copy-on-write in implementing fork?
[雨丝风片]:
这里把前后两句话之间的因果关系给翻译没了。最后一句话的提问是显式依赖于第二句话的事实的。因此,我觉得如此翻译较好:“在大多数的UNIX应用程序中,fork系统调用后面几乎总是会紧跟着一个exec系统调用。为什么这种做法会使得在实现fork的时候使用copy-on-write特别有吸引力?”

[260页] 表中:(billypeng )
pagedep   根据(应该为跟踪)目录块的依赖关系。

[261页] 16行:(billypeng )
软共享(应该为更新)代码。
        19行原文:The ATTACHED flag shows that the buffer with which the dependency structure is associated is not currently being written.
             书中翻译为:ATTACHED这个标志表明,当前没在把依赖关系所关联的缓冲区写入磁盘。
         本人认为,该中文意思没有表示进行时态,应该翻译为:
          ATTACHED这个标志表明,当前没有处在把依赖关系结构所关联的缓冲区写入磁盘的过程中。

【454页】上数第17行:(雨丝风片)
[本书]:
**13.35 既然IPsec可以递归调用网络协议栈内的,这对该代码有什么样的要求?
[原文]:
**13.35 Since IPsec may call routines in the network stack recursively, what requirement does this place on the code?
[雨丝风片]:
此处遗漏了对routines的翻译。

【454页】上数第18行:(雨丝风片)
[本书]:
**13.36 试述一个数据包可以通过代码的3条路。
[原文]:
**13.36 Describe three paths that a packet can take through the networking code.
[雨丝风片]:
此处只说“通过代码的3条路”着实让人不解,数据包如何“通过”代码?查原文,此处遗漏了对networking的翻译。原意当指一个数据包进入网络协议栈处理代码之后的3个可能的去向,比如接收、转发等等。

466页,表14.3:(japonensis)
例程 procO_init()应该为proc0_init()
0错印成O 了

[ 本帖最后由 雨丝风片 于 2006-9-1 16:58 编辑 ]
作者: congli    时间: 2006-03-20 09:09
呵~好!
作者: 雨丝风片    时间: 2006-03-20 09:53
我把gvim发现的问题也合并进来了,这样查找方便一些。
作者: 剑心通明    时间: 2006-03-20 11:22
好同志啊
作者: congli    时间: 2006-03-20 11:49
原帖由 剑心通明 于 2006-3-20 11:22 发表
好同志啊

神龙见首不见尾.
作者: 雨丝风片    时间: 2006-03-21 09:16
又找到了两处值得考虑的地方。现在有了中文版还是离不开英文版,,不过希望这里的勘误工作能够让更多的人不再依赖英文版了,
作者: zzh_nuaa    时间: 2006-03-21 11:45
标题: 回复 1楼 雨丝风片 的帖子
这本书有电子版下么? 呵呵,想先看看
作者: 雨丝风片    时间: 2006-03-21 11:53
原帖由 zzh_nuaa 于 2006-3-21 11:45 发表
这本书有电子版下么? 呵呵,想先看看


网上有英文版流传。
作者: zzh_nuaa    时间: 2006-03-21 12:06
标题: 回复 8楼 雨丝风片 的帖子
给个英文版的链接呀,最好是PDF的,呵呵
作者: 雨丝风片    时间: 2006-03-21 12:32
原帖由 zzh_nuaa 于 2006-3-21 12:06 发表
给个英文版的链接呀,最好是PDF的,呵呵


我搜也是搜,你搜也是搜,自己搜!

[ 本帖最后由 雨丝风片 于 2006-3-21 12:45 编辑 ]
作者: colddawn    时间: 2006-03-21 13:48
留地址,我发给你们
作者: 雨丝风片    时间: 2006-03-22 08:02
最新勘误,已更新至一楼:

【44页】倒数第9行:(gvim)
"计数器和程序状态长字"改为"处理器状态长字"(原书勘误)

【78页】上数第5行:(gvim)
原文为"Mutexes must have the information and storage space to support priority propagation",翻译的是"互斥锁必须带有信息和存储空间,以此支持优先级",很明显,没有表达出"priority propagation"的原意

【78页】上数第11行:(gvim)
"However, it is always safe to use these forms of locks in an interrupt thread without fear of deadlock against an interrupted thread on the same CPU. "漏译了这一整句话。我翻译的是"然而,在中断线程中使用这些形式的锁总是安全的,不必担心和同一CPU上的另一个中断线程发生死锁。"

【79页】上数第1行:(gvim)
"正在运行的线程获得一个互斥锁"改为"运行的内核线程获得"

【80页】上数第4行:(gvim)
"下半部"改为"上半部"

【157页】倒数第6行:(雨丝风片)
[本书]:
对于一个有4KB大小的虚拟页面以及32位页表项的4GB地址空间来说,需要用100个页表项,即4MB来描述整个地址空间。
[原文]:
For a 4-Gbyte address space with 4-Kbyte virtual pages and a 32-bit page-table entry, 1 million entries, or 4 Mbyte, would be needed to describe an entire address space.
【雨丝风片】:
少了一个“万”字,1000000就成了100了。。。
作者: 雨丝风片    时间: 2006-03-22 08:18
原帖由 vity 于 2006-3-22 00:04 发表
本人认为,从关键的原文意思层面上,楼主纠正的很准确和正确。辛苦了,顶一下!
不过可在语句上再修改一下,让语气更顺些。


就我个人而言,目前的想法主要是纠正中译本中一些会导致理解误差的地方,至于语句通顺方面则考虑得比较少,因为我想每个人的语感都不一样,书中我读着别扭的句子太多了,改不胜改,所以索性暂时不考虑这些问题,只着重于指出错误之处,除非是整句都有问题,否则就尽量避免重新翻译。

你能否举个具体的例子说一下,我们在哪些勘误条目的处理上还有待改进?我们也好举一反三。。。
同时也欢迎你以及更多的人参与到这项工作中来,宝剑锋从磨砺出,我们这样做也是为了让这本书能够更好地完成它的使命。
作者: 雨丝风片    时间: 2006-03-22 16:31
最新勘误:

【116页】上数第10行:(雨丝风片)
[本书]:
为了避免在一段地址范围内混入不相关地地址段,可以用子映射来覆盖那段地址范围。
[原文]:
To avoid intermixing of unrelated allocations within an address range, that range is covered by a submap, and only the appropriate subsystem can allocate from that map.
[雨丝风片]:
此处漏掉了最后半句话的翻译,影响了对句子完整意思的理解,前半句的翻译也不准确。全句的翻译应为:“为了避免各种不相关的分配混杂在同一个地址区间里,我们可以用一个子映射来覆盖这个区间,并且只有恰当的子系统才能在这个映射中进行分配。”
(注:即通过子映射来实现子系统级的专区专用。)
作者: moflin    时间: 2006-03-22 16:44
看了这个帖以后,打死我也不会买中文版了~~~
我打算买英文版或德文版.
作者: 雨丝风片    时间: 2006-03-22 16:48
原帖由 moflin 于 2006-3-22 16:44 发表
看了这个帖以后,打死我也不会买中文版了~~~
我打算买英文版或德文版.


贵啊!

勘误完成之后,中文版才能真正成为经典。。。
作者: bigheadfish80    时间: 2006-03-22 23:12
这本书有中文的卖了,今天在书城看到了,可惜看了下介绍的说适合高级的使用,我就没有买了。是人邮的翻译的。深圳好象来的比较迟了。

[ 本帖最后由 bigheadfish80 于 2006-3-22 23:17 编辑 ]
作者: 雨丝风片    时间: 2006-03-23 07:57
原帖由 bigheadfish80 于 2006-3-22 23:12 发表
这本书有中文的卖了,今天在书城看到了,可惜看了下介绍的说适合高级的使用,我就没有买了。是人邮的翻译的。深圳好象来的比较迟了。


出版社的“高级”的意思是告诉读者,阅读本书第一遍的时候可能需要仔细的勘误,
第一遍之后就无所谓高不高级了
作者: szjungle    时间: 2006-03-23 13:20
看了几章,觉得这本书翻译的水平很高,读起来很流畅。

上面列出的错误,有些是译者对一些字句的理解偏差造成的。而另外一些列出和没列出的一些错误,比如将 上写成下,I/O 写成 I/10,错字,掉字,我想是出版社录入和排版的责任。这么经典的一本书,没有经过认真校对就出版发行,的确很可惜。

不知道在下次印刷的时候,能不能把这里的勘误交给出版社?
作者: congli    时间: 2006-03-23 13:26
原帖由 szjungle 于 2006-3-23 13:20 发表
不知道在下次印刷的时候,能不能把这里的勘误交给出版社?

这个问题跟风雨讨论过,有这个打算.
作者: 雨丝风片    时间: 2006-03-23 13:29
原帖由 szjungle 于 2006-3-23 13:20 发表
看了几章,觉得这本书翻译的水平很高,读起来很流畅。

上面列出的错误,有些是译者对一些字句的理解偏差造成的。而另外一些列出和没列出的一些错误,比如将 上写成下,I/O 写成 I/10,错字,掉字,我想是出版社 ...


我们也是这样想的!这终究还是一本BSD内核方面的经典书籍,译者以一人之力能完成此书已属难得。我们在这里做勘误的目的也是想让这本书更完美一些,方便大家学习。等收集到一定程度之后就反馈给译者和出版社,
作者: ljoolj    时间: 2006-03-23 14:03
好同志啊....
作者: bigheadfish80    时间: 2006-03-23 14:51
原帖由 雨丝风片 于 2006-3-23 07:57 发表


出版社的“高级”的意思是告诉读者,阅读本书第一遍的时候可能需要仔细的勘误,
第一遍之后就无所谓高不高级了

汗一个先,可惜俺们就算第一遍仔细看也不一定能看到里面有的错误!!!
作者: 雨丝风片    时间: 2006-03-23 16:49
最新勘误信息:

【116页】下数第2行:
[本书]:
这段内核地址空间由子映射管理,子映射的头指向被引用的vm_map结构。
[原文]:
This piece of the kernel address space is being managed via a submap headed by the referenced vm_map structure.
[雨丝风片]:
这里译成“子映射的头指向。。。”不妥。子映射的vm_map结构体是由vm_map_entry结构体里的sub_map指针指向。由于作者此处在专讲vm_map_entry结构体,因此只是说这个子映射是由指向的vm_map结构体开始的,其完整意思应该是“这个子映射是由(vm_map_entry结构体中的sub_map指针)指向的vm_map结构体开始的。”


【117页】上数第5行:
[本书]:
虚拟内存系统实现了一套基本函数来分配和释放内核所使用的虚拟内存范围,这个范围有页对齐和页取整两种方式。
[原文]:
The virtual-memory system implements a set of primitive functions for allocating and freeing the page-aligned, page-rounded virtual-memory ranges that the kernel uses.
[雨丝风片]:
range直译为“范围”似觉不妥。整句可译为:“虚拟内存系统实现了一组基本的函数,用以分配和释放内核所使用的需要按页对齐和按页取整的虚拟内存区域。”
作者: 雨丝风片    时间: 2006-03-23 16:51
原帖由 bigheadfish80 于 2006-3-23 14:51 发表

汗一个先,可惜俺们就算第一遍仔细看也不一定能看到里面有的错误!!!


幸亏还有英文版流传,勘误才得以进行。
作者: 雨丝风片    时间: 2006-03-23 17:23
原帖由 ddcp 于 2006-3-23 15:44 发表
哪个蛤货翻译的,糟蹋原著,还卖70元钱,谢谢楼主,抵制这类白痴的中文版!




我觉得,这本书和那些十几个“人”拼凑起来的“机器翻译”作品还是不一样的,看得出来,作者还是花了很多心血的。以系统之庞大,单凭一己之力,恐难面面俱到、样样精通,难免会有略失水准的地方。我曾经试着翻译过这本书中的若干章节,深知其中字斟句酌的痛苦,因此,对于一些确实很难准确表达愿意的地方,我都能够理解译者的为难处境。但是不可否认,这本书缺乏严谨的校对,导致文中常常出现整句的缺失,甚至把“1 million” 译成“100”,失之毫厘,谬以千里,害人不浅。

我个人是最痛恨目前国内的翻译风气的,粗制滥造,触目惊心。所以我手头的书基本上都是英文的。无奈讲解BSD内核方面的资料实在不多,这一本是目前唯一覆盖整个系统的书籍,也算是一本经典了。虽然网上也有英文版流传,但毕竟不是人人都能找到,而且每个人阅读英文资料的能力也不尽相同。所以还是需要有这么一本中译本的。正是由于现实没有给我们太多选择的机会,所以我们只能着手对这本书的勘误。希望通过我们的努力,能够尽量纠正这本书中存在的错误,使其能够最大程度地传达原著的真实内容,方便大家对BSD的研究和学习。

我们在拒绝和勘误之间选择了勘误,第一次的阅读可能会很痛苦,需要仔细比对和原文的差异,但一旦勘误完成,中文版总是会体现出它比英文版更大的价值的。希望能有更多的朋友参与到勘误工作中来,只要在阅读过程中遇到了什么难以理解的地方,都可以提交到这里,以便其它的朋友能够据此改正书中内容。积累到一定程度之后我们再反馈给译者和出版社,以便在后来的版本中进行更新。


作者: bigapple2008    时间: 2006-03-24 16:23
是浙大的老师带着研究生翻译的,可能质量是不怎么样。都说翻译的不好
作者: 雨丝风片    时间: 2006-03-24 16:34
原帖由 bigapple2008 于 2006-3-24 16:23 发表
是浙大的老师带着研究生翻译的,可能质量是不怎么样。都说翻译的不好


你说的是【4.4BSD操作系统设计与实现】吧?这次的是一个人翻译的。
作者: 雨丝风片    时间: 2006-03-24 17:10
最新勘误信息:

【117页】倒数第16行:
[本书]:
可调页的地址范围是按需分配物理内存的,而且该内存可以由pageout(页面调出)守护进程回写到后备存储器上,这可以作为该守护进程的正常替换策略的一部分。
[原文]:
A pageable range has physical memory allocated on demand, and this memory can be written out to backing store by the pageout daemon as part of the latter's normal replacement policy.
[雨丝风片]:
首先,“按需分配”亦可理解为要多少给多少,不能准确传达原意。其次,将内存写出也不是“可以”作为替换策略的一部分,它本来就是一部分。整句另译如下:“可进行调页的区域是在需要的时候才分配物理内存的,作为常规替换策略的一部分,这种内存可由pageout daemon写出到备份存储中。”

【117页】倒数第11行:
[本书]:
kmemfree()回收内核中固定的内存
[原文]:
Kmem_free() deallocates kernel wired memory
[雨丝风片]:
函数名中遗漏了一个下划线。

【117页】倒数第6行:
[本书]:
因此,推荐用此方法分配内核内存而不是固定大小的大型结构,用下一节介绍的区域存储分配程序处理后者效果会更好。
[原文]:
So it is the preferred way to allocate kernel memory other than large, fixed-size structures that are better handled by the zone allocator described in the next subsection.
[雨丝风片]:
“内核内存”和“大型结构”之间是包含关系,这里却译成了互斥关系,完全看不到原文中“other than”的意思了。整句另译如下:“因此,除了大型的、固定尺寸的结构由下一节介绍的zone分配器来处理更为合适之外,分配内核内存应当首选这种方法。”
作者: linuxbao3    时间: 2006-03-26 05:02
所以我说,大家最好是看英文原版的
作者: gvim    时间: 2006-03-26 10:18
原帖由 linuxbao3 于 2006-3-26 05:02 发表
所以我说,大家最好是看英文原版的


有能力的你,为什么不尝试翻译一些文档?或者一起来找书的BUG?
毕竟人人都不是有你这样的英文水平。
作者: zhangluoer    时间: 2006-03-31 10:57
版主的说法还是比较真切的。同意版主的说法,我也买了这本书,但现在还没有到手。
有是有蚂蚁啃骨头的心理准备才买的这本书,另一方面也是对FreeBSD的喜爱。
我这里有此书的电子文档,是.chm格式的。不知能不能放到论坛上来,可以和大家共享此书。
作者: lijichao    时间: 2006-03-31 11:43
原帖由 linuxbao3 于 2006-3-26 05:02 发表
所以我说,大家最好是看英文原版的

你觉得现在大学生的英语真实的水平怎么样???
作者: 雨丝风片    时间: 2006-03-31 12:48
原帖由 zhangluoer 于 2006-3-31 10:57 发表
版主的说法还是比较真切的。同意版主的说法,我也买了这本书,但现在还没有到手。
有是有蚂蚁啃骨头的心理准备才买的这本书,另一方面也是对FreeBSD的喜爱。
我这里有此书的电子文档,是.chm格式的。不知能不能 ...


多谢支持!
至于电子书籍,这种资料的获取还是各人随缘吧,不宜在此公开分享。
作者: liubingqian    时间: 2006-03-31 21:46
把帖子置顶吧。这里水大,太容易沉下去了。
作者: zero-B    时间: 2006-04-01 01:51
我没找到这书的电子版,兄弟你有吗?
作者: 雨丝风片    时间: 2006-04-04 07:54
原帖由 zero-B 于 2006-4-1 01:51 发表
我没找到这书的电子版,兄弟你有吗?


把你的邮箱发给我吧!
作者: 雨丝风片    时间: 2006-04-04 08:55
最新勘误信息:

【118页】倒数第10行:(雨丝风片)
[本书]:
存储分配程序的速度慢还会造成另一个问题,就是让那些频繁使用内核接口的程序员放弃把存储分配程序作为首选方法,而代之以通过维护他们自己的内存分配池来创建自己的存储分配程序。
[原文]:
Another problem with a slow memory allocator is that programmers of frequently used kernel interfaces will think that they cannot afford to use the memory allocator as their primary one. Instead, they will build their own memory allocator on top of the original by maintaining their own pool of memory blocks.
[雨丝风片]:
这一节讲的是内核的内存分配程序,而不是用户级的内存分配程序,受其影响的自然也应当是内核程序员,而非用户级的程序员。“那些频繁使用内核接口的程序员”应译为“那些会被经常用到的内核接口的程序员”。


【118页】倒数第7行:(雨丝风片)
[本书]:
如果它们都有自己的空闲链表,那么两个链表所关联的内存总和就是两个子系统分别运行时所使用的内存之和的最大值。而如果它们共享一个空闲链表,则两个链表所关联的内存总和就可能是同两个子系统分别运行时使用内存最多的那个子系统的一样。
[原文]:
If they have their own free lists, the amount of memory tied up in the two lists will be the sum of the greatest amount of memory that each of the two subsystems has ever used. If they share a free list, the amount of memory tied up in the free list may be as low as the greatest amount of memory that either subsystem used.[雨丝风片]:
这一段把“和”和“最大值”译得比较混乱,不能清晰地表达出愿意。这段的意思就是讲甲、乙两个子系统各有各的空闲队列,于是甲的空闲块不能给乙用,乙的空闲块不能给甲用,这就造成了空闲块的浪费。原文另译如下:如果它们都有自己的空闲链表,那么这两个链表所占据的内存数量就是每个子系统曾经使用过的最大内存数量的和。如果它们共享一个空闲链表的话,这个空闲链表占据的内存数量就只相当于内存用量最大的那个子系统的值了。
作者: 雨丝风片    时间: 2006-04-04 19:58
最新勘误信息:

【119页】上数第2行:(雨丝风片)
[本书]:
通常,这个区域会返回一块可以使用的内存。只有当区域内所有的内存块都已经投入使用的时候,区域存储分配程序才会再创建一组内存区域。
[原文]:
Usually, the zone will have an available piece of memory that it can return. Only if every piece of memory in the zone is in use will the zone allocator have to do a full allocation.
[雨丝风片]:
这两句译得离原意太远了。另译如下:一般情况下,区域内都能够找到一块可供返回的内存。仅当区域内的所有内存块都已被使用时,区域分配器才会进行一次完整意义上的分配。


【119页】上数第9行:(雨丝风片)
[本书]:
此时的分配算法就切换到速度较慢,但是对于分配大于一页的内存效率比较高的策略上来。2-幂算法分配大小为1、2、4、8、...,n个页面,而大块算法按页面倍数分配内存,分配大小为1、2、3、4、...,n个页面。
[原文]:
The algorithm switches to the slower but more memory-efficient strategy for allocation sizes larger than a page. This value is chosen because the power-of-2 algorithm yields sizes of 1, 2, 4, 8, . . ., n pages, whereas the large block algorithm that allocates in multiples of pages yields sizes of 1, 2, 3, 4,. . ., n pages.[雨丝风片]:
此处完全把前后语句的因果关系给译没了,使人不知所云。另译如下:如果分配的尺寸大于一个页面,算法就会切换成比较慢的但内存效率却更高一些的策略。之所以选择这个数值,是因为2-幂算法此后分配的尺寸将是1、2、4、8、...、n个页面,而大块算法则将按页面的整数倍分配1、2、3、4、...、n个页面。
作者: 雨丝风片    时间: 2006-04-05 17:29
最新勘误信息:
【119页】上数第14行:(雨丝风片)
[本书]:
首先把需要分配的大内存取整为页面大小的倍数.
[原文]:
Large allocations are first rounded up to be a multiple of the page size.
[雨丝风片]:
应把"向上"取整的含义明确地译出来:大型的内存分配首先会被向上取整为页面尺寸的倍数.


【119页】上数第19行:(雨丝风片)
[本书]:
因为在释放一块内存时并不指定其大小,所以分配程序需要一直跟踪其所释放的内存片的大小.
[原文]:
Because the size is not specified when a block of memory is freed, the allocator must keep track of the sizes of the pieces that it has handed out.
[雨丝风片]:
此处把hand out译为释放简直就是颠倒黑白.另译如下:由于在释放一块内存的时候不会指定其大小,因此分配程序必须对它分配出去的内存块的尺寸进行跟踪.


【119页】倒数第12行:(雨丝风片)
[本书]:
如果采用太过标准的策略,那么这些分配请求的内存就会增加一倍.
[原文]:
The size of these requests would be nearly doubled if the more typical strategy were used.
[雨丝风片]:
"the more typical strategy"显然是有所指的,它说的就是前面提到的按2的整数次幂的分配策略,此处译为"太过标准的策略"反而不知所云了.另译如下:如果采用那个较为典型的策略,这些请求的尺寸就会被扩大为原来的两倍.


【119页】倒数第1行:(雨丝风片)
[本书]:
它们往往会被放大,因而容易浪费空间.
[原文]:
They tend to be large and hence wasteful of space.
[雨丝风片]:
不知"放大"从何说起?另译如下:它们可能会很大,从而浪费空间.


【120页】上数第2行:(雨丝风片)
[本书]:
因为它们个个都会浪费内存,它们浪费的内存加到一起就会比纯粹的内存用量大得多.
[原文]:
Because they are individually wasteful of space, collectively they waste too much space compared to a denser representation.
[雨丝风片]:
什么是"纯粹的内存用量"?不知所云.另译如下:因为它们各自都很浪费内存,和紧密的内存分配方式比起来,它们总共浪费的内存就太多了.


【120页】上数第15行:(雨丝风片)
[本书]:
会超过把它们放入完整的内存池在效率上获得的好处.
[原文]:
outweighs the efficiency gains from keeping them in the general pool.
[雨丝风片]:
"完整的内存池"为何物?此处显然说的是不区分大小和类型的"大杂烩"内存池,应译为"通用内存池".
作者: vity    时间: 2006-05-19 23:35
作者的逻辑性很强。每天坚持看两个小时,豁然开朗.
    长句子特别多,刚一读,还是要结合上下文反复看看,才搞清楚关联关系。
        看到,P56第二段,说过去gid是怎么实现的,怎么不说现在的了?是不是“分析旧版本bsd的多些”?
            希望高手搞个什么学习话题,针对里的内容持续讨论分析,带领大家学学,结合系统,给些更多实例和更直观的讲解。

[ 本帖最后由 vity 于 2006-5-20 15:38 编辑 ]
作者: gvim    时间: 2006-05-19 23:41
原帖由 vity 于 2006-5-19 23:35 发表
作者的逻辑性很强。每天坚持看两个小时,豁然开朗.
    长句子特别多,刚一读,还是要结合上下文反复看看,才搞清楚关联关系。
        看到,P65第二段,说过去gid是怎么实现的,怎么不说现在的了?是不是“分析 ...


65页没有看到有关gid的说明。(我的中文版)

[ 本帖最后由 gvim 于 2006-5-19 23:43 编辑 ]
作者: 雨丝风片    时间: 2006-05-20 07:56
原帖由 vity 于 2006-5-19 23:35 发表
作者的逻辑性很强。每天坚持看两个小时,豁然开朗.
    长句子特别多,刚一读,还是要结合上下文反复看看,才搞清楚关联关系。
        看到,P65第二段,说过去gid是怎么实现的,怎么不说现在的了?是不是“分析 ...


我们一直在琢磨究竟以什么方式来读这本书比较好,总得来说,泛泛地去读还是不行,最好还是以专题的形式,最好是有具体的问题,这样大家才有兴趣去钻研,才有兴趣去仔细研读这本书和相关代码。

你推荐几个好的专题吧!^_^
作者: gvim    时间: 2006-05-20 16:22
可以参考该书4.8节和APUE2nd的相关章节

勘误不完全,这里只是包含了进程与内存两部分的,其余部分至少我没有去校对(当然,如果有更多的人参与校对,是件好事情),因为我还没有看到那去,呵
作者: jervis0211    时间: 2006-05-20 19:16
楼上的什么意思呀?解释一下
作者: vity    时间: 2006-05-31 21:03
讲讲第六章I/O和第七章设备吧,解释一下编译内核所需的内核配置文件。
比如现在的计算机 I/O 体系,各种总线,总线连接什么接口,挂什么设备,系统怎么驱动,揭开系统底层的一些面纱。这是不是也和程序开发相关?
我以前不怎么关心硬件的,都是 Windows 的遗毒!现在正看总线,接口,主板什么的,结合书看看。
作者: antijp    时间: 2006-06-10 17:41
The signal implementation has changed significantly. Some of the description doesn't fit the current code. For example, the psignal()[in the file /sys/kern/kern_sig.c] routine does much less than the description.
作者: 玄鹤    时间: 2006-06-22 11:21
都是好人啊
作者: wanghl    时间: 2006-06-26 16:22
顶出水面!
作者: billypeng    时间: 2006-08-05 15:43
标题: 回复 1楼 雨丝风片 的帖子
我也看了这本书。

也发现一些问题:
[260页] 表中,pagedep   根据(应该为跟踪)目录块的依赖关系。
[261页] 16行,软共享(应该为更新)代码。
        19行原文:The ATTACHED flag shows that the buffer with which the dependency structure is associated is not currently being written.
             书中翻译为:ATTACHED这个标志表明,当前没在把依赖关系所关联的缓冲区写入磁盘。
         本人认为,该中文意思没有表示进行时态,应该翻译为:
          ATTACHED这个标志表明,当前没有处在把依赖关系结构所关联的缓冲区写入磁盘的过程中。
作者: japonensis    时间: 2006-09-01 09:52
466页,表14.3,例程 procO_init()应该为proc0_init()
0错印成O 了
作者: 雨丝风片    时间: 2006-09-01 16:59
原帖由 billypeng 于 2006-8-5 15:43 发表
我也看了这本书。

也发现一些问题:
[260页] 表中,pagedep   根据(应该为跟踪)目录块的依赖关系。
[261页] 16行,软共享(应该为更新)代码。
        19行原文:The ATTACHED flag shows that the buff ...


原帖由 japonensis 于 2006-9-1 09:52 发表
466页,表14.3,例程 procO_init()应该为proc0_init()
0错印成O 了



非常感谢billypeng和japonensis的贡献!已经把你们的勘误添加到1楼,
作者: 77776666    时间: 2006-10-18 17:50
原帖由 colddawn 于 2006-3-21 13:48 发表
留地址,我发给你们

你好.麻烦你给我发下.
donggua.30@gmail.com
作者: hardboy_du    时间: 2006-11-22 10:43
hardboy_du@163.com,麻烦了,找了好久也没找到
作者: 勇者威廉    时间: 2006-11-22 12:19
楼主做了件伟大的事。
作者: zhangweizj    时间: 2006-12-09 18:30
好,辛苦了

[ 本帖最后由 zhangweizj 于 2006-12-9 18:51 编辑 ]
作者: whoto    时间: 2006-12-12 23:16
原帖由 雨丝风片 于 2006-3-20 09:01 发表
【前言5页】上数第6行:(雨丝风片)
[本书]:
以及4CD套装,其中包含伯克利的所有BSD版本和BSD源代码的受控史。
[原文]:
and a 4-CD set containing all the release and the source-control history of BSD from Berkeley.
[雨丝风片]:
我看到这里,吓了一跳,以为是BSD源代码“受到控诉的历史”。去查原文,才发现是source control历史,此处当指整个Berkeley时期的BSD版本控制系统生成的代码修改记录等历史信息。所以我觉得译文应当是“以及一套由Berkeley提供的含有BSD所有发布版本和源代码控制历史的4CD套装。”
...


乍一看以为以为买书还有4-CD送呢,难道让书店给黑了?原来是到这个网站定购
作者: 雨丝风片    时间: 2006-12-12 23:36
原帖由 whoto 于 2006-12-12 23:16 发表
乍一看以为以为买书还有4-CD送呢,难道让书店给黑了?原来是到这个网站定购



BSD的代码修改记录目前只能追溯到FreeBSD诞生的时候,CSRG的活动仍然属于史前时代。

俺没钱,否则把这些CSRG的修改记录都搞到的话,很多疑难问题相信都能从版本的演变中找到答案了。
作者: isjfk    时间: 2006-12-13 09:11
原帖由 雨丝风片 于 2006-12-12 23:36 发表



BSD的代码修改记录目前只能追溯到FreeBSD诞生的时候,CSRG的活动仍然属于史前时代。

俺没钱,否则把这些CSRG的修改记录都搞到的话,很多疑难问题相信都能从版本的演变中找到答案了。

McKusick 那家伙好像卖这些东东,要不咱们凑钱买他一套

https://www.mckusick.com/csrg/cdorderform.html

靠,$99,不便宜呀...
作者: mingyanguo    时间: 2006-12-13 09:22
凑钱买了好说,主要是版权问题阿,如果凑钱买了,大家都能拿到一份拷贝就值了,否则太贵了。
作者: isjfk    时间: 2006-12-13 09:39
楼上最近对版权怎么这么热心?

https://www.mckusick.com/csrg/cdorderform.html
You may freely redistribute it to anyone else. However, I would appreciate your buying your own copy to help cover the costs that I incurred in producing the archive.

作者: mingyanguo    时间: 2006-12-13 10:26
不是,其他人的版权可以不关心,但是,作为BSD的爱好者,如果破坏BSD元老的版权,怎么都说不过去的。
刚刚看了,没有这个问题,版上的人凑钱买来然后复制是个不错的主意。
作者: isjfk    时间: 2006-12-13 10:32
如果能凑齐十个人,平摊到每个人的费用大概就在 120~150 之间,我想还是可以接受的。

我这里还有 4.4BSD Lite 和 Lite2 的源码,哈哈~
作者: gvim    时间: 2006-12-13 11:17
好提议,,,虽然我不是强烈的BSD历史爱好者,不过能搞一份拷贝回来收藏也是不错。 算我一个吧

看了M老大的FreeBSD视频教学 ... 2495刀, 忍了
作者: 雨丝风片    时间: 2006-12-13 11:29
不错!俺早就对Mckusick卖的东西感兴趣了,除了CSRG的修改记录,还有FreeBSD内核的教学视频。。。大家合计合计,只要M老大说可以freely redistribute,咱们就凑钱搞他一套!

还有,怎么操作的问题?谁有跨洋血拼的经验?
作者: isjfk    时间: 2006-12-13 11:45
怎么付款是个问题,还有兑换外币。不知道谁有这方面的经验?
作者: gvim    时间: 2006-12-13 11:59
原帖由 雨丝风片 于 2006-12-13 11:29 发表
不错!俺早就对Mckusick卖的东西感兴趣了,除了CSRG的修改记录,还有FreeBSD内核的教学视频。。。大家合计合计,只要M老大说可以freely redistribute,咱们就凑钱搞他一套!

还有,怎么操作的问题?谁有跨洋血 ...


视频实在太贵了。
团体使用$1995+$2495, 个体使用$995+$1495
强烈期待人民币增值(美元贬值)
作者: mingyanguo    时间: 2006-12-13 12:17
原帖由 雨丝风片 于 2006-12-13 11:29 发表
不错!俺早就对Mckusick卖的东西感兴趣了,除了CSRG的修改记录,还有FreeBSD内核的教学视频。。。大家合计合计,只要M老大说可以freely redistribute,咱们就凑钱搞他一套!

还有,怎么操作的问题?谁有跨洋血 ...

CSRG的还好,那个视频教学恐怕不能freely redistribute,我看到个人用户与公司用户的价钱都是不一样的.
作者: gxguax    时间: 2007-01-15 14:34
标题: 顶一下.
此贴勿沉啊.
顶一下....
作者: Animatrix    时间: 2007-05-15 10:17
ding~~俺买了还未仔细阅读…
作者: snow888    时间: 2007-05-15 10:28
原帖由 zhangluoer 于 2006-3-31 10:57 发表
版主的说法还是比较真切的。同意版主的说法,我也买了这本书,但现在还没有到手。
有是有蚂蚁啃骨头的心理准备才买的这本书,另一方面也是对FreeBSD的喜爱。
我这里有此书的电子文档,是.chm格式的。不知能不能 ...


放上来啊,我们正需要!
作者: snow888    时间: 2007-05-15 10:30
原帖由 雨丝风片 于 2006-4-4 07:54 发表


把你的邮箱发给我吧!



雨丝大大,我的电子邮箱:

yyworkroom@sina.com

最好是中英文的都给我一份,我也来核对一下看看。

水平有限,但热情很高哈。

^_^.
作者: RainFlying    时间: 2007-05-15 10:34
原帖由 bigapple2008 于 2006-3-24 16:23 发表
是浙大的老师带着研究生翻译的,可能质量是不怎么样。都说翻译的不好

浙大的老师翻译过<4.4BSD的设计与实现>麽?
<Oprating System Concept>倒是浙大的老师翻译过的
不过很多情况下都是学生翻译之后然后让老师挂个名出版的
作者: RainFlying    时间: 2007-05-15 10:35
我也要份中文和英文的电子书吧
rainflying302@gmail.com
作者: missjiang    时间: 2007-05-15 13:06
原帖由 RainFlying 于 2007-5-15 10:34 发表

浙大的老师翻译过<4.4BSD的设计与实现>麽?
<Oprating System Concept>倒是浙大的老师翻译过的
不过很多情况下都是学生翻译之后然后让老师挂个名出版的

一般来说,如果老师挂名学生翻译,最后老师会在序言中提及学生的工作并表示感谢,比如《4.4BSD的设计与实现》的前言:
《4.4BSD的设计与实现》的翻译和校对工作由我和我的学生刘文峰、马天驰、尹奇、王伟波,以及王焕龙、彭刚、金海荣、张玉龙、胡玉杰、谢科先、虞浩泽、单宏伟、倪昕、彭瑞、秦延涛、胡斌、雍国恩、王鹏、张继南等共同完成。虽然经过我们的努力,稿件仍会存在这样那样的问题,但我们大家都付出了、尽力了。


多个老师挂名学生翻译的书籍难以保证质量,china-pub上的关于44BSD的中文版和英文版的销售情况的对比反映了读者的看法:
4.4BSD操作系统设计与实现(中文版) 特价中


4.4BSD操作系统设计与实现(英文影印版)绝版

中文版由于卖不动不得不特价处理,英文版由于读者的踊跃购买成为绝版,这是否也从侧面说明了一些问题呢?

《FreeBSD操作系统设计与实现》在前言和序言中没有提及其他参与翻译工作的人,应该是一个人翻译的,如果老师挂名学生翻译,而最后老师在序言中都不提学生的名字的话,那就有点说不过去了。

我的老板也做过这样的事情,收到出版社的书后,找了7、8个师兄,每人分分工,平均每人翻译1章多一点,他自己也翻译一点,所有人的翻译初稿出来后,老板找了一个各方面水平都较高的师兄进行整合,最后他自己再审核一遍就OK了。

毫无疑问,承担具体工作的学生是不可能作为这本书的译者,参与的师兄只是在序言中被老板一句带过:“我的学生xxx、xxx、xxx、...也参与了部分翻译和校对工作”(注:因为他自己也翻译了一两章,所以是师兄们只做了部分工作)。不过其它的老师也是这么做的,也就见怪不怪了,好在我们老板还不算太抠门,给了参与翻译工作的同学1000多元的劳务费,最后完成整合工作的师兄有2000块拿。

我有FreeBSD这本书,总体来说翻译的比较认真,可以考虑购买,如果勘误工作做的比较好,它会成为经典的。最后个人对雨丝风片以及gvim做的工作表示感谢,好像gvim在china-pub上把书中的错误反馈给了作者,这项工作很有意义,值的鼓励!

[ 本帖最后由 missjiang 于 2007-5-15 13:17 编辑 ]
作者: PCOS    时间: 2007-05-15 18:36
原帖由 isjfk 于 2006-12-13 10:32 发表
如果能凑齐十个人,平摊到每个人的费用大概就在 120~150 之间,我想还是可以接受的。

我这里还有 4.4BSD Lite 和 Lite2 的源码,哈哈~

大侠:能发份源码给我吗?电邮COS@TOM.COM 谢了!
作者: wangbin    时间: 2007-05-16 01:49
支持楼主的严谨态度,值得学习!!
作者: 坏坏小少    时间: 2007-08-08 10:34
56页的表3.2第四五条有问题

应该按照下面这个才符合文意
Action
Real
Effective
Saved
1. exec-normal
R
R
R
2. exec-setuid
R
S
S
3. seteuid(R)
R
R
S
4. seteuid(S)
R
S
S
5. seteuid(R)
R
R
S
6. exec-normal
R
R
R
Key: R—real user identifier; S—special-privilege user identifier.

作者: Archx    时间: 2007-09-15 17:22
可不可以给我一份译本的拷贝,谢谢。
archx#163/com
作者: Godbach    时间: 2007-09-26 23:03
4.4BSD的这本偶算是搞到了




欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2