David Patterson . 《How to Build a Bad Research Center》

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享

(没有打分)

系统领域的经典文献

系统架构是一个工程和研究相结合的领域,既注重实践又依赖理论指导,入门容易但精通很难,有时候还要讲点悟性,很具有“伪科学”的特征。要在此领域进阶,除了要不断设计并搭建实际系统,也要注意方法论和设计理念的学习和提炼。

经常有同学询问如何学习,特贴一篇学习材料,供大家参考。09年时写的,在系统领域浩如烟海的文献中提取了一些我认为值得研究和学习的项目,没包括近几年出现的一些工作,也不够全面。不过,其实也足够了,看paper是一个从少到多再到少的过程。对问题本质、背景和发展历史有大致了解,再辅以hands-on的实践(长期的真正的实践),足以摸到本领域的门径。

此文在网上转载不少,但多数没有说明出处。今天在这里重发,也顺便向315致敬。

对于工程师来说,到一定阶段后往往会遇到成长瓶颈。要突破此瓶颈,需要在所属技术领域更深入学习,了解本领域的问题本质、方法论与设计理念、发展历史等。以下提供一些架构相关领域的学习材料,附上简单点评,供有兴趣的工程师参考。希望大家能通过对这些领域的了解和学习,掌握更多system design principles,在自己的工作中得心应手,步入自由王国。

1. Operating Systems

Mach [Intro: http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html,Paper: http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/doc/publications.html]

传统的kernel实现中,对中断的响应是在一个“大函数”里实现的。称为大函数的原因是从中断的入口到出口都是同一个控制流,当有中断重入发生的时候,实现逻辑将变得非常复杂。大多数的OS,如UNIX,都采用这种monolithic kernel architecture。

1985年开始的Mach项目,提出了一种全新的microkernel结构,使得由于70年代UNIX的发展到了极致而觉得后续无枝可依的学术界顿时找到了兴奋点,也开始了沸沸扬扬的monokernel与microkernel的争论。

插播一个花絮:Mach的主导者Richard Rashid,彼时是CMU的教授,受BillGates之托去游说JimGray加盟MS。结果把自己也被绕了进来,组建了Microsoft Research。他到中国来做过几次21Century Computing的keynotes。

