首页 文章 精选 留言 我的

精选列表

搜索[全文搜索]，共10003篇文章
优秀的个人博客,低调大师

《企业级区块链安全白皮书》全文发布(附下载)

即将开播：5月14日，Jenkins在K8S下的三种部署流程和实战演示 近日，绿盟科技、北京航空航天大学、中国移动研究院联合推出《企业级区块链安全白皮书》，旨在对企业级区块链的概念、架构、技术、安全等进行一个全面的介绍，使读者对企业级区块链相关的内容有一个较为深入的了解。 借由本白皮书，我们也想推动安全厂商、高校与区块链服务商、用户的紧密协作。我们深信，跨界合作，共同探索，才能推动企业级区块链安全生态的构建，更好地服务于企业级区块链的用户，真正实现企业级区块链的价值。 观点1： 加快推动区块链技术和产业创新发展，探索“区块链+”模式 2020年1月，国务院办公厅发布《关于支持国家级新区深化改革创新加快推动高质量发展的指导意见》。该意见指出，加快推动区块链技术和产业创新发展，探索“区块链+”模式，促进区块链和实体经济深度融合。 观点2：智能合约不是“完美合约”，安全问题需警惕 从区块链自身的漏洞和安全事件来看，企业级区块链应用还在早期，但随着区块链应用的普及，相关的公开漏洞会越来越多。可以预测大部分漏洞会来自智能合约，特别是不安全的函数、越界等常规安全问题。 观点3：区块链两大安全威胁：勒索病毒、挖矿木马 在与区块链相关的企业安全事件中，勒索病毒和挖矿木马是企业面临的两大安全威胁。匿名货币或加密货币变现的便利性，使得这类恶意攻击会持续一段时间。当然，货币的汇率变化，也会在一定程度上影响这类攻击的态势。 观点4：区块链步入监管时代 由于区块链存在不可删除、事后取证等特性，其合规性要求必然与其它信息服务不同。虽然我国区块链信息服务的监管尚处探索阶段，但国家互联网信息办公室先后发布了三期境内区块链信息服务名称及备案编号，预计后期会持续推进。 观点5：合规是区块链未来唯一出路 随着《网络安全法》等法律的颁布，个人数据的收集、管理、交换都受到了合规性的约束。无论区块链如何应用，都不应该触碰法律的红线。区块链离不开合规，如何能让区块链更加安全、规范是我们要做的事情。 观点6：区块链下一个风口：解决区块链上的隐私保护问题 为了解决区块链上的隐私保护问题，近年来新技术、新机制不断涌现。其中新机制包括通道机制、私有交易、加密授权访问机制等，以及结合前沿密码理论的创新，包括零知识证明、环签名、安全多方计算等。 观点7：区块链，向“安全”而生方能终遇美好 安全厂商、高校与区块链服务商、用户应紧密合作，推动企业级区块链安全生态的构建。区块链的出现，大大提升了安全在企业中的地位。传统的“先推动业务的高速发展，再进行安全建设”模式将不再可行，安全成为区块链的刚性需求。 下载链接：http://blog.nsfocus.net/wp-content/uploads/2020/05/Enterprise-Grade-Blockchain-Whitepaper-.pdf 【责任编辑： 蓝雨泪 TEL：（010）68476606】
2020-05-12
优秀的个人博客,低调大师

PCI Express 4.0规范全文下载，SSD和网卡何时能受益？

