ios项目分布式编译

❶ Visual Studio 2010生成的MFC项目太大了

采用分布式编译－IncrediBuild

具体的用法网上有很多

IncrediBuild与本例的工程、Makefile、脚本上传了，下载地址：
http://download.csdn.net/detail/ceofit/4409315
IncrediBuild3.61.1下载地址:
http://download.csdn.net/detail/ceofit/4409322
开发大型项目一次编译过程经常几个小时甚至一天，光靠PC跑很难满足开发需求，再加上敏捷开发每日集成，可能还要运行大量的静态检查、测试用例执行等，所以，不可避免的需要使用分布式编译

❷ iOS 和 HarmonyOS(鸿蒙系统)更安全的是

HarmonyOS(鸿蒙系统)更安全，苹果系统经历事件检验和公司以及国家信用大量事实来看均不是安全的系统，只是和大部分系统一样没有病毒而已，没有病毒并不代表没有木马后门，只是没有影响你使用的病毒，但有窃取隐私和数据的后门以及无时无刻的收集资料！
1、初识鸿蒙，混沌中生
鸿蒙是谁？从哪里来？要干什么？
2019年8月9日，华为在开发者大会HDC.2019上正式发布了鸿蒙操作系统，该系统率先部署在智慧屏、车载终端、穿戴等智能终端上，同时越来越多的智能设备也开始使用开源的鸿蒙OS。华为消费者业务CEO余承东在介绍鸿蒙OS开发初衷时表示：“随着全场景智慧时代的到来，华为认为需要进一步提升操作系统的跨平台能力，包括支持全场景、跨多设备和平台的能力以及应对低时延、高安全性挑战的能力，因此逐渐形成了鸿蒙OS的雏形，可以说鸿蒙OS的出发点和android、iOS都不一样，是一款全新的基于微内核的面向全场景的分布式操作系统，能够同时满足全场景流畅体验、架构级可信安全、跨终端无缝协同以及一次开发多终端部署的要求，鸿蒙应未来而生。”
不得不佩服华为远见卓识的发展战略以及自力更生的顽强斗志，就在最近，华为又推出HMS
Core（华为移动服务，Huawei Mobile Services），以及App Gallery
（主要面向海外华为手机用户的应用商店）。足以说明，华为已经正式把自主研发的产品应用生态放到台面上，和谷歌、苹果硬刚了。这个生态究竟能否稳固壮大，继而出现“三足鼎立”的局面呢？我们拭目以待。
下面，咱们回到今天的主角鸿蒙OS，来欣赏一下它的鸿鹄之志（开辟天地的壮志）吧！
（图片来源及版权所有：鸿蒙学堂）

2、鸿蒙OS凭什么与谷歌的Android、苹果的iOS竞争？
当前，用于智能手机的操作系统天下两分，一哥是安卓，二哥是苹果，近乎达到垄断的地步。那么，初出茅庐的鸿蒙OS可以撼动两寡头的地位进而在市场上分一杯羹吗？我们且看鸿蒙OS的四大技术特性，孰优孰劣，自有分晓。
（1）分布式架构首次用于终端OS，实现跨终端无缝协同体验
鸿蒙OS的“分布式OS架构”和“分布式软总线技术”通过公共通信平台，分布式数据管理，分布式能力调度和虚拟外设四大能力，将相应分布式应用的底层技术实现难度对应用开发者屏蔽，使开发者能够聚焦自身业务逻辑，像开发同一终端一样开发跨终端分布式应用，也使最终消费者享受到强大的跨终端业务协同能力为各使用场景带来的无缝体验。
（2）确定时延引擎和高性能IPC技术实现系统天生流畅
鸿蒙

OS通过使用确定时延引擎和高性能IPC两大技术解决现有系统性能不足的问题。确定时延引擎可在任务执行前分配系统中任务执行优先级及时限进行调度处理，优先级高的任务资源将优先保障调度，应用响应时延降低25.7%。鸿蒙微内核结构小巧的特性使IPC（进程间通信）性能大大提高，进程通信效率较现有系统提升5倍。
（3） 基于微内核架构重塑终端设备可信安全
鸿蒙OS采用全新的微内核设计，拥有更强的安全特性和低时延等特点。微内核设计的基本思想是简化内核功能，在内核之外的用户态尽可能多地实现系统服务，同时加入相互之间的安全保护。微内核只提供最基础的服务，比如多进程调度和多进程通信等。
鸿蒙OS将微内核技术应用于可信执行环境（TEE），通过形式化方法，重塑可信安全。形式化方法是利用数学方法，从源头验证系统正确，无漏洞的有效手段。传统验证方法如功能验证，模拟攻击等只能在选择的有限场景进行验证，而形式化方法可通过数据模型验证所有软件运行路径。