Exokernel [Intro:http://pdos.csail.mit.edu/exo/,Paper:http://pdos.csail.mit.edu/PDOS-papers.html#Exokernels]

虽然microkernel的结构很好,但实际中并没有广泛应用,因为performance太差,而且大家逐渐发现OS的问题并不在于实现的复杂性,而更多在于如何提高application使用资源的灵活性。这也就是在kernel extension(例如loadable module in Linux)出现后,有关OS kernel architecture的争论就慢慢淡出人们视线的原因。

Exokernel正是在这样的背景中出现的,它并不提供传统OS的abstraction(process,virtual memory等),而是专注于资源隔离与复用(resource isolation and multiplexing),由MIT提出。在exokernel之上,提供了一套库,著名的libOS,用于实现各种OS的interface。这样的结构为application提供了最大的灵活度,使不同的application可以或专注于调度公平性或响应实时性,或专注于提高资源使用效率以优化性能。以今天的眼光来看,exokernel更像是一个virtual machine monitor。

Singularity [Intro:http://research.microsoft.com/os/Singularity/,Paper: http://www.
research.microsoft.com/os/singularity/publications/HotOS2005_BroadNewResearch.pdf
]

Singularity出现在virus,spyware取之不尽、杀之不绝的21世纪初期,由Microsoft Research提出。学术界和工业界都在讨论如何提供一个trust-worthy computing环境,如何使计算机系统更具有manage-ability。Singularity认为要解决这些问题,底层系统必须提供hardisolation,而以前人们都依赖的硬件virtual memory机制并无法提供高灵活性和良好性能。在.Net和Java等runtime出现之后,一个软件级的解决方案成为可能。

Singularity在microkernel的基础上,通过.Net构建了一套type-safed assembly作为ABI,同时规定了数据交换的message passing机制,从根本上防止了修改隔离数据的可能。再加上对application的安全性检查,从而提供一个可控、可管理的操作系统。由于.NetCLR的持续优化以及硬件的发展,加了这些检查后的Singularity在性能上的损失相对于它提供的这些良好特性,仍是可以接受的。

这种设计目前还处于实验室阶段,是否能最终胜出,还需要有当年UNIX的机遇。

2. Virtual Machines

VMWare ["MemoryResource Management in VMware ESX Server",OSDI’02,Best paper award]

耳熟能详的vmware,无需多说。

XEN [“Xen and the Art of Virtualization”, OSDI’04]

性能极好的VMM,来自Cambridge。

Denali [“Scaleand Performance in the Denali Isolation Kernel”, OSDI’02, UW]

为internetservices而设计的application level virtual machine,在普通机器上可运行数千个VMs。其VMM基于isolation kernel,提供隔离,但并不要求资源分配绝对公平,以此减少性能消耗。

Entropia [“The Entropia VirtualMachine for Desktop Grids”, VEE’05]

要统一利用公司内桌面机器资源来进行计算,需要对计算任务进行良好的包装,以保证不影响机器正常使用并与用户数据隔离。Entropia就提供了这样的一个计算环境,基于windows实现了一个application level virtual machine。其基本做法就是对计算任务所调用的syscall进行重定向以保证隔离。类似的工作还有FVM:“AFeather-weight Virtual Machine for Windows Applications”。

3. Design Revisited

Are Virtual Machine Monitors Microkernels Done Right?”,HotOS’05

这个题目乍听起来,十分费解,其意思是VMMs其实就是Microkernel的正确实现方法。里面详细讨论了VMM和Microkernel,是了解这两个概念的极好参考。

Thirty Years Is Long Enough: Getting Beyond C”, HotOS’05

C可能是这个世界上最成功的编程语言,但其缺点也十分明显。比如不支持thread,在今天高度并行的硬件结构中显得有点力不从心,而这方面则是functional programming language的长处,如何结合二者的优点,是一个很promising的领域。

4. Programming Model

Why Threads Are a Bad Idea

单使用thread结构的server是很难真正做到高性能的,原因在于内存使用、切换开销、同步开销和保证锁正确性带来的编程复杂度等。

SEDA: An Architecture for Well-Conditioned, Scalable Internet Services”,OSDI’01

Thread不好,但event也没法解决所有问题,于是我们寻找一个结合的方法。SEDA将应用拆分为多个stage,不同stage通过queue相连接,同一个stage内可以启动多个thread来执行queue中的event,并且可通过反馈来自动调整thread数量。

Software Transactional Memory

如果内存可以提供transaction语义,那么我们面对的世界将完全两样,language, compiler, OS, runtime都将发生根本变化。虽然intel现在正在做hardware transactional memory,但估计可预见的将来不会商用,所以人们转而寻求软件解决方案。可想而知,这个方案无法base在native assembly上,目前有C#,haskell等语言的实现版本。资料比较多,参见Wikipedia

5. Distributed Algorithms

Logical clock, [“Time,clocks, and the ordering of events in a distributed system”, Leslie Lamport, 1978]

这是一篇关于Logic clock, time stamp, distributed synchronization的经典paper。

Byzantine [“The ByzantineGenerals Problem”, Leslie Lamport, 1982]

分布式系统中的错误各种各样,有出错就能停机的,有出错了拖后腿的,更严重的是出错了会做出恶意行为的。最后的这种malicious behavior,就好像出征将军的叛变,将会对系统造成严重影响。对于这类问题,Lamport提出了Byzantine failure model,对于一个由3f+1个replica组成的statemachine,只要叛变的replica数量小于等于f,整个state machine还能正常工作。

Paxos [“The part-time parliament”, Leslie Lamport, 1998]

如何在一个异步的分布式环境中达成consensus,这是分布式算法研究的最根本问题。Paxos是这类算法的顶峰。不过这篇paper太难了,据说全世界就3.5人能看懂,所以Lamport后来又写了一篇普及版paper:“Paxos Made Simple” ,不过还是很难懂。另外,也可参看Butler Lampson写的“The ABCD’s of Paxos”(PODC’01),其中关于replicated state machine的描述会严重启发你对并行世界本质的认识,图灵奖的实力可不是盖的。

这上面反复出现了一个名字:Leslie Lamport,他在distributed computing这个领域挖坑不辍,终成一代宗师。关于他,也有几则轶事。记得以前他在MSR的主页是这么写的,“当我在研究logicalclock的时候,BillGates还穿着开裆裤(in diaper)…”(大意如此,原文现在找不到了)。另外,他在写paper的时候,很喜欢把其他牛人的名字变换一下编排进去。这可能也是他还没拿到图灵奖的原因。

关于Lamport的其他成就,还可以参见这篇向他60岁生日献礼的paper:“Lamport on mutual exclusion: 27 years of planting seeds”, PODC’01。

6. Overlay Networking, and P2P DHT

RON [“Resilient Overlay Networks”, SOSP’01]

RON描述了如何在应用层搭建一个overlay,以提供秒级广域网网络层故障恢复速度,而现有的通过路由协议来恢复通信的时间至少在几十分钟。这种快速恢复特性和灵活性使得overlay networking现在被广泛应用。

Application Level Multicast

End System Multicast”, SigMetrics’00

Scalable Application Layer Multicast”, SigComm’02

关于ALM的paper很多,基本上都是描述如何搭建一个mesh network用以鲁棒的传输控制信息,另外再搭建一个multicast tree用以高效传输数据,然后再根据多媒体数据的特点做一些layered delivery。前几年出现的coolstream, pplive等系统都是这类系统的商业化产品。

P2P

P2P的出现改变了网络。按照各种P2P网络的结构,可以分为三种。

1.    Napster式,集中式目录服务,数据传输Peer to peer。

2.    Gnutella式,通过在邻居间gossip来查询,也被称为unstructured P2P。

3.    DHT,与unstructured P2P不同的是,DHT进行的查询有保证,如果数据存在,可在一定的hop数内返回。这个hop数通常为logN,N为系统节点数。

典型的DHT有CANChord,PastryTapestry等四种。这些研究主要在算法层面,系统方面的工作主要是在其上建立广域网存储系统。还有一些人在机制层面进行研究,例如如何激励用户共享、防止作弊等。

7. Distributed Systems

GFS/MapReduce/BigTable/Chubby/Sawzall

Google的系列paper,大家比较熟悉,不再多说。在可查。

Storage

Distributed storage system的paper太多了。下面列出几篇最相关的。

Chain Replication for Supporting High Throughput and Availability”, OSDI’04。

Dynamo: Amazon’s Highly Available Key-value Store”,SOSP’07。

BitVault: a Highly Reliable Distributed Data Retention Platform”, SIGOPS OSR’07。

PacificA: Replication inLog-Based Distributed Storage Systems”, MSR-TR。

Distributed Simulation

Simulating Large-Scale P2P Systems with the WiDS Toolkit”, MASCOTS’05。Distributed simulation有意思的地方是simulated protocol是distributed的,而这个simulation engine本身也是distributed的。Logical和physical的time和event交杂在系统中,需要仔细处理。

8. Controversial Computing Models

现在的软件系统已经复杂到了人已经无法掌握的程度,很多系统在发布时都仍然带着许多确定性(deterministic)或非确定性(non-deterministic)的bugs,只能不断的patch。既然作为人类,不够精细的特性决定了我们无法把系统的bug fix干净,我们只能从其他角度入手研究一种让系统在这令人沮丧的环境中仍能工作的方法。这就像一个分布式系统,故障无法避免,我们选择让系统作为整体来提供高可靠性。

以下3个便是典型代表。基本上,主要研究内容都集中于1) 如何正确保存状态;2)如何捕捉错误并恢复状态;3)在进行单元级恢复时,如何做到不影响整体。

