Software Revolution 为2.6内核搞出了一个详尽的UML 2.0 model，包含了所有主要子系统的SVG图(scalable vector graphics )，要下载一个ADOBE的SVG 查看插件才能在IE里观看。
        Model里用SVG表示控制流，结构图，状态机，action diagrams，数据元素，调用图，complexity metrics，business rules，decision tables。
       
        可是觉得如果只看代码话，source insight，understand c+＋挺好，也用不上这个在线的model。
       
        via Linuxdevices
        

        
        
        The free and open database of Open Source projects that anyone can edit.
        专注在open source项目的free-content目录，后台？当然是Wiki。

        
        
        Eclipse 3.1 发布了。
        Download challenge似乎很流行，Firefox，Opera，现在是Eclipse了。我去的时候，已经89757个下载了。

       

         开放就是这样，就是这样。
        开源一周之内，大家对那百万行可能是地球上最clean的代码都干了些什么？
       
        OpenSolaris 社区管理人Jim Grisanzio 曾经跟ZDNet Australia 说，相对来说，他们这些代码里面“脏字”要少些－－不奇怪，程序员也是人，所以他们也会在代码的注释，说明，版权，或者任何他们喜欢的地方加上自己的话，或者是确实为了说明情况，或者是发泄不满，或者是为了好玩，或者......
       
        如果粗略地搜索一下，会发现那些最常见的脏话确实没有－－这可跟泄漏出的Windows代码和Linux内核代码大不相同哟－－或许是Sun的雇员们全是绅士，或许Sun以前清查过 ;-) 那么，OpenSolaris 里的代码就真的那么中规中据吗？
        This is an ugly PCMCIA hack - ugh!－－没什么，我能接受
        Couldn't find the damn thing－－别着急，我能理解你的心情
        The following cast 'makes it all work'. Yes, it's ugly－－我知道你很自律
        This bit me in the ass a couple of times, so lets toss this in as a cursory sanity check－－来自率先开放的dtrace
        of this writing (1996) a clock rate of more than about 10 kHz seems utterly ridiculous, although this observation will no doubt seem quaintly amusing one day－－在IT圈子做预言从来都是吃力不讨好
        Oops, did not find this signature, so we must advance on the next signature in the SUA and hope to God that it is in the susp format, or we get hosed－－知道西方程序员信什么教了吧
        God help us all if someone changes how lex works－－你和上面的哥们可能是同一个兄弟会的
        Oh God, what an ugly pile of architecture－－还有你
        Darn MS FTP server is a load of CRAP !!!!－－进入OpenSolaris中的Perl也把对Microsoft的咬牙切齿带了进去
        另一位显然是JRR Tolkien的The Lord of the Rings 的书迷－－Didst thou think that the eyes of the White Tower were blind? Nay, I have seen more than thou knowest, Gray Fool
        还有的哥们品味好像不在Tolkien的魔幻小说上，他引用了Monty Python and the Holy Grail
        GRUB 是引导操作系统启动的门户，他们说－－This function is truly horrid, We try opening the device, then severely abuse the GEOMETRY->flags field to pass a file descriptor to biosdisk. Thank God nobody's looking at this comment, or my reputation would be ruined. －－别担心，你已经蜚声世界...

        说句老实话，开放了的Solaris代码有助于打破人们对商业软件的神秘感和对那些一直就存在的Free/Open Source软件的不信任，如果你看到他们都是由相似的人－－甚至就是同一拨人－－用相似甚至相同的方法编写，你还会觉得那些加了个封套就敢卖天价的东西有那么厉害吗？
        我一直以为，打破权威感是Free/Open Source的另一个“非技术型”成果，就像人们在Internet发展之后发现，原来Internet也能反映和承载民主平等的概念一样，Free/Open Source的意义绝不只Software那么简单。

        via ZDNet Australia 

         它曾是Sun所吹捧的OpenSolaris中的一个卓越特性；它已经被Sun两次推迟发布；它现在正在被Sun用另一个卓越的竞争者顶替－－Janus，Sun这个硅谷的倒霉蛋计划中的Linux应用虚拟机。
        让A架构的应用跑在B架构上，或者让为A平台编写的软件运行在B平台上，人们总在追求... VMWare，VirtualPC，PearPC，Bochs，Plex86，GuestPC，Wine，Cygwin...... 出于保护投资和获得更多应用的目的，软/硬件虚拟机的技术从以前mainframe的领地开始下移，人们越来越熟悉这些奇妙的东西。
        让Linux应用能运行在Solaris上的Janus也是如此，Sun曾经表示有了Janus，用户就可以只购买/使用Solaris即可，无需担心系统迁移，投资保护的问题－－可惜嘲弄人的是，Sun的目标客户－－那些需要运行Linux软件的专业人群－－对运行真正的Linux，而不是Solaris虚拟环境下的Linux，更感兴趣。
        在Janus还无定数的时候，Sun转而推Xen，来自剑桥的虚拟技术新贵。目前Xen支持的系统很多，比如至少在同一台机器上运行Solaris和Linux是没问题的。Solaris marketing 部门的头头Tom Goguen表示他们已经非常活跃地involved 在Xen项目中了，他们为Xen项目提供硬件，他们的雇员投入并邀请其他人进行把Xen集成进OpenSolaris的工作－－同时，同时，Sun仍然希望提供自己的Janus。
        IBM，HP，Intel，AMD都是Xen的狂热爱好者...

        Janus，正式名称是Linux Application Environment，会翻译Linux系统调用接口为Solaris对应实现。目前似乎在X86机器上，Linux应用无需改变即可运行在Solaris上。本来计划2005发布的Janus已经推迟到了2006，可能会和Sun的另一个明星ZFS，Zettabyte File System一同发布。

        Via news.com

        这两天忙得像XX一样，眼看着不少有意思的事情发生。
        一是Gentoo 奠基人和前Chief Architect， Daniel Robbins加入Microsoft。
        虽然在这以前很久Daniel就离开了Gentoo，并协助建立了Gentoo Foundation作为Gentoo的管理者，但他在Gentoo以及Linux社区仍然保持着巨大的影响力并享有因自己的杰出创建而获得的当之无愧的声望。这个标志性人物加入Microsoft可能有标志性意义。从目前的消息看，他说他为这个几乎是Linux死敌的新老板所做的工作是“帮助Microsoft理解Open Source和基于社区的项目”。在匆匆打包前往那个浪漫雨城的时候，Daniel还是完成了Gentoo最后一点知识产权的转移工作，比如把ebuilds和即将成为商标的“Gentoo”的版权交给Gentoo Foundation, Inc。
        Bill在Microsoft也是Chief Architect ;-P，当然你也可以念做Chief Architect Officer，CAO－－请不要用汉语拼音念。
       
        美国时间的14号，北京时间今天，OpenSolaris 终于出阁。
        Solaris engineers offer personal source-code tours

        
        从去年1月SUN的Solaris之手点向OpenSource水潭开始，16个月过去了，下周他们的新科宝贝就要正式发布，接受检阅。
        Sun 曾经计划在2004就发布OpenSolaris，不过最终只是做了一点小动作，发布了DTrace（我这儿还有一篇DTrace的详细介绍）－－或许是想试探一下社区的反应。
        通过Community Development and Distribution License（CDDL）协议发布Solaris，Sun希望能扩大自己这个当家产品的影响力，吸引更多的开发者和用户。
        我们拭目以待。
       
        Via news.com

                ars technica 文章 Inside the Xbox 360。

        第一部分从3核的Xenon开始介绍了XBox的procedural synthesis技术（相关专利），这个技术第一次在Xbox 360 上应用。简单地说，procedural synthesis 就是从静态存储的高层场景数据中，动态生成底层的几何数据，以达到对系统带宽和主存的最佳利用。第一部分还介绍了Real-time tessellation，Real-time skinning，3核Xenon如何帮助实现procedural synthesis。关于Xenon，我们看看
        
        （此仅为模拟示意图）

        Xbox 360肚子里的Xenon有3个相同的PowerPC core，共享1M 2级缓存。作者把每个core叫做PowerPC Processing Element (PPE)。每个PPE有独立的64Kcache，指令和数据各占一半。通过simultaneous multithreading (SMT)，每个PPE同时最多可以处理2个线程。对整个Xenon 来说，就是同时6个。使用procedural rendering 的游戏终归能从这个特性中受益。按Microsoft的专利所说，使用上述技术的游戏有这样两个主要部分：
        Host thread：包括游戏的主要执行部分，这个线程将管理3D引擎的高阶部分，并且控制下面这个Host thread线程。
        Host thread：完成目标几何数据的真正procedural synthesis过程。该线程输出游戏中各种对象的顶点列表，交GPU处理。
        这两个线程可以跑在同一个PPE上，或者两个PPE上。处理上述两个线程，游戏里还可以有其他独立线程完成AI,IO等工作。
        后面是Cache。Xenon 提供了更多编程控制Cache的能力。
       
        第一部分的概要介绍后，第二部分详细描述了Xenon的设计和实现。首先是传统的增加执行core数量的方法带来的困境，之后是Xenon的设计：
        Cell 和 Xenon 有共通的基本概念：去掉那些试图在运行时优化指令调度的硬件，降低执行core的复杂度。Cell 和 Xenon都摒弃了instruction window，不再强调instruction-level parallelism，指令就老老实实地按照他们被取出的次序流过CPU，当然，如果相邻指令没有相互依赖，就仍然并发执行。
        这样的静态执行机制很像那些过时的老家伙们采用的方法－－比如奔腾。静态执行很容易实现，并且占用更少的die。没了instruction window 和相关硬件，instruction window省下来的空间可以放置更多的真正的执行单元。
        当然你不能一脚踢开instruction window然后用更多的执行单元取而代之就万事大吉甩手不管，总的做点什么来补偿去掉instruction window带来的一些tradeoff－－既然instruction window的概念是要让多执行单元情况下提高instruction-level parallelism，那么去掉了instruction window的多执行单元芯片，就得重新考虑如何组织CPU。
       
        Xenon不再依靠instruction window在运行时决定ILP，它更酷，让程序员在编译时安排指令流，这样代码中包含了高层的线程级并行TLP。XBox 360的程序员们要辛苦一些，对他们的要求也高一些。在把大量的执行单元组织到3个core里面之后，每个core独立地包含相对数量较少的执行单元，经过程序员安排的指令流形成的多个并行线程就在这些独立的core上运行。最终结果是每个线程的ILP值可能比较低，但是总的组合效果是3个PPE里的所有执行单元都出于出工出力的状态，效率颇佳。据称TLP策略对procedural synthesis这样线程级并行的任务尤其有效－－不过相比那些天生就是单线程的任务在此前的大执行单元+巨大的instruction window架构上的表现，还是没那么好。3种游戏相关任务可能会受到Xenon这种缺乏乱序执行功能的芯片的负面影响：游戏控制，AI和Physics。
        Xenon PowerPC Processing Element 细节是：
        L1 cache: 32K instructions/32K data
        Two-issue superscalar execution
        In-order execution
        Two-way simultaneous multithreading
       
        PPE 流水线
        
        
        关于PPE的execution core。确切地说，组成PPE execution core的execution unit的数量和性质还没有正式透露。推测来说PPE 的执行单元（execution unit）：
        1 integer unit
        1 floating-point unit
        1 branch unit
        1 load-store unit
        2 VMX-128 units
        最引人瞩目和让人迷惑的是Xenon的向量执行单元（或者说SIMD执行单元），它将主要完成前面提到的procedural synthesis。
        Xenon的VMX将提供128个寄存器，每个128位－－老实说，对我们这样大多数还活在32位，有时会回到16位甚至8位时代的人来说，这个特性非常非常bleeding-edge......这也就是VMX-128名字的来历吧。
        每个线程都可以使用这128个向量寄存器，按照 128寄存器 * 2 线程 来算，die上就有256个物理向量寄存器。
        目前PPC的32位指令格式如何适配这个3操作数每个操作数都可以达到128位的怪物还不清楚。IBM会玩什么hack招术还是秘密。
        关于VMX-128的另一个消息是，为了提高性能，128个好汉中将会拿出一些来构成寄存器pool，pool中的寄存器被多个函数调用共享－－只要他们在同一个线程内。

        Simultaneous multithreading－－当然，我不知道翻成并发还是并行，还是并行比较好。
        和超线程P4比，Xenon的SMT实现非常非常简单。不过似乎PPE的总设计和P4的Netburst架构有相当多的类似之处（莫非英雄所见略同...）。他们的设计哲学都是narrow and deep，当然PPE有些非常重要的不同。
        PPE的流水线有21阶，和Northwood P4相同（Prescoot？我也不知道了...）。Xenon的PPE有32K指令和32K数据cache，对双线程和较深的流水线来说，似乎有点小。PowerPC 970的23阶流水线有64K指令/数据cache，而PowerPC G4的7阶流水线就有32K指令/数据Cache。不过，这并不是Xenon的灾难，实际上32K指令/数据1级cache很通用，而且当它作为一个游戏机芯片的时候，性能影响就更微乎其微了。因为在Xbox 360 这样的游戏应用中，开发者对硬件和cache层级可以做到非常细微的控制，如果把Xenon拿去搭建常规应用，比如苹果机，那恐怕就确实有点麻烦了。
        同样，Xenon的1MB 2级缓存挺起来好像也有点出乎意料－－出乎意料地小－－特别是对一个3核CPU来说。理论上，共享cache的core越多，这个cache似乎就该越大。不过实际上，准确地说，应该是共享cache的并发执行线程越多，这个cache就该越大－－不过，有点搬起石头砸自己脚的是，在这个看法下，Xenon的cache更不适合了－－因为一个Xenon的 core支持两路多线程，这样算下来，最多会有6个线程共享1M 2级cache。当然，IBM的家伙不是无厘头，他们这样设计较小的2级cache有2个重要原因：
        第一，在有限的die尺寸上搞出一个3核CPU不那么简单，没那么多空地儿留着给cache（希望上海市政府也明白同样道理，少批点儿地造cache那样的高档楼，留点儿地皮给咱们，上海这个die就只有这么大了）。Xenon 已经巨无霸到要用水冷设备才能工作了，再大就不象话了。
        第二，更重要的原因是，流媒体streaming media－－特别是Xenon－－使用cache的方式，决定了1级cache这么大足够了。Xenon 面向的应用场合，并不会非常有效地利用cache。这种Media application通常都会让流数据快速流动，cache很少会被复用。一个实证是赛扬，玩Quake 的时候，没有cache的赛扬几乎和它配了cahce的哥们奔二一样快。
       
        深流水线的另一个问题是分支预测。PPE当然有这个功能。由于缺少资料，目前可以推断的是，PPE的分支预测错误率可能会高于PowerPC 970。PPE的策略似乎更期望软件上提供branch hints，而且硬件完成的分支预测工作较少，就意味着这样的software branch hints更有效。Xenon－－－哦，还有Cell－－的程序员们，加油，branch hints 的活儿，更好的游戏性能就靠你们了。

        和PS3的Cell一样，XBox 360的Xenon和它的前辈差异巨大，策略迥异。利用procedural synthesis和多线程，XBox 360能营造出比现在的任何游戏设备或者PC都更具吸引力的视觉环境。
        对那些分支敏感代码，比如AI和控制，Xenon的表现可能是普通甚至很差。Xenon绝对会是个streaming media monster，但是如果不算面子漂亮的活儿的话，游戏引擎中那些让游戏更好玩的因素恐怕会在Xenon上受到伤害。太小的2级cache会让AI和控制部分表现不好－－他们必须得同procedural synthesis以及其他图形代码共享这可怜的1M－－程序员们得好好费费劲才能让这些非图形代码获得高性能。
        虽然Xenon可以同时运行6个线程，但是上面说的AI和控制等分支敏感代码不具备图形代码那样高的线程级的并行特性，6个线程英雄无用武之地。同样这些在乱序执行CPU上可以撒欢儿的代码也不能从Xenon的顺序执行策略中受益。
        所以，最终结果是，XBox 360为开发者提供了绝佳的图形资源，但是要求他们在游戏的非图形因素上花费多点精力。其实换个角度也可以这么看，在PC市场上，开发者要支持多种CPU，他们没法为某种CPU进行专门的性能调整和优化。这种异构性伤害了branch hints这样的优化手段。相比之下，Xenon还算好了，硬件平台是确定的，开发者至少有机会可以全力进行profiling啊，优化啊等等，所以上面所说的控制和AI部分的劣势可以得到一定弥补。随着Xenon的使用，开发者们总有办法找到解决办法对付分支敏感代码的执行效率之类的问题－－这不就是人的力量嘛－－当然，游戏fans不能指望第一代游戏就这么好 ;-P
        既然看了Xenon，也顺顺展望一下它的同门PS3的Cell－－它恐怕会更差。Cell只有1个PPE－－Xenon有3个，这意味着程序员得把控制，AI和真正的代码塞到最多2个线程里－－共享narrow execution core，而且没有instruction window。PS3的SPE甚至根本不支持分支预测。此外，PS3的2级cache更穷，只有521K，Xenon的一半。简短地说，在非图形代码上，PS3会比XBox 360更差，但是借助PS3的7个SPE，它的游戏画面就比XBox 360强多了。

        显然白痴都知道一种游戏机的成功与否取决于包括但不限于处理器架构以外的相当多因素，不过既然XBox 360的架构和PS3将采用的Cell有很多共通之处，他们似乎在接近一个共同的起跑线，让人们更能饶有兴致地坐家观虎斗。

        The hottest Linux (legal) torrents by LinuxISOtorrent.com  Your Linux Torrent Repository

        这个网站只干一件事，不过干得不错。搜集各个Linux发行版的torrent，帮你下载时省点心。Via OSNews.com

        Tux:Tops 的Pocket PC Software suggestions，都是不错的freeware。内容包括任务管理，实用程序，网络，多媒体等。