鸿蒙OS首次将形式化方法用于终端TEE，显着提升安全等级。同时由于鸿蒙OS微内核的代码量只有Linux宏内核的千分之一，其受攻击几率也大幅降低。
（4）通过统一IDE支撑一次开发，多端部署，实现跨终端生态共享
鸿蒙OS凭借多终端开发IDE，多语言统一编译，分布式架构Kit提供屏幕布局控件以及交互的自动适配，支持控件拖拽，面向预览的可视化编程，从而使开发者可以基于同一工程高效构建多端自动运行App，实现真正的一次开发，多端部署，在跨设备之间实现共享生态。华为方舟编译器是首个取代Android虚拟机模式的静态编译器，可供开发者在开发环境中一次性将高级语言编译为机器码。此外，方舟编译器未来将支持多语言统一编译，可大幅提高开发效率。
3、鸿蒙OS问题集锦
（1）鸿蒙OS的项目背景
人工智能发展迅猛，已经影响和渗透到许多科技行业和传统行业，智能化是必然的趋势。机器智能化是必然的，但是机器种类众多，若需要智能互联，就要求操作系统能适应多种设备多种终端。这意味着，操作系统需要满足更高的要求，以适用不同种类的机器，并保持分布式的互联互通。为迎接和拥抱AI全场景时代和万物智能互联时代，华为特别定义出下一代的基于微内核的全场景分布式操作系统——鸿蒙OS。 华为的初衷是，自立自强，开放合作，并努力做到核心技术上不受制于人不局限于人，这也是让华为更加领先的原因之一。
（2）什么是全场景？
根据鸿蒙OS架构设计，系统可运行在智慧大屏、穿戴、车机、音响、手表、手机、PC等等各种各样设备。通过一套系统，一个OS实现模块化解耦，对应不同设备可以弹性部署，不管硬件能力强还是硬件能力弱的，都可以一套操作系统，可以统一在不同硬件平台上进行加载部署。同时应用强大灵活统一部署能力，我们一套OS能够运行在不同硬件能力上进行部署，适配丰富的万物互联时代IoT时代能力的操作系统。
（3）什么是分布式架构？
目前，我们目前所有的主流OS架构都是集中式的，即你的手机OS和你家的智能电视的OS各自独立，除了共同享有后台的数据，本身没什么联系。打个比方，即使你在手机和智能电视上同时打开一个APP，现在的实现也是各自运行各自的，你手机的操作不会影响到智能电视上APP的运行，除非是改了后台保存的数据。而华为的分布式OS，可以实现应用的协同处理。你在手机上的操作，可以同时在智能电视的APP界面上得到体现，手机关闭APP，电视上的APP也关闭。这就是多终端的协同处理，鸿蒙OS可以把多个终端统一管理，联合来实现某项功能。
（4）为什么叫鸿蒙？
鸿蒙在中文里面可能有“开天辟地”的意思，最接近的英语单词就是Genesis，开天辟地的意思。由于用汉语拼音表达鸿蒙太难发音了，华为给取名Harmony，希望给世界带来更多和平、方便。
（5）鸿蒙OS的研发始于何时？
华为10年前就开始探索鸿蒙。现在投入的人力接近5000人，短期内要把整个系统完善，所以工作量非常大。
（6）鸿蒙OS主要特点是什么？
分布架构、天生流畅、内核安全、生态共享四大特点。

鸿蒙OS在分布架构上，实现模块化解耦，对不同设备进行可弹性部署。采用分布式软总线核心技术，将表示层、会话层、传输层和网络层等协议精简为一层，能提升有效载荷。还通过多方面提升IPC性能，在进程间通信效率提升5倍。
（7）鸿蒙OS可以用在智能手机上吗？
鸿蒙OS已经完全达到具备商用的程度，随时都可以出鸿蒙系统的手机，华为也做好了全面的准备。但华为还是希望继续使用全球共用开放的手机操作系统和生态，换句话说，一个开放的安卓系统和生态依然是我们的首选。 鸿蒙未来在穿戴设备、车机、PC等都可以使用。
（8）什么是微内核，它有什么特点？
所谓微内核，当然是相对宏内核来说的。微内核是提供操作系统核心功能的内核的精简版本，微内核仅仅提供基础的系统运行能力，以及为不同的程序/进程间提供一种消息的交互机制。而宏内核相当于一个是一个大主管，提供很全面的系统运行功能，例如时间管理、内存管理，文件管理，网络管理等等，安卓就是一种宏内核的OS。微内核的好处就是系统运行效率高，系统更加健壮，不容易出问题。微内核的最大的问题就是进程间的消息交互的效率不高，如果有很多的消息同时交互，可能会有消息丢失、重传导致系统反应变慢。
宏内核不存在这个进程交互的消息通信问题，宏内核的系统功能常驻内核和内存，执行效率的确高一点。但是宏内核越来越多的功能会让系统越来越冗余，对系统硬件的要求很高，而且内部模块过于冗余，维护调试越来越难。
所以，宏内核的OS系统不适合一些轻量级的应用，如物联网。谷歌自己也在研究微内核的OS，为了万物互联，打造统一的OS，微内核的OS是必须的。但是华为的鸿蒙OS比谷歌的Funchsia走的更快了一些，因为鸿蒙在荣耀智慧屏马上要商用了。
（9）鸿蒙OS如何做到低延时高性能？
鸿蒙 OS通过使用确定时延引擎和高性能IPC两大技术解决现有系统性能不足的问题。我们在前面说了，微内核的OS，可能会出现大量的进程间的消息通信时，大量进程间消息一拥而上，导致大量消息被阻塞，系统性能下降的问题。
鸿蒙OS的这个特性就是解决这个问题。鸿蒙OS内部把不同的进程消息确定优先级，采用专业的调度算法来合理调度进程间的通信消息，高优先级的应用优先保障，低优先级的应用排队处理。
这种机制就让微内核进程间的通信变的有序，不会出现大家一拥而上导致消息丢失的现象。其实这种基于优先级消息的调度机制在华为的高端通信设备，如路由器设备中早就使用，只是把这种机制用在了鸿蒙OS。
（10）为什么鸿蒙OS的安全性更高？
鸿蒙OS采用微内核设计，微内核本身的健壮性和安全性就比宏内核高很多。微内核设计的基本思想是简化内核功能，因此不存在和系统功能的耦合性，让整个系统相对健壮。
宏内核集成了很多系统功能，功能越复杂，系统越复杂。虽然系统功能的通信效率有所提升，但是复杂的耦合性让系统的故障率也更高，这是宏内核OS的特点。
华为的鸿蒙OS基于微内核，因此可以让整个系统更加健壮，不会因为对系统功能的攻击影响整个系统的稳定性。同时通过华为先进的验证测试算法，可以确保整个OS更加安全，在受到攻击的时候系统更加稳定。
（11）鸿蒙OS如何提高开发效率？
鸿蒙OS支持多终端的开发IDE，支持多语言统一编译。也就是开发者可以一次性的生成在不同类型的终端中运行的APP。这个策略是和鸿蒙的跨多终端部署的策略紧密相关，如果相同的或不同的终端都需要重新编译适配，那么这个对开发人员典型是不友好的。
也就是如果开发者的应用，需要同时在手机、车载、物联网路由器使用，那么如果使用鸿蒙OS加上方舟编译器，只需要编译一次就可以，这样就可以实现多终端的部署和共享。
华为的方舟编译器可以为开发者在开发环境中将高级语言编译为系统底层的机器语言，机器语言的执行效率更高，同时也可以屏蔽不同的虚拟机的差异。
（12）鸿蒙是什么条件的开源 ？
鸿蒙开源是一个全面的开源。为了技术保密和核心的东西，在有一些地方分节奏开源，最终都会开源。

