• 2006-02-24

    Debian安装源包括amd64

    Views: 9752 | No Comments

    Debian安装源包括amd64,自己做个记号,以免丢失。主要是中国教育网的站点,如果你是教育网用户,速度一般在500K以上。

    ftp://debian.ustc.edu.cn/debian
    
    http://mirror.dlut.edu.cn/debian
    
    ftp://deb.ustcsz.edu.cn/debian
    ftp://ftp.tsinghua.edu.cn/mirror/debian/debian
    

    amd64

    ftp://debian.ustc.edu.cn/debian-amd64/debian
    
    http://amd64.debian.net/debian-amd64/debian
    
    ftp://deb.ustcsz.edu.cn/debian-amd64/debian
    
    Posted by ideawu at 2006-02-24 08:10:29
  • 2006-02-23

    在Linux下玩Doom3

    Views: 8871 | No Comments

    可怜我的AMD Sempron2500+,ATI9550(128M),512内存,也只能使用800x600才能勉强玩,而且最好不要遇见超过5个人(怪)物。






    Posted by ideawu at 2006-02-23 21:05:00
  • 2006-02-19

    静态和动态链接库

    Views: 13015 | 5 Comments

    创建和使用“C”的静态和共享链接库Building And Using Static And Shared "C" Libraries

     开发程序的其中一个问题是,它们总是倾向于变得越来越大,使得编绎和链接的时间是一个大数字,而且破坏了makefile,和源文件所在的目录。一旦我们的程序达到这种状况,那么该是我们寻找一种不同的方法来管理我们的项目的时候了。

    正因为如此,我们想到将相关联的源码文件结合成小的单元,使得可以使用单独的makefile来管理,由不同的程序员来管理也是可以的(在多程序员的项目上)。

    什么是“C”链接库?它有什么好处?What Is A "C" Library? What Is It Good For?

    编绎器给我们的一个工具是链接库。一个链接库就是一个包含多个目标文件的文件,在一个程序的链接阶段可以作为一个单独的整体来使用。链接库一般是索引好的,所以很容易找到它们的符号(函数,变量等等)。因为这个原因,当一个程序的目标文件被安排在链接库时,其链接的速度比目标文件分布在磁盘上更快。而且,使用链接库的时候,我们只查找和打开更少的文件,这加快了链接的速度。

    Unix系统(以及大部分的现代系统)允许我们创建和使用两种链接库 -- 动态链接库和共享(或者说静态)链接库。(这里可能是原文或者原来翻译时的笔误. 本人有理解翻译内容的责任.) Unix系统(以及大部分的现代系统)允许我们创建和使用两种链接库 -- 静态链接库和共享(或者说动态)链接库.

    Static libraries are just collections of object files that are linked into the program during the linking phase of compilation, and are not relevant during runtime. This last comment seems obvious, as we already know that object files are also used only during the linking phase, and are not required during runtime - only the program's executable file is needed in order to run the program. 静态链接库只是目标文件的集合,这些目标文件在链接阶段被链接进程序之中,在程序运行的时候没有关系。最后一个观点看起来是很显然的,因为我们已经知道目标文件只是在链接阶段被使用,程序运行的时候并不需要 -- 只有程序的可执行文件运行的时候需要它。(我没有理解这一段话的意思。看起来作者也应该不知道自己在讲什么。不过,我知道,静态库在编译的时候被固定在了可执行文件中。-- ideawu注)(基于错误翻译的错误理解)

    网友 yourhero 的解释:

    我觉得这个你的理解有点偏差,据我理解,作者说的意思是,静态链接库在使用它的程序连接的时候需要用,连接完成后生成的可执行文件可以直接运行,不用在需 要这个lib文件了; 而动态库则不一样,在调用它的程序连接时需要使用lib文件(如果有),生成的可执行文件也不能单独使用,而必须和dll文件一起才可以执行。

    共享链接库(也叫做动态链接库)是分两步链接进程序中的。首先,在编绎的时候,链接器查找出程序需要的所有符号(再提一次,函数,变量等等),然后链接进程序当中或者程序的另一个共享链接库当中。动态链接库中的目标文件并没有固化进可执行文件。替代的是,当程序运行的时候,由系统的一个程序(叫做动态装载器 dynamic libraries)检查程序需要哪些动态链接库,然后把它们装入内存并且与内存中的程序关联。

    这种复杂的动态加载过程使得程序的启动稍微变慢,但这是一个不值一提的缺点,因为已经被它的强大的优点给掩盖住了 -- 当第二个程序需要相同的动态链接库时,它可以使用内存中相同的动态链接库的复本,因此省了很多内存。例如,标准“C”库是一个常用的动态链接库,被所有的C程序使用。但是,任一时刻内存中只有一个它的复本。这意味着我们需要更少的内存来运行我们的程序,而且可执行文件变得更小了,也省了很多磁盘空间。

    无论如何,这种方式还是有一个缺点。如果我们重新编绎了一个动态链接库并且尝试用新的链接库来运行我们的程序的第二个复本,我们就会立即被困住 -- 动态加载器会发现内存中已经有了一个链接库的复本,就不再从磁盘加载新的(修改过的)版本。有方法可以解决这个问题,我们将在最后一节讨论。

    翻译自:http://users.actcom.co.il/~choo/lupg/tutorials/libraries/unix-c-libraries.html 的部分。

    Posted by ideawu at 2006-02-19 10:31:00
  • 2006-02-16

    Linux桌面小技巧 — 工作区

    Views: 13590 | 2 Comments

    工作区(Workspace)

    无论你使用Gnome还是KDE,一般在任务栏上都会有四个工作区。你可以增减它的数目。每一个工作区都可以看作是一个独立的桌面,只是它的桌面图标和菜单是一样的。当前桌面某一时刻只能显示其中一个工作区,但是你可以在工作区之间进行切换。

    当你启动一个程序时,它的图标就出现在当前工作区,如果你切换到了其它工作区,你将看不到任务栏上有它的图标,但是它仍然在另一个工作区里工作。

    这样有一个好处。比如,我们可以将一些已经启动了的但是不再需要控制的程序移动到另一个工作区,从而保持当前工作区的清洁。我们可以将MP3播放程序移动到其它工作区,也可以将系统监视器(System Monitor)等程序移动到另一个工作区。作法是右键点击任务栏上程序的图标或者程序窗口的标题栏,然后选择“移动到另一个工作区”---->“工作区X”(X为1-4或者更多)。

    右键点击任务栏-->Add to panel-->Workspace Switcher就可以安装工作区了。

    Posted by ideawu at 2006-02-16 07:58:30
  • 2006-02-14

    I had a dream

    Views: 8001 | Comments Off

    I had a dream lastnight, really a nightmare. I failed an important exam just because I love playing truant so much.

    I was so scared...

    Posted by ideawu at 2006-02-14 18:01:25
  • 2006-02-10

    操作系统为什么运行缓慢

    Views: 10336 | 3 Comments

    昨天有时间翻了翻 Andrew S. Tanenbaum 的《现代操作系统》一书,先看最后一章“操作系统的设计”。发现有一节“12.4.1 操作系统为什么运行缓慢”很好,小节标题是“操作系统为什么运行缓慢”,但是我认为他讲的是所有的计算机软件为什么运行缓慢。我摘抄上来与大家分享,顺带我的一点看法,同大家一起讨论。

    在讨论优化技术之前,值得指出的是许多操作系统运行缓慢在很大程度上是自己造成的。例如,古老的操作系统MS-DOS和UNIX版本7在几秒钟内就可以启动。现代UNIX系统和Windows 2000尽管运行在快100倍的硬件上,可能要花费几分钟才能启动。原因是它们要做更多的事情,有用的或无用的。看一个相关的案例。即插即用使得安装一个新的硬件设备相当容易,但是付出的代价是在每次启动时,操作系统都必须要检查所有的硬件以了解是否存在新的设备。这一总线扫描是要花时间的。

    一种替代的(并且作者看来是更好的)方法是完全抛弃即插即用,并且在屏幕上包含一个图标标明“安装新硬件”。当安装一个新的硬件设备时,用户可以点击图标开始总线扫描,而不是在每次启动的时候做这件事情。当然,当今的系统设计人员是完全知道这一选择的。但是他们拒绝这一选择,主要是因为他们假设用户太过愚笨而不能正确地做这件事情(尽管他们使用了更加友好的措辞)。这只是一个例子,但是还存在更多的事例,期望让系统“用户友好”(或者“防傻瓜”,取决于你的看法)却使系统始终对所有用户是缓慢的。

    或许系统设计人员为改进性能可以做的最大一件事情,是对于添加新的功能特性更加具有选择性。要问题的问题不是“用户会喜欢吗?”而是“这一功能特性按照代码大小,速度,复杂性和可靠性值得不计代价码?” 只有当优点明显地超过缺点的时候,它才应该被包括。程序员倾向于假设代码大小和程序瑕疵计数为0并且速度为无穷大。经验表明这种观点有些过于乐观。

    另一个重要的是产品的市场销售。到某件产品的第4或第5版上市的时候,真正有用的所有功能特性或许已经全部包括了,并且需要该产品的大多数人已经拥有它了。为了保持销售,许多生产商仍然继续生产新的版本,具有更多的功能特性,正是这样才可以向现有的顾客出售升级版。只是为了添加新的功能特性而添加新的功能特性可能有助于销售,但是很少会有助于性能。

    作者的这种说法我是很认同的,所以当有位兄弟发贴问“FC5是不是运行快了很多了”的时候,我立即回贴表示这几乎不可能。

    经验告诉我们,升级软件往往伴随着升级硬件,否则新的软件无法使用或者速度无法接受。这是因为,软件的升级,速度并不是主要考虑的问题,新的功能和新的操作方式才是软件升级的原因。软件制作都当然不需要添加新的功能特性,只需要研究原来软件的算法,并试图改进来提高速度。一般情况下是可以提升速度的,但大多数情况是不明显的。硬件可以只通过改进物理特性而不增加或者删除某项功能来提升速度,而软件只能通过改进算法来提升速度,功能的删除是很少见的。

    但是,我们忽略了重要的一点。并不是因为更新和更好的算法是难以发明的,而是因为采用新的算法必须带来新的软件Bug。原来的软件肯定有Bug,这是必然的。但是,它的功能的性能想必已经满足了用户的需要。而且,一百个专家1个星期的测试结果并不比一万个用户一年的使用情况来得可靠。没有人愿意在软件中增加未知的Bug,或许是致命的,只有迫不得已的情况下才这么做。

    事实还告诉我们,我们可以通过将P3+128M内存的机器升级为P4+1024M内存从而使用我们的FC4操作系统产生速度上的明显提升。但是,我们不可能过将RH9操作系统升级为FC4而期望在我们的P3+128M内存的机器上产生任何的速度提升。所以,试图通过升级软件而硬件不升级来提升软件速度,这种想法往往是可笑的。

    Posted by ideawu at 2006-02-10 08:53:57
|<<<129130131132133134135136137>>>| 133/138 Pages, 825 Results.