Recovery Oriented Computing

Failure oblivious computing, OSDI’04

Treating Bugs as Allergies, SOSP’05

9. Debugging

系统很复杂,人类无法从逻辑上直接分析,只能通过data mining的方法在宏观上进行观察。

Black box debugging[“Performance debugging for distributed systems of black boxes”, SOSP’03]

对大型系统的performance debugging非常困难,因为里面的问题很多都是非确定性的,而且无法重现。只能通过对log的挖掘,找出配对的调用/消息以定位问题。

CP-miner [“A Tool for Finding Copy-paste and Related Bugs in Operating System Code”, OSDI’04]

很多人在重用代码的时候,都使用copy-paste。但有时候简单的CP会带来严重的问题,例如局部变量的重名等。CP-miner通过分析代码,建立语法树结构,然后mine出这类错误。

(11个打分, 平均:5.00 / 5)

The Evolution of Operating System

(1个打分, 平均:5.00 / 5)

#弯曲首发#跨越“朦胧期”的云计算 – 浅谈几个技术突破点和争议点

各位弯友好,很长时间没发文章,实在对不起弯友和首席的厚爱,所以在这里以这篇新写的文章来向大家表达歉意^_^

我记得我第一次听到“云计算”这个名词的时候,大概07年底的时候,当时云计算的开创者之一Dennis Quan来到当时我工作地方IBM中国研究院做主题 演讲,在那次演讲中,他基于之前他在Google那里参与合作项目的实践,给我们描绘了在他眼里云计算所带来的美好前景,自从那天开始我成为了云计算的信徒,并且不才地2011年中出版我个人云计算的专著《云计算核心技术剖析》,之后就一直封笔,并始终专注于我们YunTable的开发和团队的组建。那么为什么在封笔两年之后,又重新提笔写云计算的文章呢?因为到了2013年,其实“云计算”这个概念,因为很多原因导致毁誉参半,并且随着其衍生“大数据”这个概念更愈演愈烈,但是身为一名所谓的“云计算和大数据专家”我个人认为在技术方面通过这几年的努力,云计算已经度过最近的朦胧阶段,并业界已经找出一些核心突破点,并铺以重兵攻坚,但同时也有一些有争议,并值得讨论的地方,这是我对这些加以总结,并形成此文的原因,虽然每个段落和方向都浅尝截止,但是希望能给大家一些启发。

 