❸ 鸿蒙和ios对比如何

鸿蒙和ios对比如下：

1、原理不同

ios是全世界第一个基于FreeBSD系统采用“面向对象操作系统”的全面的操作系统。鸿蒙OS是一款“面向未来”的操作系统，一款基于微内核的面向全场景的分布式操作系统。

2、特性不同

ios全64位技术，可以通过第三方的Mode Selector进行64位和32位切换，依靠NeXT-型程序服务，提供全局拼写检查及其他功能强大的工具。

鸿蒙OS的“分布式OS架构”和“分布式软总线技术”通过公共通信平台，分布式数据管理，分布式能力调度和虚拟外设四大能力，将相应分布式应用的底层技术实现难度对应用开发者屏蔽，使开发者能够聚焦自身业务逻辑。

3、内嵌不同

ios包含了自家的软件开发程序，其重大的特色是名为Xcode的集成开发环境。Xcode是一个能与数种编译器沟通的接口，包括Apple的Swift、C、C++、Objective-C、以及Java。

鸿蒙OS采用全新的微内核设计，拥有更强的安全特性和低时延等特点。微内核设计的基本思想是简化内核功能，在内核之外的用户态尽可能多地实现系统服务，同时加入相互之间的安全保护。

❹ xcode使用方法

xcode使用方法：（以xcode5为例）

1，下载安装好xcode5后，就可以开始ios开发之旅了。首先打开xcode。选择新建一个xcode项目。

❺ ios的安全体系结构