PCI Express® Base Specification Revision4.0 Version 1.0 下载链接 http://pan.baidu.com/s/1dFxqX9Z （也可以点击本文底部“阅读原文”） 大家可能看到新闻了，PCIe Express 4.0 v1.0规范终于正式发布，此时距离我撰写支持PCIe Gen4的《初探OpenPOWER9服务器设计：x86不再寂寞》已经过去一年的时间。不知这是否意味着POWER9将会尽快正式发布了呢？ 有意思的是，在10年前PCIe 2.0发布的时候，我写过一篇工作站的评测，提到了对于显卡/GPU的意义，也就是全速x16插槽。 6年前，大约Intel发布第一代Xeon E5的半年之前，我也写过一篇评论，因为LSI已经提前推出了支持PCIe 3.0 x8的6Gb/s SAS控制器和HBA卡。 这次应该是9月底就完成的，整个规范共1293页 今天，在4.0草案标准期间“偷跑”的板卡同样不少，不过x16 lane宽度的显卡/GPU似乎不是当前最紧迫的，毕竟PCIe 3.0的8GT/s每个lane有效带宽接近1GB/s全双工。而对于SSD和网卡就不同了。 56/100Gb网卡、NVMe SSD渴望更大带宽 双端口56Gb InfiniBand HCA，用流行的PCIe 3.0 x8就存在瓶颈了；至于100Gb以太网等，如果不用PCIe x16单端口都发挥不出来，比如我在《4节点近160万IOPS：SDS/超融合测试不能只看数字》测试平台中使用的MellanoxConnentX-4网卡。 至于SSD，目前主流的NVMe用的是PCIe 3.0 x4，实际效率能跑到3.2GB/s就不错了，参见《Intel发布P4500、P4600 NVMeSSD：规格释疑》一文。除了少数高端企业级和发烧型号用x8接口之外，可以说单盘（卡）IOPS达到70-80万x4接口也开始出现瓶颈了。更何况未来会在存储阵列中应用的双端口U.2 SSD，x4 lane会拆分成2个x2来使用。 这样的M.2 SSD转接卡，是当前提高整体带宽的一种选择 如上图，4个M.2 PCIe x4直通转接PCIe x16，对于有些图形工作站等需要极高存储带宽的应用是一种解决方案。上面的卡我在《双Xeon SP只用一个风扇？Precision7920工作站散热设计解析》中曾经提到过，随着Dell新一代工作站机型发布，同样的Ultra-Speed Drive Duo/Quad也可以通过Intel RSTe vROC选项支持NVMe RAID0、1。 如果平台（主板）升级到PCIe 4.0，这种M.2转接方案的带宽理论上也可以翻倍，当然估计一时半会SSD还达不到那么快。 而PCIe 4.0的普及进程却不是太乐观，关于Intel发布不久的Xeon Scalable服务器/工作站平台我写过不少东西，这里随便列出一篇《IntelXeon SP服务器架构曝光：Apache Pass、QuickAssist》。据说Intel要等2019年发布的下一代Xeon平台才会支持PCIe 4.0，POWER由于指令集等方面原因难成主流，AMD又刚把PCIe控制器lane数量做上去（《超越Xeon？AMD Naples服务器的理想与现实》），估计短时间难以染指4.0。 GPU提升I/O的另一个路子——NVLink 除了CPU之外，GPU性能提升的速度似乎更快，不过NVIDIA自己搞出一套解决I/O互连的方式。 上面示意图是一款双CPU+ 4 GPU服务器，1U机箱支持4块300W GPU卡那种，我在《九条大道通GPU：HPC服务器PCIe之灵活应用》曾经介绍过它的PCIe直通和Switch有多种连接方式选择。 如今NVIDIA大力推广NVLINK，并且在一些应用中（比如GPU间显存频繁交换数据）性能提升明显，原有服务器机型也面临升级更新。上图所示Dell PowerEdge C4130就把GPU部分改造成一块NVLINK互连板，上面还是4个GPU模块，只在与CPU通信时才需要经过PCIe交换器，GPU间的带宽增大了。我还没仔细研究，估计是从PCIe卡换成下图这种SXM模块吧。 1U 4颗GPU、2U 8颗GPU是现在比较高的密度 具体来说最新的Tesla V100支持的NVLINK链路比P100还增加了2条（6 vs. 4），只是听说这东西有些贵：） Gen-Z、CAPI等能撼动PCIe吗？ 两个月前我还写过一点相关的： 《Gen-Z互连(上)：Intel缺席的内存中心架构》 《Gen-Z互连(下)：第一步25-100GB/s、PCI-SIG的反应》 还是更欣赏TangJie总说过的一个观点：“这些新的I/O标准，如果想活下来，就必须大家联合起来。” 毕竟这么多年过去，PCIe生态太成熟了。先写到这里吧。
2018-02-11
优秀的个人博客,低调大师

浅析Android 4.0的通知系统（附Android 4.0设计指南全文翻译）