核心技术突破点

就像前面说的那样,现在云计算技术层面,其实大的IaaS,SaaS和PaaS的架构已经清晰,但是下面几个点还是存在一定的技术难度,就像Tesla所用到核心技术,非5-10年的功夫是无法攻克的,所以个人觉得需要业界集结力量攻克。

Tesla

云计算的安全性

谈到云计算的话题,安全性永远是最热的话题之一。由于这个话题牵涉面广,所以本段落只关注两点,首先,是数据中心网络的安全性,最典型的例子,莫过于云计算最有知名度的Amazon Web Service服务,最近几年其几次大型故障都和网络有关,特别是其基于局域网技术的云硬盘服务EBS,多位业界网络专家认为其路由器的Oversubscribe(超卖)和网络配置无法应对(比如网络控制信息方面的流量会有波动)是整个问题的关键,如何解决好这个问题看来还需要进一步的实践和创新;其次,是虚拟机本身的安全性,其实在虚拟机的发展之初,其实各个技术主要关注首先绝对是性能,比如当时Xen虽然上手其为复杂,但是由于其本身的半虚拟化的架构,使得其在性能方面,长期稍强于VMware,并拿这点作为其长期的谈资,但是随着各方面程序的优化,特别是硬件虚拟化技术的引入,其实在性能方面,各方面都已经接近均势,并且大的优化空间也不多,所以虚拟机的安全性很有可能将会作为今后的主要考量之一,据一些行业IaaS云供应商的反馈,Xen本身有严重的漏洞,通过这个漏洞,虚拟机里面的程序可以直接攻击到物理机本身,并且KVM也有类似的问题,比如KVM直接有两个IO端口可以和QEMU通信,所以虚拟机的安全性还有待完善。 云计算的安全绝对是一个需要重视,并且需要花大力气的领域。