防火墙
Cisco通过建议客户道德定义他们的安全政策来解决这一问题。一旦定义了这些政策，就可以采用多个安全组件来满足政策要求。Cisco IOS安全体系机构的组件包括：防火墙、访问管理、宿主安全、加密。
过去几年，路由器一般是企业的智能资产与其网络之间的唯一东西。路由器被独特地定位、设计和配备，以用来在各种级别的开放系统互连（例如OSI reference model）模型中控制及报告数据流。随着今天网络的可访问性及功能的提高、以及公司通过经济有效的远程访问设备连接，风险程度逐步降低。如果一个路由器被安排提供网络外围安全，那么它通常是指“防火墙路由器”。防火墙路由器内维护访问控目录（ACL），ACL的主要功能是提供过滤。IOS安全提供大量的工具来帮助报靠ACL违规（即非法访问）
ACL违规记账
ACL违规记账：随着时间的推移，企业需要一个历史透视图来弄清哪些ACL已经经过测试。这种知识给网络管理人员提供了对入侵者是如何尝试进入某企业网络的一个了解。ACL违规记账提供来源和目的地地址信息、来源和目的地端口号码以及包个数。
ACL违规日志记录
在今天的网络世界，提供强大的防火墙功能已不足以解决问题，网络管理人员需要一个集中化报告选项。过去，网络管理人员在发生损害之前不知道他们已经受到黑客的攻击。唯一可用的早期告区工具是扫描主机日志文件。尽管这仍然是一种优异的安全诊断方法，但是它不能很好地扩展。ACL报告工具通过提供违规信息和网络周边预防，给管理人员提供帮助。IOS包含ACL违规日志记录，给管理人员提供定期的系统日志记录，可以实时确实ACL违规。
网络地址转换
网络地址转换（NAT）：与全球Internet连接的网络数量急剧增加，造成了未来连接可用地址的迅速消耗。而World Wide Web对这种耗尽又起到了推波助澜的作用；而Internet正以每年30%到50%的速度发展。根据目前的估计，3到10年内，剩下的氖 Internet地址将全部用完。
Cisco IOS框架
专用网络服务
IOS可以概念化为一个操作系统，为一个全面的协议族提供全面的网络服务。网络服务可以被分成许多不同的功能；下图将它们分成通用和专用服务。专用服务包括交换、路由以及几乎适用于跨局域网、广域网和IBM/SNA环境的所有数据联网协议的专门化服务。
通用网络服务
通用网络服务包括支持IOS体系结构的增值功能，并提供企业级解决方案，来满足客户对安全、服务质量、VLANs配置管理和路由以及（通信）流量管理的需求，进而提高网络性能和可靠性。通用网络服务还提供协议处理服务，例如转换、加密和压缩。
路由协议
通过网络互联，IOS支持许多路径恢复协议以及其他路由协议特性供基于政策的路由配置和管理。
安全
安全：重点强调特性要求，例如通过防火墙提供的资源保护，访问控制，以及与用户验证机制（例如锁定和密钥安全）的集成。
服务质量
服务质量：介绍在互联网内提供服务质量的IOS特性和功能。服务质量对多媒体应用程序支持至关重要。这里所讲座的IOS特性包括几种排队机制（这些可能在流量管理部分讨论）和资源保护协议（RSVP）。
虚拟局域网
VLANs：简要介绍Cisco在VLANs配置中部署路由和交换的IOS支持。
流量管理
流量管理：包括根据用户（来源和目的地）、局域网和广域网记迪斯科以及RMON标准支持进行的流量模式测量。本部分将讨论Cisco的NetFlow Switching（尽管理论上说可能属于服务质量部分）。
协议处理
协议处理：介绍多媒体和协议类型的集成、协议转换、加密和压缩以及IBM SNA和TCP/IP网际互连（取决于多协议路由和转换）的一般类别。SNA的TCP/IP集成在InterWorks Business Unit部分讨论。本部分将围绕压缩和协议转换介绍IOS特性。
总结
作为本单元的一个总结，我们将提供IOS市场模型。该模型包括5个功能性领域，所有领域都有许多相关的特性。它简单的提供了在一个网际互连解决方案的上下文内位IOS特性的另一种方法。
Cisco IOS处理办法集
从IOS Granularity到特性级
上图总结了IOS向解决方案集的发展过程。由于许多专门的网络服务特性已经从IOS核心分离，因而解决方案集是可能的。尽管Cisco目前能够提供它所说的特性集-例如企业特性集或桌面特性集，但是这些都是受到IOS核心和子系统相关性限制的预封装解决方案。随着解决方案集的发展，它们将获得得更加高级的层次地址：作为专门的特性实体，而且是作为核心或子系统定义去发展（不过，一般总会有某些级别的子系统定义。）
客户为重点的解决方案
IOS成为一咱以客户为重点的技术；它提供专门满足客户主要的技术及商业需求的网际互连功能和特性。客户可以在IOS基本平台之上有效地设计他们自己的特性体系结构。
可伸缩性和投资保护
由于客户选择满足他们要所需的核心特性，因此可以大幅度降低IOS开销。IOS可以利用客户现有的硬件和基础设施投资进行更好地扩展，从而提供投资保护以及更好的网络寿命周期拥有成本。
降低复杂性
IOS复杂性降低，并进而带为客户互联网络复杂性的降低。由于IOS系统及特性间相关性减少，因此解决方案集有助于使统一系统中可能发生的并行损害最小化。实际上，许多与一个全面特性IOS的实现相关的要求都可以实现最小化。
安全介绍
Cisco从几个方面考虑安全问题。在企业设备中、安全通常基于安全保护、闭路电视和卡密钥入口系统。有了这些措施，企业可以放心，他们的物理及智力资产将得到保护。Cisco的安全方案允许企业通过使基于政策的组件及IOS安全体系结构，来扩展这一模型。IOS安全体系机构已经经过10多年的技术革新发展历程、它为企业的安全政策提供基础。IOS安全基于多个重叠的解决方案，这些解决方案一起维护企业的安全完整性。
企业必须决定何时在用户的访问和工作效率与可能被用户视为限制的安全措施之间进行折衷。一方是访问和工作效率，另一方是安全。一个好的设计的目标是提供一个平衡，同时从用户的角度看尽可能少增加限制。有些非常合理的安全措施，例如加密，不限制访问和效率。另一方面，低劣的安全计划可能造成用户效率和性能的降低。那么，企业在维护安全的努力中要冒多大的访问和效率风险呢
设计目标
IOS是围绕下列目标设计的：
模块性：IOS为大量的协议和协议族提供支持，运行于多平台并坚持独立于硬件的设计标准（硬件隔离）。
速度最快：IOS能使Cisco为网络协议提供最快的平台实现。
网络互连：IOS支持包括路由、桥接和交换技术的需求。
高性能平台：IOS由多个RISC处理器体系结构（MIPSRxxxx、Motorola680xx）支持。
分布式：IOS为分布式体系结构的部署提供基础。
环境：IOS提供一个支持大型企业需求的软件开发环境。
多维支持
IOS为LAN介质，WAN协议，以及各种功能，包括路由、交换、集令、IBM、协议转换及许多其他服务提供支持。
设计结果
IOS设计为客户提供完成下列任务的能力：
建立特大规模的网络。
在远程访问链接中，维护多协议支持。
全面集成IBM/SNA和互联网络环境。
开发基于IOS功能的广泛的安全策略。
在互联网络内设计和维护优良的流量控制和服务质量参数。
优化网络带宽和操作资源。
支持互联网络上的多媒体应用。
路由器IOS 的升级方法
将系统软件备份到TFTP服务器 flash：tftp
将TFTP服务器中的系统软件下载到路由器中 tftp flash：
TFTP 软件可以从Cisco网站上下载，文件名为 Tftpstv.exe 此软件可在Windows 95/98/2000/NT上安装，在升级IOS前必须先运行此软件，并通过菜单设置Root 目录为新系统文件所在目录。
设置PC机IP地址与路由器以太网端口IP地址在相同网段
假设计算机的IP地址为：e.e.e.e
假设IOS文件放在C：IOS 子目录下
在这台计算机上运行TFTP Server 软件，把文件目录设置为：C：ios
在这台路由器上进入特权模式
Router# tftp flash
Address or name of remote host []?e.e.e.e
Source filename []?c5300-is-mz.121-2.bin
Destination filiname [c5300-is-mz.121-2.bin]?
Accessing tftp：//e.e.e.e/c5300-is-mz.121-2.bin …
Erase flash ：before ing ?[confirm]
Erasing the flash filesystem will remove all file!Continue?[confirm]
Erasing device … eeeeeeeeeeeeeeeeeeeeeeee….erased
Loading c5300-is-mz.121-2.bin from e.e.e.e (via fastethernet 0/0)
认识Cisco IOS的访问权限
许多工作在Cisco IOS之上的网络管理员从未费心去考虑过他们正在使用的权限等级或这些等级的意义。然而，Cisco IOS实际上十六种不同的权限等级。David Davis论述了这些不同的等级并且向你介绍在配置这些权限时需要用到的主要命令。
你知道为什么Cisco IOS用不同的命令提供了16种权限等级？许多工作在Cisco IOS环境中的网络管理员从未费心去考虑过他们正在使用权限等级或这些等级的意义。
当在Cisco IOS中进入不同的权限等级时，你的权限等级越高，你在路由器中能进行的操作就越多。但是Cisco路由器的多数用户只熟悉两个权限等级：
用户EXEC模式－权限等级1
特权EXEC模式－权限等级15
当你在缺省配置下登录到Cisco路由器，你是在用户EXEC模式（等级1）下。在这个模式中，你可以查看路由器的某些信息，例如接口状态，而且你可以查看路由表中的路由。然而，你不能做任何修改或查看运行的配置文件。
由于这些限制，Cisco路由器的多数用户马上输入enable以退出用户EXEC模式。默认情况下，输入enable会进入等级15，也就是特权EXEC模式。在Cisco IOS当中，这个等级相当于在UNIX拥有root权限或者在Windows中拥有管理员权限。换句话说，你可以对路由器进行全面控制。
因为网络只是由少数人维护，他们每个人通常都有进入特权模式的口令。但是在某些情况下，那些小型或中型公司会进一步增长，而权限问题会变得更加复杂。
许多时候，当有一个支持小组或不需要在路由器上进行过多访问的缺乏经验的管理员时问题就出现了。或许他们只是需要连接到路由器以查看运行配置或重新设置接口。
在这种情况下，这些人会需要介于等级1到等级15之间的某个等级进行操作。请记住最小权限原则：只赋予必需的最少的访问权限。
有很多可行的配置IOS用户和权限的方法，我无法在一篇文章中详细描述每一种方法。所以，我们将关注你在配置权限时用到的基本命令。
Show privilege：这个命令显示目前的权限。这里给出一个例子：
router# show privilege
Current privilege level is 3
Enable：管理员通常使用这个命令以进入特权EXEC模式。然而，它也可以带你进入任何特权模式。这里给出一个例子：
router# show privilege
Current privilege level is 3
router# enable 1
router> show privilege
Current privilege level is 1
router>
User：这个命令不仅可以设定用户，它还可以告诉IOS，用户在登录的时候将拥有何种权限等级。这里给出一个例子：
router(config)# username test password test privilege 3
Privilege:这个命令设定某些命令只在某个等级才能用。这里给出一个例子：
router(config)# enable secret level 5 level5pass
Enable secret：默认情况下，这个命令创建一个进入特权模式15的口令。然而，你也可以用它创建进入其他你可以创建的特权模式的口令。
让我们考察一个例子。假设你想创建一个维护用户，他可以登录到路由器并且查看启动信息（以及等级1的其他任何信息）。你将输入的命令可能是：
router(config)# user support privilege 3 password support
router(config)# privilege exec level 3 show startup-config
需要注意的是并不需要enable secret命令，除非你想让以等级1登录进来的用户为了能提升到等级3而使用口令。在我们的例子中，新用户（维护）已经处在等级3而且无需额外的enable secret口令来登录。
除此之外，需要注意的是这个配置假设你已经拥有一个配置好的使用用户名和口令的路由器，该例子还假设你已经为等级15定义了enable secret命令，你有一个拥有等级15的超级用户，而且你已经在超级用户权限下保存了启动配置文件。
被删除的的快速恢复
1、先用终端的一台机器级连线连接cisco route的俄Enternet0 口
2、然后，在终端上安装TFTP软件，在把需要恢复的IOS文件（如：C2600.BIN）拷贝到TFTP安装好的目录里面。
3、在CISCO的ROMMON界面下：（CTRAL+BREAK）
设置如下
IP_ADDRESS=192.168.1.1 (设置CISCOEnternet0 口的IP地址)
IP_SUBNET_MASK=255.255.255.0 (设置CISCOEnternet0 口的子掩码)
DEFAULT_GATEWAY=192.168.1.1 （将网关设置为CISCOEnternet0 口的地址）
TFTP_SERVER=192.168.1.2 （TFTP终端计算机的IP地址）
TFTP_FILE=C2600.BIN (需要传送的IOS文件，将此文件放在安装好的TFTP目录里)
tftpdnld （执行传送命令）
在Cisco设备上用FTP传IOS文件
用FTP在路由器和服务器之间传输文件，是在Cisco IOS Release 12.0中引进的。因为FTP是一个使用TCP/IP的面向连接的应用，所以它比TFTP提供更好的吞吐量和成功率，TFTP是用UDP/IP作传输服务的无连接应用。
作为一个面向连接的应用，在传输IOS映像之前，FTP需要使用登录和口令。建立路由器到FTP服务器的登录用户名和口令，通过使用路由器上特权模式的配置操作完成。为了准备用FTP进行IOS映像传输，将再次使用下列命令顺序来提供这些信息给路由器IOS：
enable
enter password xxxxxxxxx
configure terminal
ip ftp username login_name
ip ftp password login_password
end
write memory
像用TFTP一样， enable命令以及跟着的特权口令，允许操作员获得使用特权模式命令的权力。Configure terminal命令执行路由器的配置模式。在这种模式下，可以输入任何或全部选项与定义来修改、添加或删除路由器运行配置。与目标FTP服务器上一个登录名字相关联的FTP用户名，通过ip ftp username命令提供给路由器IOS。ip ftp username 命令中的login-name变量，定义了当Copy ftp:命令中未指定登录名时路由器使用的缺省用户登录名。
login-name变量是目标FTP服务器上的一个有效用户名。ip ftp password命令是与目标FTP服务器上指定的login-name相关联的缺省口令。end命令退出配置模式。执行完这些命令后，路由器IOS配置有了连接到FTP服务器上所必需的FTP参数。命令行最后的write memory命令，把路由器的运行配置写到路由器的NVRAM中以永久保存。保存运行配置到存储器，就在加电重启和路由器重新装载之间保存了刚输入的配置信息。
把当前IOS映像备份到一个FTP服务器，通过输入如下命令完成：
device:filename
ftp:[[[//login-name[:login-password]@]location]/directory]/filename]
使用此命令，路由器管理员通过device:filename变量的device参数，来指定路由器上闪存位置，通过filename参数指定映像的名字。filename是闪存设备上找到的一份映像名字。
下载
login-name和login-password值，可以是ip ftp username和ip ftp password命令设置的值。
然而，要记得这些命令仅用于缺省情况。若这些命令未被输入，FTP服务器提示路由器管理员输入用户名和口令。剩下的location、directory和filename变量定义与TFTP中相同。
例如，从闪存传送一份映像到名为FTP SERVER的FTP服务器，路由器管理员输入下列命令：
flash:ios-image
ftp://joev:jandj@FTPSERVER/Cisco/image/ios-image
名为ios-image的映像被复制到相对于FTP服务器的授权用户joev的目录结构的//cisco/image/目录中。名为FTP SERVER的服务器的IP地址，由路由器向在配置文件中找到的DNS服务器执行一次DNS查询而确定。
传输一份新映像文件到路由器通过下面的 ftp:命令而执行：
ftp: [[[//[login-name[:login-password]@]location]/directory]/filename]device:[filename]
ftp:命令使用与前面讨论的相同的变量。使用此命令时，只需如下指出：
ftp: slot1:
用这种缩写格式的命令时，缺省的login-name和缺省的login-password被传送到FTP服务器。
如果路由器的缺省值未被指定，FTP服务器将提示输入用户名和用户口令。该FTP连接像对待其他连接一样，并且路由器管理员输入将取回的文件的filename。注意，在此例中，与登录名相关联的缺省目录结构必须有所请求的filename供获取。此例中所请求的文件将被存储在指定的slot1的闪存卡中。
Cisco IOS使用一种缺省机制，来提供FTP login-name和login-password值。对login-name，IOS将使用下列标准：
1) 如果指定login-name的话，在命令中指定。
2) 如果该命令被配置，在ip ftp username命令中设置login-name。
3) 缺省的FTP登录名anonymous。
password由下面的决定：
1) 如果指定login-password的话，在命令中指定。
2) 如果该命令被配置，在ip ftp password命令中设置login-password。
3)路由器生成一个login-password: login-name @ routername.domain。变量login-name是与当前会话相关联的登录名，routername是路由器配置的主机名称，domain是路由器的域名字。注意复制操作可以通过按下ctrl-^ 或ctrl-shift-6来取消。这将终止当前的复制操作，但部分复制的文件将保留在闪存中直到被删除。

