From Fedora Project Wiki

Fedora 新闻周刊第 115 期

欢迎阅览 Fedora 新闻周刊第 115 期，记载自 2008-01-07 起一周事件。本页永久链接为 http://fedoraproject.org/wiki/zh_CN/FWN/Issue115

本周的主要内容有：

“公告”部分，MaxSpevack 做出了一份特别的通告，“Fedora 继往开来”

“博客聚集”部分，包含“交接”，“Fedora 营销重组”，“致 FUDCon 所有参与者”，“FUDCon 2008 - 第一日”和“FUDCon 2008 - 第二日”

要参与我们或给出反馈，请访问 。


公告

原文请查看

Fedora 继往开来

MaxSpevack announces in fedora-announce-list[1] ,

"将有超过150的人来参加周六的FUDCon，它将是一个盛大的会议。这次的开放话题将是我一年一次的"State of Fedora"演讲。我认为这个一定会被录制下来并最终放到网上的，不过还是先让我来和你们分享一些细节吧。"

"我很高兴的宣布，PaulFrields接受了Red Hat的工作，他将在二月份作为Fedora Project Leader掌管这些工作。"

"另外，最近JackAboutboul已经成为了一名全职的Red Hat的品牌营销交流人员。我们已经邀请Jack来担任Fedora营销，社区建设以及大使方面的领导工作了。"

https://www.redhat.com/archives/fedora-announce-list/2008-January/msg00003.html

Fedora 博客聚集

原文请查看

交接

MaxSpevack points out in his blog[1] ,

"当Paul在二月份接替我担当Fedora Project Leader后，我将仍为Fedora方面的事情工作。接下来的一两个月我主要将协助Paul来适应这个工作，特别是接下来的几周，Paul还要给他在加入Red Hat以前的工作收尾的这个阶段。"

[1] http://spevack.livejournal.com/42900.html

Fedora 营销重组

KarstenWade points out in his blog[1] ,

"作为我的航班前最后一个hackfest，我们和Red Hat的发言人Leigh Day谈到Fedora 营销的问题。她正领导着一个微型思想会议，内容包括围绕我们的所有事情，从我们的交流机制到如何计划和处理这些事情等等。"

[1] http://iquaid.org/2008/01/13/fedora-marketing-revitalization/

致 FUDCon 所有参与者

JonRoberts points out in his blog[1] ,

"我知道每个人都很忙，而且今天是最后一天，不过如果有人愿意花一点时间来回答一些关于他们进展如何的问题的话，那就太好了。希望这些信息能够促进Fedora的发展以及让每个人都能很好的工作。我将在晚些时体会提一些特定的问题，祝大家愉快！顺便提一下，如果你有时间的话，回复营销列表上的那些问题，回复到我的email或者我的blog上都可以。"

[1] http://blog.questionsplease.org/2008/01/13/to-all-fudcon-attendees/

FUDCon 2008 - 第二日

ChrisTyler points out in his blog[1] ,

“FUDCon的第二天终于到来。很高兴看到曾经只是hackergotchi头像或IRC昵称的人。”

[1] http://blog.chris.tylers.info/index.php?/archives/100-FUDCon-2008-Day-2.html

FUDCon 2008 - 第一日

JefSpaleta points out in his blog[1] ,

"这是第一天的一些照片。第一张是今早在hackfest分组之前的拍的："

[1] http://jspaleta.livejournal.com/17056.html

营销

原文请查看


Fedora 更换项目领导人

RahulSundaram reports in fedora-marketing-list[1] ,

"不为Red Hat工作的Paul竟然会对Red Hat产生这么大的影响，是不是很令人感兴趣？这就是开源的力量。比官僚主义优秀多了。"

[1] https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg00074.html

FUDCon 洛利(Raleigh 2008)视频

RahulSundaram reports in fedora-marketing-list[1] ,

"这是一周摘要的特别制作版，在N.Carolina的Raleigh召开的FUDCon完成的。这部录像能让你了解FUDCon是如何运作的以及参与的。"