通过手机的通知系统，可以将应用程序的一些重要消息告知给用户。流畅、舒适、友好的应用程序离不开精心设计的消息提醒机制。但是并不是所有的通知都是用户想看的，否则只会给用户造成骚扰，所以要谨慎使用通知。 在对《Android Design》进行翻译时发现：Android系统已经提出了一些关于通知消息的设计建议，故在此分享给大家。 一、何时使用通知？ 通知主要用于对时间敏感（Time Sensitive）的事件，尤其是涉及他人（Involve another person）的同步事件。例如下面的Gtalk和日历发出的通知就是时间敏感，且与人相关的事件。 那么什么时候又不应该使用通知呢？官方的建议是： 不直接针对用户的，或不紧急的信息。例如SNS中与用户没有直接关系的新鲜事。Path可能就犯了这个错误。 正显示在当前屏幕的信息也不必创建一个通知。即正在聊天的时候，就不必再创建关于聊天消息的通知了。 系统可以自己完成而无需用户操作的简单动作，例如保存、同步或者是更新应用程序等。 如果发生错误了，但是应用程序可以快速自我恢复，此时也不必用通知去打断用户，甚至都可以不用让用户知道这个错误。 对于用户不能手动启动或停止的服务，也不必使用通知。 不要为了让用户对你的品牌记忆深刻而创建多余的通知，否则只会让用户反感。想让用户对你的应用程序保持注意力并且提供少量内容的最好方式是提供小部件（widget）给用户，让用户可以将它放到首页。 二、通知的设计指南 1. 使其私有化 其他用户发过来的通知应该在通知里包含用户的头像（Icon/Photo），还要显示通知的标题（Title）、消息内容（Message）、时间戳（Timestamp），以及应用程序的图标（Secondary Icon）。 2. 合并同类通知 如果一个应用程序发出了多个相同类型的通知，而且这些通知都还没被处理的话（被处理的通知会被移出通知抽屉），那么请将相同类型的通知合并为一个。 合并后的通知会有一个总结性的描述，并且能让用户知道一共合并了多少条通知（Number Pending）。 3. 对时间敏感事件的时间戳 默认的系统通知会在通知右上角打上时间戳，如果你认为显示时间戳对你的通知是没有意义的，那你可能就要重新考虑是否值得为这条消息创建一条通知了。如果这条通知确实足够重要，再决定是否不显示时间戳。 常见的需要显示时间戳的通知是通讯通知，如Email、短信、聊天消息这种，用户需要通过时间戳来理解消息的上下文。 4.通知相关的导航机制 如果用户点击了一条通知，此时应该将相关的应用程序打开到可以对通知中提到的内容进行操作的状态。但如果用户点击了一个合并的通知，应该去到列表页面（内容页的上一层级），后面第三部分会详细阐述。 5.自我清理 有些通知会在某个时间点出现告知用户一些相关的信息和提示，但是如果过了那个时间点，这个通知可能对用户来说就不重要了，此时就应该考虑自动删除这条通知。 同样的，用户查看过的聊天消息或邮件，也应该让用户不必手动操作就移除这些通知。 6.为通知提供预览 提供一段简短的文本作为通知的预览可以让用户大致了解通知的内容，从而帮助用户决定是否立刻查看该通知。 7.让用户决定是否显示通知 用户可能对频繁出现的通知感到厌烦，所以应该让用户决定是否显示通知。因此，在应用程序的设置中应该让用户可以取消通知。 8.使用不同的图标 为了让用户在通知栏看一眼就能知道是哪个应用程序发出的通知，应该采用有自己特色的图标。所以在设计应用程序的图标的时候，应该注意与其他Android应用的通知图标有比较明显的区别。 但需要注意的是不要用颜色来区分，因为通知图标通常都是黑白的。 三、通知的导航机制 1.单条通知与合并通知 如果用户点击了一条通知，此时应该将相关的应用程序打开到可以对通知中提到的内容进行操作的状态。例如用户收到一封新邮件的通知，用户点开该通知后应该去到这封邮件的内容页。因为同类通知会被合并，如果用户点击了一个合并的通知，应该去到列表页面（内容页的上一层级）。在下面的例子中，用户点开一条合并的新邮件通知后，进入了收件箱界面. 2.间接通知 如果应用程序需要同时展示多个事件的信息，可以使用一条通知将用户指引到一个中间界面。这个界面会展示这些事件，并为用户提供进入应用程序的入口。这种类型的通知被称为间接通知。 例如一个用户在Gmail中收到了Calendar发出的一条间接通知。点击这条通知后打开一个中间界面（calendar interstitial），这个界面下显示了几个事件的提醒，在这个界面点“返回”键会回到Gmail，但是如果用户点击了某个事件提醒，就会离开这个中间界面并打开Calendar应用程序以显示这个事件的详细内容。在这个事件的详细内容的界面下，点“向上”和“返回”都会去到Calendar应用的首页。在间接通知的中间界面点“返回”会回到触发该通知的界面，返回路径中不会被插入其他界面。一旦用户通过中间界面进入了应用程序，“向上”和“返回”的逻辑就与标准通知一样了：在应用程序之间进行导航，而不会返回到中间界面。 关于间接通知的详细内容请查看百度MUX翻译的《Android Design》的模式Patterns—-导航Navigation章节。 3. 弹出通知 弹出通知会绕过抽屉通知直接出现在用户面前。一般情况下很少使用，只在需要及时地反馈并且必须打断用户的场合下才会使用。例如Talk应用使用这种形式的通知来提醒用户有好友邀请他加入视频聊天，因为这个邀请会在几秒后自动失效。 对于导航行为，弹出通知严格遵循间接通知的中间界面的导航逻辑。点“返回”会关闭弹出通知。如果用户从这条弹出通知进入了发出通知的应用程序，“向上”和“返回”的逻辑会与标准通知的逻辑保持一致，在应用程序内进行导航。 关于间接通知的详细内容请查看百度MUX翻译的《Android Design》的模式Patterns—-导航Navigation章节。 四、通知的相关交互 1. 通知抽屉 默认情况下，待处理的通知是以图标形式显示在状态栏中，从屏幕上方向下滑即可打开通知抽屉。 最近的通知排在最前面，点击一条通知会将其应用程序打开到与这条通知相关的界面。 在一条通知上向左或向右横划即可移除该通知。 在Android 4.0的平板电脑中，通知栏则被集成到底部的系统栏里，在通知区域的任意位置点击即可打开通知抽屉。 2. 进行中的通知 有一些通知是让用户了解后台正在运行的进程。例如正在播放的音乐播放器、正在后台运行的省电程序、正在保护系统的安全软件等。另外也可以对下载上传、视频编码这种持续时间较长的任务提供反馈。这种进行中的通知是不可以被移除的。 3.Dialog和Toast用作反馈 如果某个应用程序没有在当前屏幕运行，它就不应该弹出对话框（Dialog）和提示条（Toast）。对话框和提示条应该是用户在当前应用程序下执行操作时，用来提供即时的操作反馈的。比如对话框可以让用户知道某个操作的危险后果，而提示条可以让用户知道某个操作已成功执行。 五、总结 在Android平台设计应用程序的通知消息时应该明确在哪些场景下使用通知；不同的场景显示什么类型的通知。在设计的时候还要注意通知的私有化、导航逻辑、清理机制、同类通知的合并、图标的设计等。为避免对用户造成骚扰，还应该在应用程序的设置中增加对是否显示通知消息的设置。 从较早版本的Android系统开始，就具备了比较成熟的通知系统，新版iOS系统也参考了类似的设计。所以充分利用Android的通知系统，一定可以让用户对你的应用程序了如指掌。 另附上MUX翻译的最新版《Android Design》，欢迎大家下载阅读。 译文：http://mux.baidu.com/img/97/AndroidDesign-BaiduMUX.pdf 原文：http://developer.android.com/design/ 【本文首发于： 百度无线用户体验官方博客】 http://mux.baidu.com/?p=3183 【 关注百度技术沙龙】 本文转自百度技术51CTO博客，原文链接：http://blog.51cto.com/baidutech/908498，如需转载请自行联系原作者
2017-11-14

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

时间: 2026-09-24 大小: 189MB 下载: 9次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册