❻ android系统编译能用分布式编译吗

项目越来越大，每次需要重新编译整个项目都是一件很浪费时间的事情。Research了一下，找到以下可以帮助提高速度的方法，总结一下。
1. 使用tmpfs来代替部分IO读写
2.ccache，可以将ccache的缓存文件设置在tmpfs上，但是这样的话，每次开机后，ccache的缓存文件会丢失
3.distcc,多机器编译
4.将屏幕输出打印到内存文件或者/dev/null中，避免终端设备（慢速设备）拖慢速度。

tmpfs
有人说在Windows下用了RAMDisk把一个项目编译时间从4.5小时减少到了5分钟，也许这个数字是有点夸张了，不过粗想想，把文件放到内存上做编译应该是比在磁盘上快多了吧，尤其如果编译器需要生成很多临时文件的话。
这个做法的实现成本最低，在Linux中，直接mount一个tmpfs就可以了。而且对所编译的工程没有任何要求，也不用改动编译环境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel来测试一下编译速度：
用物理磁盘：40分16秒
用tmpfs：39分56秒
呃……没什么变化。看来编译慢很大程度上瓶颈并不在IO上面。但对于一个实际项目来说，编译过程中可能还会有打包等IO密集的操作，所以只要可能，用tmpfs是有益无害的。当然对于大项目来说，你需要有足够的内存才能负担得起这个tmpfs的开销。
make -j
既然IO不是瓶颈，那CPU就应该是一个影响编译速度的重要因素了。
用make -j带一个参数，可以把项目在进行并行编译，比如在一台双核的机器上，完全可以用make -j4，让make最多允许4个编译命令同时执行，这样可以更有效的利用CPU资源。
还是用Kernel来测试：
用make： 40分16秒
用make -j4：23分16秒
用make -j8：22分59秒
由此看来，在多核CPU上，适当的进行并行编译还是可以明显提高编译速度的。但并行的任务不宜太多，一般是以CPU的核心数目的两倍为宜。
不过这个方案不是完全没有cost的，如果项目的Makefile不规范，没有正确的设置好依赖关系，并行编译的结果就是编译不能正常进行。如果依赖关系设置过于保守，则可能本身编译的可并行度就下降了，也不能取得最佳的效果。
ccache
ccache工作原理：
ccache也是一个编译器驱动器。第一趟编译时ccache缓存了GCC的“-E”输出、编译选项以及.o文件到$HOME/.ccache。第二次编译时尽量利用缓存，必要时更新缓存。所以即使"make clean; make"也能从中获得好处。ccache是经过仔细编写的，确保了与直接使用GCC获得完全相同的输出。