数据中心大二层和SDN

去年我曾经走访了几家做私有IaaS云的厂家,根据和他们的沟通,对于这些厂家而言,他们面对最大的技术挑战,基本都是“网络难配、网络难配”,主要有下面这三个原因:其一是现在云服务多个节点之间需要连接大量内部的通信,最明显的例子就是Hadoop,当集群大小超过千台时,网络会成为比IO更大的一个瓶颈;其二是虚拟机各节点只能在同一个二级网段内才能进行非常重要的动态迁移;其三是每个虚拟主机都会运行十个以上的虚拟机,这会导致过一个网段内实际所需要承受的机器数量和具体流量都倍增;这些因素都导致数据中心网络从之前对外为主的南北向,慢慢转为以内部为主的东西向,同时数据中心不得不出现大二层的现象。为了解决这些问题,网络界推出了各种解决方案,包括将路由能力带到二层网络的TRILL和FabricPath,用于识别虚拟机流量的VN-Tag和VEPA,用于二层互联的VPLS和OTV,最后就是号称改变整个网络世界的SDN(软件定义网络); 对于这些技术,我个人觉得的确能让现有的云服务,特别是IaaS层在技术层面有一个质的的飞跃,但是整体成熟度和成本要下降到一个让大家都满意程度,并非易事。

OpenStack完整的生态环境

2012年云计算的业界,其中有一个名词绝对是OpenStack,它和之前的IaaS开源项目,比如CloudStack、桉树(Eucalyptus)等不同的是,OpenStack强调的核心是生态圈,并且它的生态圈有两个特色,其一是模块众多,它不仅有传统用于虚拟机的模块,而且它还有提供云存储模块Swift,以及用于虚拟机镜像管理的Glance,另外还有最具创新型的网络模块Quantum;其次,整个圈子里面初创公司极为活跃,不仅国外有已经被VMware以巨资收购的Nicira,而且在国内,无论是九州云还是UnitedStack都做的有声有色。 虽然表面而言,OpenStack生态圈“歌舞升平”,但是其实个人觉得其实有很多隐患,最重要的是缺乏一个领军的企业来引导,光靠一个松耦合的社区真的有点难度。

Hadoop的生态圈的完善

虽然我个人对现在业界各种五花八门的Hadoop用例有点疑惑,但是Hadoop社区的确在最近几年,通过Cloudera和Hortonworks这两大巨头推动,并且再加上类似淘宝云梯这样案例不断成熟,使的Hadoop快成为业界标准的大数据服务平台。同时由于MapReduce这样新的编程框架,使得传统的基于关系型数据库的周边工具都无法继续使用,所以一些新的周边工具不断推出,包括用于数据流支持的Pig,用于SQL解析的Hive,用于日志收集的Flume,用于ETL的Scribe,用于实时分析的Impala等。 对于Hadoop这个生态圈,我个人也是很有疑虑的,虽然和OpenStack的圈子相比,它表面有两大巨头支持,但这两大巨头各怀鬼胎,而且其整体所需要投入的工程量和OpenStack相比不相上下,希望两大巨头能抛弃成见,起心协力。

NewSQL的兴起