[1] https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg00070.html

开发

原文请查看

The X-orcist: Driver Slasher!

作为清除工作的一部分，AdamJackson在移植到新的服务API时提交[1] 了针对移除特定的Xorg驱动程序的反对意见的征求计划书。Adam列出了将要移除的名单：avivo (ATI R500+芯片将使用radeon或者radeonhd); s3; vga; ark; chips and tseng。Adam希望那些有意见的人就赶紧提出来。

[1] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00847.html

The chips driver for C&T 65xx mode[2] was declared[3] by AlanCox to be essential to the small LCD displays which are common on low-power boxes and for which VESA is unable to correctly set the modes. Alan offered to test or debug as required. Adam promised[4] "chips will be spared from the coming apocalypse."

[2] "Chips and Technology" http://en.wikipedia.org/wiki/Chips_and_Technologies

[3] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00852.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00858.html

The next two objections seemed to be false alarms. WarrenTogami was worried[5] about both the AMD Geode driver and the s3 driver as the former was used by the OLPC and the latter by Intel's "Affordable PC". ThorstenLeemhuis corrected[6] this with the information that the APC actually used the "SiSM661GX [which] is driven by xorg-x11-drv-sis" and AdamJackson confirmed[7] this and also clarified that the AMDGeode was not going to be dropped. HansdeGoede noted[8] however that the vesa driver would not be able to handle pre-Virge cards contrary to Adam's plan as their BIOSes had no VESA support.

[5] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00930.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00941.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00983.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00943.html

A plea to save the tseng driver came[9] from FelixMiata. He outlined their usefulness for upgraders with only a PCI and no AGP slots. In the end Adam agreed to do his best to port all the drivers (as a low priority task) as there had been requests to retain them. ChristopherAillon and AlanCox nevertheless vied[11] to name the promised purge.

[9] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00935.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01058.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01051.html

呼吁选择一个替代的初始化脚本