ccache用于把编译的中间结果进行缓存，以便在再次编译的时候可以节省时间。这对于玩Kernel来说实在是再好不过了，因为经常需要修改一些Kernel的代码，然后再重新编译，而这两次编译大部分东西可能都没有发生变化。对于平时开发项目来说，也是一样。为什么不是直接用make所支持的增量编译呢？还是因为现实中，因为Makefile的不规范，很可能这种“聪明”的方案根本不能正常工作，只有每次make clean再make才行。
安装完ccache后，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，链到/usr/bin/ccache上。总之确认系统在调用gcc等命令时会调用到ccache就可以了（通常情况下/usr/local /bin会在PATH中排在/usr/bin前面）。
安装的另外一种方法：
vi ~/.bash_profile
把/usr/lib/ccache/bin路径加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
这样每次启动g++的时候都会启动/usr/lib/ccache/bin/g++，而不会启动/usr/bin/g++
效果跟使用命令行ccache g++效果一样
这样每次用户登录时，使用g++编译器时会自动启动ccache
继续测试：
用ccache的第一次编译(make -j4)：23分38秒
用ccache的第二次编译(make -j4)：8分48秒
用ccache的第三次编译(修改若干配置，make -j4)：23分48秒

看来修改配置（我改了CPU类型...）对ccache的影响是很大的，因为基本头文件发生变化后，就导致所有缓存数据都无效了，必须重头来做。但如果只是修改一些.c文件的代码，ccache的效果还是相当明显的。而且使用ccache对项目没有特别的依赖，布署成本很低，这在日常工作中很实用。
可以用ccache -s来查看cache的使用和命中情况：
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到，显然只有第二编次译时cache命中了，cache miss是第一次和第三次编译带来的。两次cache占用了81.7M的磁盘，还是完全可以接受的。
distcc
一台机器的能力有限，可以联合多台电脑一起来编译。这在公司的日常开发中也是可行的，因为可能每个开发人员都有自己的开发编译环境，它们的编译器版本一般是一致的，公司的网络也通常具有较好的性能。这时就是distcc大显身手的时候了。
使用distcc，并不像想象中那样要求每台电脑都具有完全一致的环境，它只要求源代码可以用make -j并行编译，并且参与分布式编译的电脑系统中具有相同的编译器。因为它的原理只是把预处理好的源文件分发到多台计算机上，预处理、编译后的目标文件的链接和其它除编译以外的工作仍然是在发起编译的主控电脑上完成，所以只要求发起编译的那台机器具备一套完整的编译环境就可以了。
distcc安装后，可以启动一下它的服务：
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默认的3632端口允许来自同一个网络的distcc连接。
然后设置一下DISTCC_HOSTS环境变量，设置可以参与编译的机器列表。通常localhost也参与编译，但如果可以参与编译的机器很多，则可以把localhost从这个列表中去掉，这样本机就完全只是进行预处理、分发和链接了，编译都在别的机器上完成。因为机器很多时，localhost的处理负担很重，所以它就不再“兼职”编译了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然后与ccache类似把g++，gcc等常用的命令链接到/usr/bin/distcc上就可以了。
在make的时候，也必须用-j参数，一般是参数可以用所有参用编译的计算机CPU内核总数的两倍做为并行的任务数。
同样测试一下：
一台双核计算机，make -j4：23分16秒
两台双核计算机，make -j4：16分40秒
两台双核计算机，make -j8：15分49秒
跟最开始用一台双核时的23分钟相比，还是快了不少的。如果有更多的计算机加入，也可以得到更好的效果。
在编译过程中可以用distccmon-text来查看编译任务的分配情况。distcc也可以与ccache同时使用，通过设置一个环境变量就可以做到，非常方便。
总结一下：
tmpfs： 解决IO瓶颈，充分利用本机内存资源
make -j： 充分利用本机计算资源
distcc： 利用多台计算机资源
ccache： 减少重复编译相同代码的时间
这些工具的好处都在于布署的成本相对较低，综合利用这些工具，就可以轻轻松松的节省相当可观的时间。上面介绍的都是这些工具最基本的用法，更多的用法可以参考它们各自的man page。
5.还有提速方法是把屏幕输出重定向到内存文件或/dev/null,因对终端设备(慢速设备)的阻塞写操作也会拖慢速度。推荐内存文件，这样发生错误时，能够查看。