前几年谈了很多NoSQL,虽然其伸缩性不错,但因为其不支持完整SQL语句,使得其学习成本很高,所以个人觉得既能伸缩,又能支持SQL的NewSQL兴起再所必然。大家想起的NewSQL,一定是MemSQL或者SAP HANA等这类初出茅庐的新型基于内存的数据库,但我个人觉得在NewSQL方面,其实最强大的始作俑者是研发出MapReduce的Google,虽然其最初整套用于半结构化数据解析的索引构建模块是基于MapReduce的,并且研发了著名NoSQL技术BigTable,但是随着它业务的需求和对性能等方面要求的不断提升。在技术方面,它做了优化和转型,基于现有公开的资料,主要两部分,其一在索引构建和OLTP方面,Google以BigTable为基础发展出可以对大数据集进行增量更新的Percolator系统以用于索引的构建和服务,同时也在BigTable基础上,推出用于分布式海量OLTP的Megastore和F1 Spanner,并且他们分别被用于Google App Engine的Data Store数据库服务和Google的现金牛广告服务,同时在OLAP方面,它推出有点类似MPP列式数据库的Dremel,通过Dremel这个系统能够构建有千台规模的分析集群,并能快速地对PB级别的数据进行处理。无论是F1 Spanner还是Dremel,它们在伸缩性方面都非常不错,并且在语法上面支持一定的SQL语句,个人觉得它们绝对是NewSQL的典范之作。 可惜的是现在NewSQL界,真正有实力的公司和产品并没有出现;

 

争议点

虽然上面提到了很多关注点,但是在我看来,还是有很多争议点,就像梅西和C罗各有各自的优点,还需要进一步讨论才能分出优劣或者各自适合的场景,个人觉得通过这样的讨论,能帮助大家抓住关键点,从而引发质的飞跃。

conflict

OpenStack 还是 CloudStack?

其实,OpenStack和CloudStack虽然其提供功能大体类似,但是个人觉得它们在核心理念是大相径庭,CloudStack本质是产品的思路,也就是通过这个产品能够非常快速地构建一个提供IaaS服务的私有云,并且通过其主要用户Zynga的使用来进行逐步地优化,而OpenStack则本质是一个生态圈,就像上面提到的那样,里面有很多公司和团队参与,并且功能强大的模块很多,可惜实际的案例不多,特别是大规模的。那么到底OpenStack的模式还是CloudStack的模式是今后IaaS云计算的主流,我个人很难判断,但最近一年,使用OpenStack来构建一个大型IaaS云,个人觉得至少在整体项目的技术支持还缺乏一个能全面理解OpenStack的团队来做。

结构化数据,Hadoop适合吗?

首先,个人一直觉得虽然现在Hadoop使用面很广,包括类似OLAP的结构化数据分析,但是其实Hadoop这样MapReduce的框架,最初的需求主要是用于类似网页这样的半结构化数据的处理和分析,而且MapReduce这样暴力的方式也特别适合类似地理数据和视频这样非结构化数据。同时虽然现在有类似Hive这样的解决方案,但是基于我最近几年我在底层的收获,和一些朋友反馈,Hadoop在处理结构化数据时,无论是处理速度,还是处理成本,都和基于列式存储的 NewSQL数据库无法接近的。另外,虽然Cloudera推出用于准实时分析的Impala,但是由于其重写了极为耗时耗力的SQL解析引擎,所以个人觉得等它全面支持SQL语句那天,还为时尚远。综上所述,诚然Hadoop能做对结构化数据的分析,但是是否合适,个人觉得是一个仁者见仁,智者见智的问题。

GAE,还是Cloud Foundry?

