博文

目前显示的是 六月, 2015的博文

sublime latextool 多文件支持

在使用sublime 结合latextool 使用的过程中,如果是多文件环境的话,需要在每个子文件的头部添加如下代码: %!TEX root = ../dissertation.tex 等号后面是主文件相对于当前子文件的相对路径 这样就可以使得:1)编译的时候子文件可以脱离父文件进行编译;2)实现编译后从子文件到pdf文件的正向搜索以及定位;3)成功编译以后在pdf文件中定位到当前源文件中光标所在的文中的位置。

解决 sublime text 中文输入下 输入法选词框无法跟随的问题

在sublime text中编辑中文文档的时候,输入法(bing输入法)的选词框不能跟随光标在正在输入的位置移动,而是一直固定在某一个地方。这样在选词的时候相当不方便。解决方案是安装 IMESupport 包就可以解决这一问题。

SDN: 到底是谁的狂欢

私以为,无论是 SDN ,还是 OpenFlow ,或是其它与其相伴所产生出来的各种概念或是技术,其核心的思想都可以规约到 Open 这一点上来。当前已有的很多应用需求和使用场景已经很清晰的表明,目前的 TCP/IP 协议已经很难满足不断新出现的业务的需求。但由于 TCP/IP 协议作为目前 Internet 事实的标准,其具有巨大的部署量,因此想从整体上对其进行全局的变革是很困难也是很不实际的,因此最近十几年来一直有很多新的针对 TCP/IP 在各种应用场景下的修改,新的 RFC 也是不断被提交和通过。但是与计算机领域的发展速度相比,网络领域的发展可以说是止步不前。借助通用的硬件平台架构,各种处于应用层的软件应用不断涌现出来,以适应各种场景的使用需求,从而创造出了很多具有很高价值的应用。但是反观网络领域的应用,受限于较为封闭的架构, Cisco 、 Juniper 等把握了网络组件整体解决方案的公司对网络的发展形成了较强的主导能力,这严重阻碍了网络技术的发展,因此对于开放网络架构的需求也是越来越强烈。 既然我们寻求网络的开放,那我们就需要问自己几个问题: 1 )我们到底需要开放什么, 2 )怎么做,以及最终的 3 )开放以后可以为今后的网络世界带来怎样的变化。 OpenFlow 的第一篇文章正好回答了前两个问题以及第三个问题的一部分。以 OpenFlow 为主要技术的观点认为,可以将传统网络中路由控制和数据转发这两个层面的功能分离,相对应的则是网络中的硬件不再负责全局的路由信息,转由一个专属的路由控制器来负责。而具体的实现则涉及集中式的控制器、代理( plugin ),以及其它相配套的协议完成。可是最后一个问题其认为易于进行路由控制这点,私以为它的观点则过于狭隘了。个人认为,在未来的一段时间内,网络世界将会是以上层应用、服务为主的以内容为导向的世界。上层应用的欣欣向荣反而映衬除了下层网络发展方向的局限性。然而当网络的控制层面从数据层面剥离出来,其带来了更为灵活的网络使用方案,利用这一点可以很方便地实现很多以前传统网络很难实现的功能,例如 in-network 的计算等。 可以想象,借助控制层面灵活多样的特性,以后的网络也可以像计算机领域一样,涌现出各种适用于各种场景的应用。正是看到软件的灵活性,用软件来定义网络的行为这一想法得到了大多数人

解决多文件下 Sublime text + LatexTool \cite 命令无法触发自动补全

Sublime Text  是一款非常优秀的文本编辑器,通过加载插件可以支持多种语言的语法高亮以及自动补全。 本文主要解决一个主文件而有多个子文件情形下,Sublime Text 在使用 LatexTool插件时,\cite 命令无法触发参考文献自动弹出的问题。 具体原因就不细说了,直接上解决方案。 在每个子文件的开头加如下代码 \iffalse \bibliography{../contents/reference.bib} \fi 其中../contents/reference.bib表示参考文献bib文件与主tex文件的相对路径。