❼ C++实现分布式文件解析系统

整个分布式文件解析系统一共有四个角色：任务分配服务器、文件解析服务器、工作站和管理平台。在一个大型的网络中，有若干个用户（即“工作站”）随机地通过“任务分配服务器”向若干个“文件解析服务器”提交文本文件。“文件解析服务器”将收到的文件解析后写入log文件中。“管理平台”负责以可视化的界面观察所有连接到的“任务分配服务器”和“工作站”的ip及工作状态。

任务分配服务器的作用是轮流地将来自“工作站”的文件传送请求转发到每个在线的“文件解析服务器”上，从而避免某个特定的“文件解析服务器”工作负载太重。“任务分配服务器”轮流给所有在线的“文件解析服务器”分配任务。轮流的原则是按每工作站每批轮流，不考虑每批文件的数量多少。当有“工作站”准备传送一批文件时，首先连接任务分配服务器，通知任务分配服务器有一批文件待传。任务分配服务器则把该工作站的IP和端口告诉选定的“文件解析服务器”，以便让“文件分析服务器”能主动和“工作站”连接，并完成该批文件传输。

ps：主动的含义是文件分析服务器主动通过 connect 连接工作站。“任务分配服务器”本身不接收或转发文件。工作站每次都是按批提交文件，一批文件的数量不等。

“文件解析服务器”每收到用户的一批文件后，就自动对该批文件进行“文件解析”。“文件解析”的功能是：

管理平台的作用是采用图形化的方式展示目前在线的工作站，文件分析服务器的工作状态。能展示工作站的IP，工作状态（传文件中或没有传文件）。能展示文件分析服务器的IP，工作状态（接收文件中，文件分析中，没有传文件，没有文件被分析）。当一个工作站或文件分析服务器宕机，能实时更新状态。

整个系统的工作流程如下图所示：

该项目源码在 https://github.com/toMyLord/DistributedFileParsingSystem

src目录下包含 Server 类、 Client 类、 SpecificTime 类。 Server 类用于服务器初始化，监听 socket_fd ，接受来自客户端的连接请求，接收或发送信息，关闭套接字。 Client 类用于客户端初始化，连接服务器，与服务器进行全双工通信，关闭连接。 SpecificTime 类用于获取当前系统的时间，并以规定的格式返回一个 std::string 类型的字符串。上述三个类会被用于所有角色，因此以一个目录的形式单独放在所有角色所属目录外，通过CmakeLists.txt将这些文件的编译相关性联系在一起，从而生成可执行文件。

该目录下为编译 TaskDistribution 所需要的专属文件。在当前目录下的src目录内，定义了 DistributionServer 类，该类内组合了DistributedFileParsingSystem/src目录下的 Server 类。实现 DistributionServer 类的目的是为了使用该类监听特定端口的所有网络连接，并将所有连接的客户端信息都存储在一个 std::vector 容器内。 DistributionServer 类的定义如下：

在 ClientNode 结构体内嵌套的 ClientInfo 结构体声明和定义在DistributedFileParsingSystem/src/server.h文件内， ClientInfo 结构体保存了连接到 server 的客户端的 sockaddr_in 、 socket_fd 以及ip信息。 ClientNode 结构体扩展了一个新的字段 client_state ，该字段用来描述客户端的传输状态。

通过 std::vector<ClientNode> 将所有连接的客户端信息都保存下来。每当有新的客户端连接，就使用 client_node.push_back() 将信息保存在内存中。如果有已连接的客户端断开连接，需要用 find_if() 函数配合 lambda 表达式找到在 vector 中的迭代器，然后断开连接并删除 client_node 中对应的数据。具体过程如下：