当EricTanguy请求[2] 讨论Mudur-一个叫Pardus[3] Trukish GNU/Linux版本时，引发了另外一个关于如何减少初始化时间的讨论(见FWN#111"Fedora 8启动速度"[1] )。这个项目的网页认为磁盘I/O是一个有限资源，使用Python重写的启动脚本能够并行运行从而避免不必要的I/O，从而解决问题。Pardus并没有替换initd。

[1] http://fedoraproject.org/wiki/FWN/Issue111#head-2fa65b1cb87233afa6584ff976a30ded300fab7e

[2] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00460.html

[3] http://www.pardus.org.tr/eng/projeler/comar/SpeedingUpLinuxWithPardus.html

CaseyDahlin responded[4] that he had been working on a parallel boot system, rrn, which provided dbus notifications of starting services, retains 'initd' and is compatible with SysV initscripts. (A FUDCon[5] session was planned for rrn). Casey was skeptical about the use of Python, preferring Haskell, but agreed that BASH ran many other programs causing extra I/O.

[4] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00484.html

[5] http://barcamp.org/FUDConRaleigh2008

JonathanUnderwood asked why upstart had not been chosen as a replacement and Casey provided[6] the information that discussions on the subject (he included a link to the wiki entry) had preferred prcsys but that its use of pthreads and lack of dbus functionality had inidcated a rewrite would be useful. Jonathon thought[6a] that the current roadmap for "upstart" obviated many of those objections.

[6] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00490.html

[6a] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00558.html

NicolasMailhot wished[7] that any replacement init system would also take care of session initiation and LinusWalleij provided[8] a link to the InitKit project at Freedesktop.org. Casey investigated this and later reported[8a] that InitKit plans solely to create a standard for even-based activation to provide a common target for dependent software. No actual code is specifically planned to come from InitKit.

[7] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00506.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00518.html

[8a] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00918.html

A name-change was suggested by LeszekMatok due to both the sound and a potential namespace pollution. Casey explained[9] that it stood for "Resolve/Run/Notify" but took the points on board.

[9] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00579.html

The suggestion that Haskell might be used was ridiculed by DimiPaun who pointed out that any language chosen should be widely known by sysadmins and that it would be better to use C if the init scripts were to be rewritten. YaakovNemoy accepted the obscurity argument but argued[10] Haskell's advantages over Python, pointing out that Haskell needed no VM and instead is compiled to native machine code. NilsPhilippsen thought[11] that requiring a compiler collection merely to boot a machine needed much justification.

[10] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00545.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00569.html

The use of any dependency bloating requirements such as PERL or Python was considered[12] a non-starter by EnricoScholz. YaakovNemoy responded[13] that Python was installed on most machines and that the combination of Bash with awk, grep and other tools most definitely was. Yaakov called for comparative measurements of the time taken and number of kilobytes read during startup by the current system and one that starts python. Enrico pointed[14] to over 50% of his machines not using Python and MattMiller's disbelief that YUM (and hence python) was installed on less than half was answered[15] by DanielBerrange with the information that "stateless" installs or VM "appliances" do not require YUM.

[12] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00505.html

[13] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00541.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00551.html

[15] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00582.html

The use of an initscript which required anything outside of POSIX was anathema to RalfCorsepius. NilsPhillipsen responded[16] that he could see no way of removing the numerous forks and exec()s within the current SysV framework. Casey and YaakovNemoy thought that Ralf's argument that a bare-bones POSIX should be adhered to was a nearly religious one. Ralf backed[18] up his argument with reference to SuSE's initscript changes.

[16] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00572.html

[17] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00826.html

[18] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00829.html

The suggestion of HorstvonBrand was that service dependencies should be considered and AndrewFarris largely agreed[19] but thought that Horst's specific suggestion that a webserver should be prevented from running if there were no network was wrong. An interesting subthread developed in which the hanging of network services due to DNS lookups failing when there is no network developed.

[19] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00860.html

The suggestion that daemons could be changed to become non-forking and thus avoid having to use Python was made[20] by Enrico and this led to an informative exchange. NilsPhilippsen riposted[21] that Enrico's scheme only handled the subset of daemons which used pidfiles and that Python was not irretrievably bloated. JamesAntill confirmed[22] that a "core" python could be a fraction of the current size, but cautioned that it would be a lot of work to sort out the dependencies. Enrico responded[23] with an estimate of the size of a slimmed down bash and arguments that suggested that pidfiles were an anachronism required by initsystems with forking daemons. Nils seemed to rebut[24] most of these points, arguing that PIDs of processes could change and that python's size had been demonstrated to be of similar magnitude to bash's. Enrico countered[25] this by noting, among other things, that fork() and exec() performance were dependent on the particular program being executed and that a distinction needed to be drawn between first startup (which is not that important) and subsequent instances. This exchange continued a little further without apparent resolution or clarity.

[20] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00619.html

[21] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00624.html

[22] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00739.html

[23] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00633.html

[24] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00642.html

[25] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00650.html

A suggestion was made[26] by CaseyDahlin to consider the use of busybox to replace bash and its attendent required programs. KevinKofler worried[27] that the number of forks would remain the same and wondered whether a "shell which emulates POSIX process handling in-process and uses direct builtin function calls for commands like sed rather than forking a new process [...] could work," but worried that maintainability would suffer due to the need for special-case code to handle pipes and other necessary features. Both Casey[29] and AlanCox[30] noted that the fork was less of an issue than the execve due to disk IO. Alan suggested Plan9's rc or ash, but BillNottingham reported[31] that ash had been benchmarked and shown to be unpromising.

[26] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00607.html

[27] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00611.html

[28] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00611.html

[29] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00612.html

[30] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00632.html

[31] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00677.html

A skeptical evaluation of initng was posted by LennartPoettering who seemed inclined[32] towards favoring upstart but thought it was a bit of a moving target "in short: initng is a joke, initkit not ready yet, upstart a bit of a moving target that's going to be replaced soon anyway. The other systems seem to be too simple (minit, runit) or totally un-Linuxish (SMF, launchd)." Lennart preferred the idea of following Debian's lead and implementing LSB headers "to allow parallel startup" and Casey responded[33] that Fedora should "commit to that outright, and not let ourselves sit on our asses for another 5 years while everything blows by."

[32] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00666.html

[33] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00675.html

Casey made the excellent point that Fedora is supposed to be a showcase for innovation and that he had attempted to move forward with rrn (based on discussion with HaraldHoyer) and this was now apparently not desired. He exhorted fellow contributors to pick firm goal so that someone could do the work and expressed the willingness to do it himself as long as there was an agreed target.

Firewire(火线), Choice And Fedora

这个星期的大奖颁发给了HansdeGoede,一个从抱怨[1] firewire(IEEE 1394)支持退步开始起家的人。Hans在想内核中的juju栈的实现去除了旧栈的支持好不好，主张使用一种开关程序以提供对两种栈的支持。作为Fedora过于"bleeding edge"的附加证据，他在PulseAudio bugzilla上指出了这一点，言语中还透露着一丝不快。ThorstenLeemhuis表示同意(出了PulseAudio)并拿hplip来作比较［2］。他说，"Linux的本质是选择",很不同意Fedora项目的这种做法，还比如Xgl以及最新的Zope/Plone。

[1] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00845.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00848.html

Hans' original firewire concerns spawned a mostly technical thread while his more general complaint and Thorsten's amplification of it gave rise to a very wide ranging, voluminous argument. The firewire issue was directly addressed[3] by WillWoods who posted that a fix had already gone into Fedora 7 and Fedora 8, due in no small part to the feedback received by making the Juju stack available in Fedora. Information[4] from KrzysztofHalasa and JarodWilson suggested that Hans' "Via vt 6306" controller should work in OHCI-1.1 mode and Hans offered to help test a rawhide kernel built with some of the upstream linux1394 tree when it was ready.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00851.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01029.html

The idea that "Linux is about choice" was roundly rebuffed[5] by AdamJackson in a longish, impassioned post which argued that too much choice increased the failure rates combinatorially: "If I could only have one thing this year, it would be to eliminate that meme from the collective consciousness. It is a disease. It strangles the mind and ensures you can never change anything ever[...] "

There was lots of (dis)agreement on this point especially between DavidZeuthen in agreement and PatriceDumas arguing in favor of more diversity. It was mildly heated and led David to accuse[6] Patrice of "screw[ing] up the SN ratio of this list even more". David wondered why he (David) was even on the list anymore.

[5] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00988.html

使用Type1字体的应用程序应该升级到OTF

PatriceDumas建议[1] 应该介绍一些方法来处理未通过fontconfig注册的字体。Patrice审查了那些通过t1lib来使用Type1字体的包，认为Debian包defoma[2] 可能会是一个解决办法。

[1] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01046.html

[2] DEbian FOnt MAnager http://packages.debian.org/unstable/admin/defoma

KellyMiller was horrified[3] and cited his negative experiences with defoma, including Xorg locking during startup, as a prime motivator in switching to Fedora. In response to MatejCepl Patrice clarified[4] that there was nothing wrong with fontconfig except that some applications, specifically grace, xglyph and xdvi, did not use it. Patrice noted that it might be better to port t1lib to use fontconfig instead of adding defoma.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01048.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01113.html

A long-term perspective was added[5] by NicolasMailhot when he commented that Type1 fonts were becoming increasingly rare as the preferred non-TTF format was now OTF[6] . Nicolas advised that applications currently depending on Type1 fonts should upgrade their backend.

[5] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01145.html

[6] http://en.wikipedia.org/wiki/OpenType

令人震惊！内核使机器的温度达到125C？

MatthewMiller提交[1] 了一份很有趣的报告。Matthew观察到一个32位的Athlon 3200+在使用kernel 2.6.24-0.133.rc6.git8.fc9编译一个软件包的时候机器核心问题飚升到125C。而前一个内核也只是到95C。机器在达到125C温度的时候就断电了。

[1] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00443.html

AndrewHaley suggested[2] that the hardware was at fault rather than the software which led RichiPlana to rebut[3] that with a list of instances in which software had damaged hardware. AlanCox seemed to agree[4] with Richi that it was possible that a kernel error could lead to overheating and then the BIOS would shut the machine off once a critical temperature had been reached. Alan requested that the fans be checked and then old and new kernels run and if any anomalies resulted that Len Brown then be informed.

[2] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00444.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00452.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00459.html

Inaccurate ACPI readings with other AMD processors were reported by SteveGrubb[5] and TrondDanielsen[6] although Trond noted that lm_sensors appeared to give accurate readings.

[5] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00447.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00589.html

基础设施

原文请查看

This section contains the major discussion, happening on the Fedora infrastructure list between 6th January 2008 to 12th January 2008.

断电

MikeMcGrath reports[1] ,

上周我们经历几次奇怪的硬件断电。有3太重启了，一次是xen6，而xen1有那么一两次。那些重要的访问程序都从xen1转移到了xen2了。xen2现在运行着很多的访问程序，app1, app2, app3, koji1, releng1, noc1, puppet1, 3个测试服务程序。宿主程序最后还是放回到了xen1上。RH小组只好来帮助我们解决这些像突然停电之类的奇怪的事情。如果还是解决不了而且情况依旧的话，我们只能呼叫Dell了。在这周晚些时候，我们终于搞明白这个和iscsi相关。我们没有硬件监视器，没办法。

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-January/msg00025.html

A new FIG: sysadmin-tools

MikeMcGrath reports[1] ,

Similar to the web group the sysadmin-tools group has access to a number of our collaborative tools (in the future to include asterisk, gobby and likely mailman).

[1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-January/msg00045.html

安全周刊

原文请查看

Coverity and Open Source

There were quite a few stories about Coverity this week. Most were rather poorly written and were confusing at best. The real story is best read from the Coverity site here:

http://scan.coverity.com/

In general Coverity is portrayed in a mostly positive light for providing their service to various Open Source projects. In reality it's not that simple. Using a closed source tool for the supposed benefit of Open Source is misleading at best. If Coverity was serious about improving the state of Open Source, they would release their tool under an Open Source license for the community to consume and improve upon. Right now they simply have a clever marketing program.

Bruce Schneier Interview

Computerworld has a nice interview with Bruce Schneier that even mentions Linux:

http://www.computerworld.com.au/index.php/id;1891124482;pp;1

He is one of the few security public figures who can explain things in a manner that most people can understand.

安全更新

原文请查看

Fedora 8 安全更新

Fedora 7 安全更新

事件和会议

原文请查看

In this section, we cover event reports and meeting summaries from various Projects and SIGs.

Contributing Writer: ThomasChung

Fedora Board Meeting Minutes 2008-MM-DD

  • No Report

Fedora Ambassadors Meeting 2008-MM-DD

  • No Report

Fedora 文档 Steering Committee 2008-MM-DD

  • No Report

Fedora Engineering Steering Committee Meeting 2008-01-10

Fedora 基础设施 Meeting (Log) 2008-01-10

Fedora Localization Meeting 2008-MM-DD

  • No Report

Fedora 营销 Meeting 2008-MM-DD

  • No Report

Fedora Packaging Committee Meeting 2008-MM-DD

  • No Report

Fedora Quality Assurance Meeting 2008-MM-DD

  • No Report

Fedora Release Engineering Meeting 2008-MM-DD

  • No Report

Fedora SIG EPEL Meeting Week 02/2008

Fedora SIG KDE Meeting Week 02/2008

Fedora SIG Store Meeting (Log) 2008-01-09

Fedora SIG Astronomy Meeting Log 2008-MM-DD

  • No Report
Retrieved from "https://fedoraproject.org/w/index.php?title=Archive:Zh/FWN/Issue115&oldid=51809"