虽然PaaS这个名词在2012年比较沉寂,但是Cloud Foundry和GAE(Google App Engine)都有一定的进步,Cloud Foundry有了更多用户,GAE又发布了新的版本。争论的核心是Cloud Foundry和GAE在方向性上面的差别比OpenStack和CloudStack更大,在我看来,Cloud Foundry核心是快速地部署,快速地开发,支持各种编程模式和灵活地使用,而GAE的优势是通过它分布式的架构能快速伸缩,并且能够最大限度地进行超买,从而在一定用户规模的基础上实现较大的盈利,但是初期构建成本比Cloud Foundry高的多,所以我个人觉得Cloud Foundry这个方案比较适合私有云,而GAE更适合公有云,具体今后的PaaS届那种是潮流,这个很难说。
阅读全文»

(8个打分, 平均:5.00 / 5)

Experiments as Research Validation – Have We Gone too Far?

大师最近的学术会议文章被枪毙了,因为是理论没有数据。大师生气了,写了一篇檄文,讨伐灌水文章。

(1个打分, 平均:5.00 / 5)

CMU老教授对Ph.D的理解

多年前看到的CMU教授写给自己学生的一篇关于如何读Ph.D的文章,甚是经典,特转来与诸位共勉。

 

USEFUL THINGS TO KNOW ABOUT PH.D. THESIS RESEARCH
H. T. KUNG

(Prepared for “What is Research” Immigration Course,
Computer Science Department, Carnegie Mellon University, 14 October 1987)
Presntation Outline

1. Introduction
2. Why Ph.D. thesis could be really difficult for a student
3. Types of Ph.D. theses (from Allen Newell)–not a topic of this talk
4. Growth  of  a star (the transformation process that some students go
through to become a mature researcher)–which stage are you in?
5. Stages of Ph.D. thesis research
6. Methods to  get into the depth of a topic (or how to come up with
good ideas)
7. Breaking myths
8. Pitfalls to avoid (easy ones to avoid listed first)
9. Some other general advice
10. All the effort is worth it (believe it or not)

1. Introduction

- Ph.D. thesis is treated very seriously at leading universities.

* Expectation is high.

- Ph.D.  thesis represents a substantial work.  Faculty
often tell other  people  that  “We  have  a  student
working  on  this  area for his or her Ph.D. thesis.”
Amazingly  enough,  this  is  usually  sufficient  to
convince  people that the problem is somehow going to
be solved.

* Ph.D. thesis research is a task to ensure that the student
can   later   take   on  independent,  long-term  research
commitments.  (If a Ph.D.  student does not intend to be a
researcher,  the Ph.D. thesis work is not worth the effort
in general at least at CMU.)

* Through  the  Ph.D.  thesis   process   the   student   is
transformed into a professional researcher.

* Faculty are judged by the theses of their Ph.D. students.

* High  standard  Ph.D.  thesis  is probably one of the most
important  factors  that  contribute  to  the  success  of
graduate education at leading American universities.

* Ph.D.  thesis  is  probably  the  only  real challenge for
getting a Ph.D.  degree.

- Ph.D. qualifier is seldom  a  problem  for  motivated
students.

- Ph.D.  thesis  research  is probably more mechanical than a new
graduate student would think. (Of course the process  is  still
too complex to be automated.)

* Knowing  this  mechanism can be more important than thesis
results themselves.

* Some information presented here may be  relevant  to  your
whole  research career, i.e., it is not just for the Ph.D.
thesis per se.

- This talk consists of pragmatic advice.

* The talk is based on my  personal  experience  (i.e.,  not
based on any serious research)

- I  happen  to have research experience in both theory
and system areas.  We will compare thesis research in
these two areas.

* This  is  a  common sense talk and will have down to earth
discussions.

- “I wish someone told me this before.”

阅读全文»

(1个打分, 平均:3.00 / 5)

图灵奖获得者姚期智教授主题演讲:量子计算

(1个打分, 平均:3.00 / 5)

张益唐的故事 。 孪生素数不再孤独 。论文全文

(1个打分, 平均:5.00 / 5)

Hadoop Security Design

(1个打分, 平均:5.00 / 5)

Memory Errors: The Past, the Present, and the Future

(1个打分, 平均:5.00 / 5)