TaskDistribution_main.cpp是任务分配服务器可执行文件编译所需的主函数。在该文件内声明了两个 DistributionServer 类的实例 workstation_server 和 parsing_server ，一个 Server 类的实例 manager_server ，分别用来处理来自工作站、文件解析服务器、管理平台的连接。因为任务分配服务器只允许一个管理平台连接，因此管理平台选择 Server 类，因为可能会有大量工作站和文件解析服务器连接至任务分配服务器，因此选择 DistributionServer 来分别监听工作站和文件解析服务器的连接端口。

在主函数中，我选择使用 epoll ——IO多路复用技术来监听工作站、文件解析服务器和管理平台的连接请求，从而实现在单进程中对三个端口进行监听。

当有管理平台连接至任务分配服务器后，任务分配服务器就不再处理来自管理平台的连接请求，直到当前管理平台退出。

当有文件解析服务器连接至任务分配服务器后，任务分配服务器会将文件解析添加至就绪队列，等待来自工作站的请求。每当有工作站发出文件传输请求，就将处于就绪队列顶端的文件解析服务器出队列，并分配给当前工作站用来处理解析任务。处理完文件解析任务后，任务分配服务器会将文件解析服务器重新加入队列。

当工作站连接至任务分配服务器后，任务分配服务器会建立一个新的线程用来处理工作站发出的请求。当工作站发出文件解析请求后，该线程会将就绪队列顶端的文件解析服务器分配给工作站，并一直监控整个解析过程，直到解析完成，将文件解析服务器重新入队列。完成后此线程会重新监听来自工作站的解析请求，直到工作站断开连接，该线程就会消亡。如果工作站发出解析请求后，没有任务文件解析服务器就绪，那么任务分配服务器会每过1s检测一次是否有就绪的文件解析服务器（此处可以改进，将每秒轮询的方式改为等待时长者优先策略）。

该目录下为编译 TaskDistribution 所需要的专属文件。在当前目录下的src目录内，主要实现两个功能： 使用单例模式实现日志文件记录 、 使用状态模式实现文件解析服务器在等待状态和解析状态之间的切换 。

使用单例模式来实现日志记录的 RecordingLog 类的实例只会创建一次，从而避免创建多个日志类实例，造成写入混乱的情况。 RecordingLog 类会将特定信息以 filesteam 的方式写入文件中，具体被记录在日志文件中的信息包括接收来自工作站文件的时间、日期、工作站ip、工作站端口、文件名、文件前8个字节内容、文件总长度。该类的声明情况如下所示：

在本系统的FileParsing程序中，使用状态模式用来处理文件解析服务器的状态转换。文件解析服务器主要有两种状态——等待任务分配服务器发送解析文件请求状态和接受来自工作站的文件并完成解析，写入日志文件的状态。

在第一种状态下，文件解析服务器收到来自任务分配服务器的解析请求后，会将需要主动连接的工作站的ip及端口保存下来，并切换到第二种状态。

在第二种状态下，文件解析服务器根据保存的ip和端口主动连接工作站，连接完成后接收来自工作站的文件信息，解析后通过 RecordingLog 类中的 getLogInstance() 函数将解析后的结果写入日志文件，完成后会将解析完成情况回传给任务分配服务器，在任务分配服务器中，将该文件解析服务器重新添加到就绪队列。之后会主动切换到第一种状态，再次等待任务请求。

这部分程序使用了状态模式，使得文件解析服务器在等待分配任务状态及解析文件状态自动切换，从而保证了两种状态上的逻辑分离，具有非常好的封装性，并体现了开闭原则和单一职责原则：每个状态都是一个子类，如果需要增加状态就只需要增加子类，如果需要修改状态，就只需要修改一个子类即可完成，具有很高的扩展性。

该目录下为编译 WorkStation 所需要的专属文件。在当前目录下的src目录内，定义了 SendDirectory 类。通过该类，可以实现根据输入的一个目录，自动发送该目录下的所有文件。注意，该目录下不可再包含目录。

该目录下为编译 Managerplatform 所需要的专属文件。此目录可以使用QtCreater打开，但是编译还是需要根据DistributedFileParsingSystem/CMakeLists.txt文件通过cmake编译。

该目录下的 ClientThread 类通过继承 QThread 类，实现在Qt中使用线程。在该部分程序运行时，就会创建一个 ClientThread 线程，用于与任务分配服务器建立连接，并不断接受来自任务分配服务发送的有关工作站及文件解析服务器的在线状态以及传输状态。每当有新的信息后，就通过Qt的槽机制，发送给 QDialog ，显示在界面中。

编译完成后会生成四个可执行文件：TaskDistribution、FileParsing、WorkStation、ManagerPlatform。

运行过程如下所示：
首先分别运行每个可执行程序，其中运行两个FileParsing程序（上线两个文件解析服务器）：

在WorkStation程序下输入需要发送的文件目录：

可以在任务分配服务器的log中看到有新上线的文件解析服务器，同时在管理平台也可以看到对应的文件解析服务器。我们通过工作站连续发送三次文件。

实现了整个分布式任务解析服务器框架，整个项目可以正常实现需求功能。
缺陷：任务分配服务器存在不能正常处理所有连接的正常close。

在任务分配服务器处新增了心跳包机制——任务分配服务器会每隔5s向所有连接在线的文件解析服务器和工作站发送心跳包，文件解析服务器和工作站在收到心跳包后，也会主动回应心跳。通过心跳包机制可以很好的处理来自其他连接的断开情况。同时新增了在管理平台退出后，任务分配服务器可以重新接受来自管理平台的连接。

❽ ios git 和svn的区别

GIT是分布式的，SVN不是，这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。
GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提 交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。

❾ 在个人电脑上怎么进行分布式编译服务器的安装

方法一:直接在命令行安装

~$ aptitude install distcc

方法二: 下载distc，解压，编译安装如下：

~$ wgethttp://distcc.samba.org/ftp/distcc/distcc-2.18.3.tar.bz2

~$ tar-jxf distcc-2.18.3.tar.bz2

~$ cddistcc-2.18.3

~$./configure && make && sudo make install