LGPL协议是否意味着可以自由开发商业软件

GPL协议原文 - http://www.gnu.org/copyleft/gpl.html
GPL协议中文译文 - http://bergwolf.googlepages.com/gplv3_zh
LGPL协议原文 – http://www.gnu.org/copyleft/lesser.html
LGPL协议中文译文 - http://www.thebigfly.com/gnu/lgpl/lgpl-v3.php
58种不同的开源协议 - http://www.fsf.org/licensing/licenses/
什么是动态链接 - http://zh.wikipedia.org/wiki/%E5%8A%A8%E6%80%81%E9%93%BE%E6%8E%A5%E5%BA%93
官方声明 - http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt
官方Q&A - http://www.qtsoftware.com/about/licensing/frequently-asked-questions

QT 协议可参考Qt的LGPL协议是否意味着可以自由用QT开发商业软件

今天,我们共同祭奠同胞!

今天,南京大屠杀死难者国家公祭日
10:00,

南京全城正鸣笛致哀!
昭昭前事,惕惕后人!
岁末寒冬,祭奠同胞!

中国青年报·中国青年网 记者 李超/摄

我们以国之名悼念逝者
不为延续仇恨,只为警醒:吾辈自强!

1937年12月13日,侵华日军在南京城开始了
40多天惨绝人寰的大屠杀,30万同胞惨遭杀戮。
南京大屠杀真实影像(来源:央视新闻)

在那场持续6周的人间浩劫里,每隔12秒就有一人遇难。

劫后余生的幸存者留下了,难以抚平的伤痛和苦难记忆。

今年,又有4位南京大屠杀幸存者与世长辞。
截至目前,登记在册的在世幸存者仅剩73位。

△2020南京大屠杀幸存者百人群像实录(黑白照为已故幸存者)

“昭昭前事,惕惕后人。”
83年后,人们生活在和平年代,这段中华民族的屈辱历史,
我们却不敢忘、不能忘。
铭记,不仅牢记和平来之不易,还需汲取落后挨打的教训;
纪念,不为激起仇恨,只为立下誓言:吾辈当自强。

广告名词 CPA、CPS、CPM、CPT、CPC 、CVR、OCPC、OCPM是什么

1.CPA(Cost Per Action) 每行动成本,这个行为可以是注册、咨询、放入购物车等等。CPA是一种按广告投放实际效果计价方式的广告,即按回应的有效问卷或注册来计费,而不限广告投放量。电子邮件营销(EDM)现在有很多都是CPA的方式在进行。

2.CPS(Cost Per Sales):以实际销售产品数量来换算广告刊登金额。CPS是一种以实际销售产品数量来计算广告费用的广告,这种广告更多的适合购物类、导购类、网址导航类的网站,需要精准的流量才能带来转化。

3.CPC(Cost Per Click) 每点击成本。CPC是一种点击付费广告,根据广告被点击的次数收费。如关键词广告一般采用这种定价模式,比较典型的有Google广告联盟的AdSense for Content和百度联盟的百度竞价广告。

4.CPT(Cost Per Time) 每时间段成本。CPT是一种以时间来计费的广告,国内很多的网站都是按照“一个星期多少钱”这种固定收费模式来收费。这种广告形式很粗糙,无法保障客户的利益。但是CPT的确是一种很省心的广告,能给你的网站、博客带来稳定的收入。阿里妈妈的按周计费广告和门户网站的包月广告都属于这种CPT广告。

5.CPM(Cost Per Mille) 每千人成本。CPM是一种展示付费广告,只要展示了广告主的广告内容,广告主就为此付费。这种广告的效果不是很好,但是却能给有一定流量的网站、博客带来稳定的收入。有人认为,CPM的计算不能按照被看到作为衡量标准,如果一个Banner在页面底部,需要滚屏才能看到,只要这个Banner在该页面中被展示了1000次,即使1000次中没人滚屏到页面底部看这个广告,也应该计算为一个CPM。

fb42c445749f46eab0a100b06b816873_th

(1)CPT和CPM只在第一步收取广告费用,即媒体只需要将广告对广告受众进行了展示,即可向广告商收取广告费用。

(2)CPC只收取第二步费用,消费者看到广告后并进行了点击行为以后,媒体向广告商收取广告费用。

(3)CPA和CPS处于第三步,即消费者有看到广告后并点击了广告,进一步了解活动情况后在广告主的网站完成某些特定行为(例如付款消费,填表注册等)。

f403828429794c43a893db96b1e19925_th

相比而言,CPM和CPT对网站有利,而CPC、CPA、CPS则对广告主有利。目前比较流行的计价方式是CPM和CPC,最为流行的则为CPM。

从广告价格上来分,CPT和CPM的表面价格相对较为低廉,而CPC居中,CPA和CPS的价格则似乎要高很多。需要指出的是,这里说的价格只是表面价格,不等于性价比。一般情况下,CPA和CPS的性价比相对固定,而CPC和CPT、CPM则根据网站对用户的粘性不同而有区别。

从作弊难易程序来看,CPT和CPM的选择,通常取决于网站的质素,而网站的质素,衡量标准似乎只有网站统计和第三方统计,但这些都是很容易作弊的,国内满天飞的刷流量软件和网站,就是CPT和CPM作弊的最佳工具,尽管站长们都知道,但是广告商却只能在一段时间内广告效果不如意时才能有所察觉。

对于CPC广告,尽管存在一定的技术防范措施,作弊也相对容易,国内甚至有网站出售点击广告包月,这也是导致国内CPC广告联盟式微的原因吧。而CPA也相对较为容易,只要有足够多的时间和精力去注册和验证虚假用户。唯CPS广告几乎不在乎作弊,也是几个广告类型中唯一很难作弊的广告模式。

7dd98d1001e93901abaa5c1e75ec54e736d19662

1.CVR (Click Value Rate): 转化率,衡量CPA广告效果的指标

2.CTR (Click Through Rate): 点击率

3.ROI: Return On Investment,投资回报率,或者说 投资利润率。指通过投资而应返回的价值,它涵盖了企业的获利目标。利润和投入的经营所必备的财产相关,因为管理人员必须通过投资和现有财产获得利润。又称会计收益率、投资利润率。

悼念金庸 从“金句”看金庸生死观

1。慧极必伤,情深不寿,强极则辱,谦谦君子,温润如玉。——《书剑恩仇录》

2。人生在世,充分圆满的自由根本是不能的。——《笑傲江湖》

3。幽冥之事,究属渺茫。死虽未必可怕,但凡人莫不有死,到头这一身,难逃那一日。能够多活一天,便多一天罢!——《倚天屠龙记》

4。生死修短,岂能强求?予恶乎知悦生之非惑邪?予恶乎知恶死之非弱丧而不知归者邪?予恶乎知夫死者不悔其始之蕲生乎?——《倚天屠龙记》

5。兄弟,每个人都要死,我说那谁也躲不了的瘟疫,便是大限到来,人人难逃。——《射雕英雄传》

6。人生在世,去若朝霞。魂归来兮,哀我何悲。——《天龙八部》

信息通信发展司召开IPv6规模部署及专项督查工作 全国电视电话会议

2018年8月3日,工业和信息化部信息通信发展司召开IPv6规模部署及专项督查工作全国电视电话会议。部信息通信发展司司长闻库,部网络安全管理局副局长张新,部信息通信管理局互联网处处长裴玮,中国信息通信研究副院长王志勤出席会议并讲话,中央网信办信息化发展局处长方新平受邀出席会议。会议由部信息通信发展司巡视员陈家春主持。

会议指出,发展基于IPv6的下一代互联网,不仅是互联网演进升级的必然趋势,更是助力互联网与实体经济深度融合、支撑经济高质量发展的迫切需要,对于提升国家网络空间综合竞争力、加快网络强国建设具有重要意义。

会议要求,以“通盘布局、移动先行、流量突破”为主要工作思路,推进各项改造工作。其中,基础电信企业30个自营APP是LTE IPv6“高速公路上的测试车”,各企业要力争提前完成改造,真正实现端到端贯通,为提升用户规模与网络流量打下良好基础;内容分发网络(CDN)改造要适度超前,为互联网应用改造提供足够的内容加速资源;云服务企业,特别是大型云服务企业不仅要及时完成云产品IPv6改造目标,还要充分发挥平台优势,面向中小型企业提供IPv6技术咨询和网站改造等服务;终端制造企业要进一步加快移动和固定终端的软硬件升级,消除IPv6盲点。各企业间加强沟通协调对接,合力破解具体困难问题;各通信管理局、各企业、中国信息通信研究院要按照相关要求,扎实做好专项督查各项工作,确保相关工作取得实效。

工业和信息化部机关司局、北京市通信管理局、基础电信企业、北京邮电大学、部属单位及部分互联网企业有关部门负责人在现场参会。各省(区、市)通信管理局、基础电信企业及互联网企业负责人在视频分会场参会。

来源:http://www.miit.gov.cn/n1146290/n1146402/n1146440/c6291799/content.html

[转]国内知名站长网站 ChinaZ 论坛宣布关闭

先说明一下,关闭的是站长论坛BBS这个网站 http://bbs.chinaz.com/,不是站长之家。

Chinaz站长论坛成立于2002年,是国内知名站长社区,而昨日一条《站长论坛关闭公告》刷爆了站长的朋友圈,满屏的情怀,叹息一个时代的结束。十六年间,互联网发生了翻天覆地的变化,站长们从满怀梦想的少年变成了油腻大叔。

2005年,Chinaz创始人姚剑军与其他三位创始人成立厦门享联科技有限公司,以公司化的方式运营站长站。公司成立后的第一个动作便是推出第三方数据统计服务商——CNZZ,其一个月后,成为中国站长必用的网站统计服务之一。CNZZ在2008年获得IDG投资,2011年被阿里巴巴集团收购。2017年1月享联科技宣布通过新三板上市!股票代码:870486。

其中,2010年ChinaZ迎来了自己的吉祥物,取名“WoWo”。关于为什么选择蜗牛作为吉祥物,站长之家创始人阿飞哥(姚剑军)称:“蜗牛慢吞吞的,但是却很努力的在爬,而且背上背着一个重重的壳,这和吉祥物wowo吉祥物wowo站长好相像。我认为蜗牛其实是一种精神,纵使自己很慢,但也会不断的去努力,永不放弃。”

2017年公司上市后,阿飞也迎来的人生的高峰,而Chinaz站长论坛关闭的理由是“因业务发展需要”,不禁让人想到论坛已经成了重重的壳,但愿站长们能做到永不放弃!

来源:站长圈

源地址:https://www.oschina.net/news/98001/say-goodbye-to-bbs-chinaz

英媒晒国外名人收入 比尔·盖茨每天入账6000多万元

国际在线专稿:在各类媒体上看到哪个福布斯富豪又赚了多少钱时,可能并不会给人造成太大的冲击。不就是数字嘛,多加几个零就是了,数数谁不会啊?

但是,如果把这个数字换算成日薪甚至是时薪和自己对比的话,可以说就很扎心了…

英国《每日邮报》近日统计了多位富豪的日均收入以及花钱方式,一起来看看吧。

(并没有换算成小时单位,所以还请放心阅读)

比尔·盖茨

日均收入:710万英镑(约6215万人民币)

据彭博社报道,盖茨去年进账共26亿英镑(约227.7亿人民币),平均到每天就是710万英镑。

除此以外,作为盖茨基金会主席,盖茨本人能够调动的金钱量更大于他自身的收入……

花销:盖茨喜欢去冰岛度假,还常和家人一起驾游艇出游。

盖茨曾说过:“到了一定程度以后,金钱对于我个人就没什么用处了。现在我用钱的主要目的就是贡献给基金会,并将资源送到世界最穷苦的人们手中。”

J·K·罗琳

日均收入:19.8万英镑(约173.4万人民币)

作为《哈利波特》系列的作者,罗琳从其版税、电影、主题公园、各种纪念品以及舞台剧表演中获得巨大的收入,而她现在还在继续写作。

花销:罗琳和丈夫以及三个孩子一起住在爱丁堡,据说曾以百万英镑买下邻居的房子……

阿黛尔·阿德金斯

日均收入:14.4万英镑(约126万人民币)

阿黛尔的第三个专辑《25》全球共售出2000万份,仅在英国就帮她捞了1650万英镑(约1.44亿人民币)。

花销:在美国和英国多地拥有房产。

大卫·贝克汉姆

日均收入:13.6万英镑(约119.1万人民币)

小贝的肖像权公司去年给他开出了1270万英镑(约1.1亿人民币)的薪水,使用其形象打广告的商家遍布各种行业。

花销:小贝在科茨沃尔德的房子花了近六百万英镑(约5255万人民币),他的宝贝女儿哈珀(Harper)上芭蕾课也是一笔不小的花销。

英国女王

日均收入:11.7万英镑(约102.5万人民币)

英国政府会将皇室不动产利润中的15%给予女王,去年她因此获得的收入共有4280万英镑(约3.7亿人民币),近期预计还将增长。

花销:女王的各种度假在她总花销中其实所占比例不大,维护各个皇家宫殿的费用才是大头。

詹妮弗·劳伦斯

日均收入:4.9万英镑(约42.9万人民币)

尽管这位奥斯卡影后时常抱怨自己的收入不如一些男演员高,但她去年也有1820万英镑的收入(约1.59亿人民币)。

花销:在比弗利山庄的住宅价值540万英镑(约4728万人民币)。

 

解读Linux启动过程

转自:https://my.oschina.net/macwe/blog/1531024

解读Linux启动过程

 

1. 概述

本文解读一下从CPU加电自检到启动init进程的过程, 先通过下面这张图大致看一下Linux启动的整个过程。

本文的分析环境是GRUB 0.97 + Linux 2.6.18。

2. BIOS

CPU加电后首先工作在实模式并初始化CS:IP=FFFF:FFF0,BIOS的入口代码必须从该地址开始。BIOS完成相应的硬件检查并提供一系列中断服务例程,这些中断服务提供给系统软件访问硬件资源(比如磁盘、显示器等),最后选择一个启动盘加载第一个扇区(即:MBR,共512字节)数据到内存0x7C00处,并从这里开始执行指令(CS:IP=0000:7C00),对于笔者的电脑来说这就是GRUB的Stage1部分。

3. GRUB

GRUB的作用是bootloader,用来引导各种OS的。

3.1. Stage1

Stage1就是MBR,由BIOS把它从磁盘的0扇区加载到0x7c00处,大小固定位512字节,此时的CPU上下文如下:

eax=0011aa55 ebx=00000080 ecx=00000000 edx=00000080 esi=0000f4a0 edi=0000fff0
eip=00007c00 esp=00007800 ebp=00000000 iopl=0 nv up ei pl zr na po nc
cs=0000 ds=0000 es=0000 fs=0000 gs=0000 ss=0000 eflags=00000246
// 注: dl=启动磁盘号, 00H~7FH是软盘, 80H~FFH是硬盘。

因为只能是512字节,大小受限,它就干一件事,把Stage2的第一个512字节读取到0x8000,然后jmp到0x8000继续执行。

3.1.1. 读磁盘

磁盘扇区寻址有两种方式:

  • CHS方式:传统的方式,使用三元组(10位Cylinder, 8位Head, 6位Sector)来寻找扇区,最大只能找到(2^10) * (2^8) * (2^6) * 512 = 8GB的硬盘容量,现在的硬盘明显不够用了。
  • LBA方式:现在的方式,使用48位线性地址来寻找扇区,最大支持(2^48) * 512 = 128PB的硬盘空间。虽然机械上还是CHS的结构,不过磁盘的固件会自动完成LBA到CHS的转换。

因为CHS明显不适合现在的硬盘,所以LBA模式寻址是现在的PC的标配了吧!万一磁盘不支持LBA或者是软盘,需要我们手工转换成CHS模式。转换公式如下(就是三维空间定位一个点的问题):

磁道号C = LBA / 每磁道的扇区数SPT / 盘面总HPC
磁头号H = (LBA / 每磁道的扇区数SPT) mod HPC
扇区号S = (LBA mod SPT) + 1

判断是否支持LBA模式

/* check if LBA is supported */
movb	$0x41, %ah
movw	$0x55aa, %bx
int	$0x13

如果返回成功(CF=1)并且BX值是0xAA55表示支持LBA寻址(用Extensions方法)。

注意:3.5英寸软盘需要使用CHS方式寻址,它的CHS参数是80个柱面、2个磁头、每个磁道18个扇区,每扇区512字节,共1.44MB容量。

LBA模式读的功能号是AH=42h,DL参数是磁盘号,DS:SI参数是Disk Address Packet(DAP)结构体的内存地址,定义如下:

struct DAP {
    uint8_t sz; // 结构体大小
    uint8_t unused;
    uint16_t sector_cnt; // 需要都的扇区总数
    struct dst_addr { // 内存地址,读到这里
        uint16_t offset;
        uint16_t segment;
    };
    uint64_t lba_addr;  // 磁盘的LBA地址
};

参考:

  • https://en.wikipedia.org/wiki/Logical_block_addressing#CHS_conversion
  • https://en.wikipedia.org/wiki/INT_13H

3.2. Stage2

Stage2就是GRUB剩下的全部的代码了,包括BIOS中断服务的封装给C代码使用、键盘驱动、文件系统驱动、串口、网络驱动等等,它提供了一个小型的命令行环境,可以解析用户输入命令并执行对OS的启动。

3.2.1. start.S

首先Stage2的头512字节(start.S)被加载到0x8000,并在这里开始执行,此时的CPU上下文如下:

eax=00000000 ebx=00007000 ecx=00646165 edx=00000080 esi=00007c05 edi=0000fff0
eip=00008000 esp=00001ffe ebp=00000000 iopl=0 nv up ei pl zr na po nc
cs=0000 ds=0000 es=0800 fs=0000 gs=0000 ss=0000 eflags=00000246

start.S的工作是把Stage2的后续部分全部加载到内存中(从0x8200开始),有103KB大小。

3.2.2. asm.S

asm.S是0x8200处的代码,先看一下CPU上下文环境:

eax=00000e00 ebx=00000001 ecx=00646165 edx=00000080 esi=00008116 edi=000081e8
eip=00008200 esp=00001ffe ebp=000062d8 iopl=0 nv up ei pl zr na po nc
cs=0000 ds=0000 es=1ae0 fs=0000 gs=0000 ss=0000 eflags=00000246
3.2.2.1. 最开始的代码应该设置好段寄存器和栈
cli
/* set up %ds, %ss, and %es */
/* cs=0000 ds=0000 es=0000 fs=0000 gs=0000 ss=0000 */
xorw	%ax, %ax
movw	%ax, %ds
movw	%ax, %ss
movw	%ax, %es

/* set up the real mode/BIOS stack */
movl	$STACKOFF, %ebp
movl	%ebp, %esp
sti

此时:

cs=0000 ds=0000 es=0000 ss=0000 esp=00001ff0 ebp=00001ff0。
3.2.2.2. 保护模式和实模式

因为GRUB没有实现自己的中断服务,所以访问硬件资源还是使用BIOS的中断服务例程(实模式)。GRUB的命令行环境是工作在保护模式下的,所以当GRUB需要访问BIOS中断的时候需要切换回实模式,于是在GRUB执行过程中会有频繁的实模式和保护模式的互相切换操作,当切换回实模式后别忘了保存保护模式下的栈指针

(1) 实模式进入保护模式

/* transition to protected mode */
DATA32	call EXT_C(real_to_prot)

/* The ".code32" directive takes GAS out of 16-bit mode. */
.code32

下图是实模式到保护模式的切换步骤:

GRUB没有设置分页机制和新的中断,所以GRUB的保护模式访问的是物理内存且是不能使用INT指令,不过对于bootloader来说够用了。因为需要切换到保护模式栈,原来的返回地址要放到新的栈上,以保证能够正常ret:

ENTRY(real_to_prot)
	...
	/* put the return address in a known safe location */
	movl	(%esp), %eax
	movl	%eax, STACKOFF  ; 把返回地址保存起来备用

	/* get protected mode stack */
	movl	protstack, %eax
	movl	%eax, %esp
	movl	%eax, %ebp      ; 设置保护模式的栈

	/* get return address onto the right stack */
	movl	STACKOFF, %eax
	movl	%eax, (%esp)    ; 把返回地址重新放到栈上
	
	/* zero %eax */
	xorl	%eax, %eax

	/* return on the old (or initialized) stack! */
	ret                     ; 正常返回

(2) 保护模式切换回实模式

	/* enter real mode */
	call	EXT_C(prot_to_real)
	
	.code16

下图说明了保护模式切换回实模式的步骤:

保护模式的栈需要保存起来以便恢复现场,让C代码正确运行,实模式的栈每次都重置为STACKOFF即可,和(1)一样,也要设置好返回地址:

ENTRY(prot_to_real)
	...
	/* save the protected mode stack */
	movl	%esp, %eax
	movl	%eax, protstack  ; 把栈保存起来

	/* get the return address */
	movl	(%esp), %eax
	movl	%eax, STACKOFF   ; 返回地址放到实模式栈里

	/* set up new stack */
	movl	$STACKOFF, %eax  ; 设置实模式的栈
	movl	%eax, %esp
	movl	%eax, %ebp
	... 
3.2.2.3. 创建C运行时环境

C的运行环境主要包括栈、bss数据区、代码区。随着切换到保护模式,栈已经设置好了;随着Stage2从磁盘加载到内存,代码区和bss区都已经在内存了,最后还需要把bss区给初始化一下(清0),接下来即可愉快的执行C代码了。

3.2.2.4. 执行cmain()

先执行一个init_bios_info()获取BIOS的信息,比如被BIOS使用的内存空间(影响我们Linux映像加载的位置)、磁盘信息、ROM信息、APM信息,最后调用cmain()。 cmain()函数在stage2.c文件中,其中最主要的函数run_menu()是启动一个死循环来提供命令行解析执行环境。

3.2.2.5. load_image()

如果grub.cfg或者用户执行kenrel命令,会调用load_image()函数来将内核加载到内存中。至于如何加载linux镜像在Documentation的boot.txt和zero-page.txt有详细说明。

load_image()是一个非常长的函数,它要处理支持的各种内核镜像格式。Linux镜像vmlinuz文件头是struct linux_kernel_header结构体,该结构体里头说明了这个镜像使用的boot协议版本、实模式大小、加载标记位和需要GRUB填写的一些参数(比如:内核启动参数地址)。

  • 实模式部分:始终被加载到0x90000位置,并从0x90200开始执行(linux 0.11就这样做了)。
  • 保护模式部分:我们现在使用的内核比较大(大于512KB),叫做bzImage,加载到0x100000(高位地址,1MB)开始的位置,可以任意大小了。否则小内核zImage放在0x10000到mbi.mem_lower * 1024(一般是0x90000)区域。
3.2.2.6. linux_boot()

我们正常的启动过程调用的是big_linux_boot()函数,把实模式部分copy到0x90000后,设置其他段寄存器值位0x9000, 设置CS:IP=9020:0000开始执行(使用far jmp)。

至此GRUB的工作完成,接下来执行权交给Linux了。

4. setup.S

该文件在arch/i386/boot/setup.S,主要作用是收集硬件信息并进入保护模式head.S。初始的CPU上下文如下:

eax=00000000 ebx=00009000 ecx=00000000 edx=00000003 esi=002d8b54 edi=0009a000
eip=00000000 esp=00009000 ebp=00001ff0 iopl=0 nv up di pl zr na po nc
cs=9020 ds=9000 es=9000 fs=9000 gs=9000 ss=9000  eflags=00000046

4.1. 自身检查

先检查自己setup.S是否合法,主要是检查末尾的两个magic是否一致

# Setup signature -- must be last
setup_sig1:	.word	SIG1
setup_sig2:	.word	SIG2

4.2. 收集硬件信息

主要是通过BIOS中断来收集硬件信息。收集的信息包括内存大小、键盘、鼠标、显卡、硬盘、APM等等。收集的硬件信息保存在0x9000处:

# 设置ds = 0x9000,用来保存硬件信息
movw	%cs, %ax			# aka SETUPSEG
subw	$DELTA_INITSEG, %ax 		# aka INITSEG
movw	%ax, %ds

这里看一下如何获取内存大小,这样OS才能进行内存管理。这里用三种方法获取内存信息:

  1. e820h:请求中断INT 15H,AX=E820H时返回可用的物理内存信息,e820由此得名,参考http://www.uruk.org/orig-grub/mem64mb.html。由于内存的使用是不连续的,通过连续调用INT 15H得到所有可用的内存区域,每次查询得到的结果ES:DI是个struct address_range_descriptor结构体,返回的结果都是64位的,完全能够满足目前PC的需求了。
     struct address_range_descriptor {
     	uint32_t base_addr_low;   // 起始物理地址
     	uint32_t base_addr_high;
     	uint32_t length_low;      // 长度
     	uint32_t length_high;
     	uint8_t type;             // 1=OS可用的, 2=保留的,OS不可用
     };
    
  2. e801h:通过请求中断INT15h,AX=e801H返回结果,最高只能得到4GB内存结果。
  3. 88h:古老的办法,通过请求中断INT15h,AH=88H返回结果。最高只能得到16MB或者64MB的内存,现在的电脑不适用了。

扩展阅读:http://wiki.osdev.org/Detecting_Memory_(x86)#E820h

4.3. 启用A20

让CPU访问1MB以上的扩展内存,否则访问的是X mod 1MB的地址。下面列举三种开启A20的方法:

  1. 使用I/0端口92H,AL的将1-bit置1
     inb	$0x92, %al			# Configuration Port A
     orb	$0x02, %al			# "fast A20" version
     andb	$0xFE, %al			# don't accidentally reset
     outb	%al, $0x92
    
  2. 使用BIOS中断INT 0x15, AX=0x2401
     movw	$0x2401, %ax
     pushfl					# Be paranoid about flags
     int	$0x15
     popfl
    
  3. 使用键盘控制器
     movb	 $0xD1, %al			# command write
     outb	 %al, $0x64
     call	 empty_8042
    
     movb	 $0xDF, %al			# A20 on
     outb	 %al, $0x60
     call	 empty_8042
    

4.4. 进入保护模式

4.4.1. 临时的GDT和IDT

这里的IDT全部是0;Linux目前使用的GDT如下:

gdt:
	.fill GDT_ENTRY_BOOT_CS,8,0

	.word	0xFFFF				# 4Gb - (0x100000*0x1000 = 4Gb)
	.word	0				# base address = 0
	.word	0x9A00				# code read/exec
	.word	0x00CF				# granularity = 4096, 386
						#  (+5th nibble of limit)

	.word	0xFFFF				# 4Gb - (0x100000*0x1000 = 4Gb)
	.word	0				# base address = 0
	.word	0x9200				# data read/write
	.word	0x00CF				# granularity = 4096, 386
						#  (+5th nibble of limit)
gdt_end:

这里只定义了两个DPL为0的代码段和数据段,只给内核使用的。

4.4.1. 设置CR0.PE

这里使用lmsw指令,它和mov cr0, X是等价的

movw	$1, %ax				# protected mode (PE) bit
lmsw	%ax				# This is it!
jmp	flush_instr

4.5. 调转到head.S(CS:EIP=0x10:100000)

至此硬件信息就收集完成,这些收集到的硬件信息都保存在0x90000处,后续OS可以使用这些硬件信息来管理了。

5. head.S

该文件位于arch/i386/kernel/head.S,这个是内核保护模式的代码的起点,笔者电脑的位置在0x100000,此时CPU上下文是:

eax=00000001 ebx=00000000 ecx=0000ff03 edx=47530081 esi=00090000 edi=00090000
eip=00100000 esp=00008ffe ebp=00001ff0 iopl=0 nv up di pl nz na pe nc
cs=0010 ds=0018 es=0018 fs=0018 gs=0018 ss=0018               eflags=00000002

注:已经进入保护模式,CS的值是GDT表项的索引。

它的作用就是设置真正的分段机制和分页机制、启动多处理器、设置C运行环境,最后执行start_kernel()函数。

5.1. startup_32

5.1.1. 加载临时的分段机制

boot_gdt_table就是临时的GDT,其实和start.S的一样:

	lgdt boot_gdt_descr - __PAGE_OFFSET
	movl $(__BOOT_DS),%eax
	movl %eax,%ds
	movl %eax,%es
	movl %eax,%fs
	movl %eax,%gs

ENTRY(boot_gdt_table)
	.fill GDT_ENTRY_BOOT_CS,8,0
	.quad 0x00cf9a000000ffff	/* kernel 4GB code at 0x00000000 */
	.quad 0x00cf92000000ffff	/* kernel 4GB data at 0x00000000 */

5.1.2. 初始化内核bss区和内核启动参数

为了让C代码正常运行,bss区全部清0,启动参数需要移动到boot_params位置。

5.1.3. 启动临时分页机制

临时的页表,只要能够满足内核使用就行。页目录表是swapper_pg_dir,它是一个4096大小的内存区域,默认全是0。一般__PAGE_OFFSET=0xC0000000(3GB),这是要把物理地址0x00000000映射到0xc0000000的地址空间(内核地址空间)。下面是页目录表和页表的初始化代码:

page_pde_offset = (__PAGE_OFFSET >> 20); // 3072,页目录的偏移

	// 页目录表存放在pg0位置,arch/i386/kernel/vmlinux.lds中定义
	movl $(pg0 - __PAGE_OFFSET), %edi
	movl $(swapper_pg_dir - __PAGE_OFFSET), %edx  // edx是页目录表的地址
	movl $0x007, %eax			/* 0x007 = PRESENT+RW+USER */
10:
	// 创建一个页目录项
	leal 0x007(%edi),%ecx			/* Create PDE entry */
	movl %ecx,(%edx)			/* Store identity PDE entry */
	movl %ecx,page_pde_offset(%edx)		/* Store kernel PDE entry */
	addl $4,%edx   // 指向swapper_pg_dir的下一个项
	movl $1024, %ecx   // 每个页表1024个项目
11:
	stosl  // eax -> [edi]; edi = edi + 4
	addl $0x1000,%eax // 每次循环,下一个页目录项
	loop 11b
	/* End condition: we must map up to and including INIT_MAP_BEYOND_END */
	/* bytes beyond the end of our own page tables; the +0x007 is the attribute bits */
	leal (INIT_MAP_BEYOND_END+0x007)(%edi),%ebp  // 页表覆盖到这里就终止
	cmpl %ebp,%eax
	jb 10b
	movl %edi,(init_pg_tables_end - __PAGE_OFFSET)

下面是对上面代码的翻译(这样更有利于理解):

extern uint32_t *pg0;  // 初始值全0
extern uint32_t *swapper_pg_dir;  // 初始值全0

void init_page_tables()
{
	uint32_t PAGE_FLAGS = 0x007; // PRESENT+RW+USER
	uint32_t page_pde_offset = (_PAGE_OFFSET >> 20); // 3072
	uint32_t addr = 0 | PAGE_FLAGS;  // 内存地址+页表属性
	uint32_t *pg_dir_ptr = swapper_pg_dir; // 页目录表项指针
	uint32_t *pg0_ptr = pg0;  // 页表项指针
	
	for (;;) {
		// 设置页目录项,同时映射两个地址,让物理地址和虚拟地址都能访问,
		*pg_dir_ptr = pg0 | PAGE_FLAGS;     // 0, 1
		*(uint32_t *)((char *)pg_dir_ptr + page_pde_offset) = pg0 | PAGE_FLAGS;  // 768, 769
		pg_dir_ptr++;
		
		// 设置页表项目
		for (int i = 0; i < 1024; i++) {
			*pg0++ = addr;
			addr += 0x1000;
		}
		// 退出条件,实际上只映射了两个页目录就退出了(0,1,768, 769)
		if (pg0[INIT_MAP_BEYOND_END] | PAGE_FLAGS) >= addr) {
			init_pg_tables_end = pg0_ptr;
			return;
		}
	}	
};

5.1.4. 设置栈

/* Set up the stack pointer */
	lss stack_start,%esp

ENTRY(stack_start)
	.long init_thread_union+THREAD_SIZE
	.long __BOOT_DS

/* arch/i386/kernel/init_task.c
* Initial thread structure.
*
* We need to make sure that this is THREAD_SIZE aligned due to the
* way process stacks are handled. This is done by having a special
* "init_task" linker map entry..
*/
union thread_union init_thread_union 
	__attribute__((__section__(".data.init_task"))) =
		{ INIT_THREAD_INFO(init_task) };

内核最初使用的栈是init_task进程的,也就是0号进程的栈,这个进程是系统唯一一个静态定义而不是通过fork()产生的进程。

5.1.5. 设置真正的IDT和GDT

	lgdt cpu_gdt_descr   // 真正的GDT
	lidt idt_descr    //真正的IDT
	ljmp $(__KERNEL_CS),$1f   // 重置CS
1:	movl $(__KERNEL_DS),%eax	# reload all the segment registers
	movl %eax,%ss			# after changing gdt.  // 重置SS

	movl $(__USER_DS),%eax		# DS/ES contains default USER segment
	movl %eax,%ds
	movl %eax,%es

	xorl %eax,%eax			# Clear FS/GS and LDT
	movl %eax,%fs
	movl %eax,%gs
	lldt %ax
	cld			# gcc2 wants the direction flag cleared at all times
	// push一个假的返回地址以满足 start_kernel()函数return的要求
	pushl %eax		# fake return address  

对于IDT先全部初始化成ignore_int例程:

setup_idt:
	lea ignore_int,%edx
	movl $(__KERNEL_CS << 16),%eax
	movw %dx,%ax		/* selector = 0x0010 = cs */
	movw $0x8E00,%dx	/* interrupt gate - dpl=0, present */

	lea idt_table,%edi
	mov $256,%ecx
rp_sidt:
	movl %eax,(%edi)
	movl %edx,4(%edi)
	addl $8,%edi
	dec %ecx
	jne rp_sidt
	ret

ignore_int例程就干一件事,打印一个错误信息"Unknown interrupt or fault at EIP %p %p %p\n"

对于GDT我们最关心的__KERNEL_CS、__KERNEL_DS、__USER_CS、__USER_DS这4个段描述符:

.quad 0x00cf9a000000ffff	/* 0x60 kernel 4GB code at 0x00000000 */
.quad 0x00cf92000000ffff	/* 0x68 kernel 4GB data at 0x00000000 */
.quad 0x00cffa000000ffff	/* 0x73 user 4GB code at 0x00000000 */
.quad 0x00cff2000000ffff	/* 0x7b user 4GB data at 0x00000000 */

至此分段机制、分页机制、栈都设置好了,接下去可以开心的jmp start_kernel了。

6. start_kernel

该函数在linux/init/main.c文件里。我们可以认为start_kernel是0号进程init_task的入口函数,0号进程代表整个linux内核且每个CPU有一个。 这个函数开始做一系列的内核功能初始化,我们重点看rest_init()函数。

6.1.rest_init

这是start_kernel的最后一行,它启动一个内核线程运行init函数后就什么事情也不做了(死循环,始终交出CPU使用权)。

static void noinline rest_init(void)
{
	kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND); // 启动init
	……
	/* Call into cpu_idle with preempt disabled */
	cpu_idle();  // 0号进程什么事也不做
}

6.2. init()

该函数的末尾fork了”/bin/init”进程。这样1号进程init就启动了,接下去就交给init进程去做应用层该做的事情了!

// 以下进程启动后父进程都是0号进程
if (ramdisk_execute_command) {
	run_init_process(ramdisk_execute_command);
	printk(KERN_WARNING "Failed to execute %s\n",
			ramdisk_execute_command);
}

/*
 * We try each of these until one succeeds.
 *
 * The Bourne shell can be used instead of init if we are 
 * trying to recover a really broken machine.
 */
if (execute_command) {
	run_init_process(execute_command);
	printk(KERN_WARNING "Failed to execute %s.  Attempting "
				"defaults...\n", execute_command);
}
run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");

附录1. 启动多核CPU

以上解读的内容只在0号CPU上执行,如果是多CPU的环境,还要初始化其他的CPU。多CPU启动的起点是start_kernel()->rest_init()>init()->smp_init()。而smp_init()函数给每个CPU上调用cpu_up()do_boot_cpu()函数,每个CPU都要再走一遍head.S的流程,然后启动自己的idle进程(内核态0号进程)。

附录2. x64的不同

i386和x64的启动代码主要区别在head.S中。

  • 页表格式不同,i386使用两级页表,x64使用4级页表。
  • 多了兼容32位的代码段和数据段__USER32_CS、__USER32_DS和__KERNEL32_CS
  • x64段寄存器用法和i386的不同:x64下面CS、DS、ES、SS不用了,始终为0。而FS、GS寄存器的用法倒像是实模式下的,主要考虑是保留两个作为基地址好让线性地址计算方便。FS:XX = MSR_FS_BASE + XXGS:XX = MSR_GS_BASE + XX, 不是段描述符索引了(像实模式的分段)。

J2EE框架 Spring

J2EE框架 Spring 推荐

J2EE框架 面向方面AOP/IoC Web框架
Apache
Java
跨平台

Spring Framework 是一个开源的Java/Java EE全功能栈(full-stack)的应用程序框架,以Apache许可证形式发布,也有.NET平台上的移植版本。该框架基于 Expert One-on-One Java EE Design and Development(ISBN 0-7645-4385-7)一书中的代码,最初由 Rod Johnson 和 Juergen Hoeller等开发。Spring Framework 提供了一个简易的开发方式,这种开发方式,将避免那些可能致使底层代码变得繁杂混乱的大量的属性文件和帮助类。

Spring 中包含的关键特性:

  • 强大的基于 JavaBeans 的采用控制翻转(Inversion of Control,IoC)原则的配置管理,使得应用程序的组建更加快捷简易。
  • 一个可用于从 applet 到 Java EE 等不同运行环境的核心 Bean 工厂。
  • 数据库事务的一般化抽象层,允许宣告式(Declarative)事务管理器,简化事务的划分使之与底层无关。
  • 内建的针对 JTA 和 单个 JDBC 数据源的一般化策略,使 Spring 的事务支持不要求 Java EE 环境,这与一般的 JTA 或者 EJB CMT 相反。
  • JDBC 抽象层提供了有针对性的异常等级(不再从SQL异常中提取原始代码), 简化了错误处理, 大大减少了程序员的编码量. 再次利用JDBC时,你无需再写出另一个 ‘终止’ (finally) 模块. 并且面向JDBC的异常与Spring 通用数据访问对象 (Data Access Object) 异常等级相一致.
  • 以资源容器,DAO 实现和事务策略等形式与 Hibernate,JDO 和 iBATIS SQL Maps 集成。利用众多的翻转控制方便特性来全面支持, 解决了许多典型的Hibernate集成问题. 所有这些全部遵从Spring通用事务处理和通用数据访问对象异常等级规范.
  • 灵活的基于核心 Spring 功能的 MVC 网页应用程序框架。开发者通过策略接口将拥有对该框架的高度控制,因而该框架将适应于多种呈现(View)技术,例如 JSP,FreeMarker,Velocity,Tiles,iText 以及 POI。值得注意的是,Spring 中间层可以轻易地结合于任何基于 MVC 框架的网页层,例如 Struts,WebWork,或 Tapestry。
  • 提供诸如事务管理等服务的面向方面编程框架。

在设计应用程序Model时,MVC 模式(例如Struts)通常难于给出一个简洁明了的框架结构。Spring却具有能够让这部分工作变得简单的能力。程序开发员们可以使用Spring的 JDBC 抽象层重新设计那些复杂的框架结构。

雨中的旋律

《雨中的旋律》(Rhythm of the Rain)是欧美经典歌曲,由瀑布合唱团演唱。

英文歌词

Rhythm of the Rain
Listen to the rhythm of the falling rain,
Telling me just what a fool I’ve been.
I wish that it would go and let me cry in vain,
And let me be alone again.
The only girl I care about has gone away.
Looking for a brand new start!
But little does she know that when she left that day.
Along with her she took my heart.
Rain, please tell me now. Does that seem fair for her
To steal my heart away when she don’t care
I can’t love another, when my heart’s somewhere far away.
The only girl I care about has gone away.
Looking for a brand new start!
But little does she know that when she left that day.
Along with her she took my heart.
Rain, won’t you tell her that I love her so
Please ask the sun to set her heart aglow
Rain in her heart and let the love we knew start to grow.
Listen to the rhythm of the falling rain,
Telling me just what a fool I’ve been.
I wish that it would go and let me cry in vain,
And let me be alone again.
Oh, listen to the falling rain–pitter-patter…

歌词大意

听那淅淅沥沥的雨声,它好像在说,我是个傻瓜。 我真希望雨停下来。 让我无望地哭泣, 让我再次孤身单影。
我唯一在乎的姑娘已经离去, 去寻找她的新生活。 然而,她不知道, 当她离去的那天, 也将我的心带走。
雨呀,请告诉我,那样公平吗?她偷走了我的心, 居然毫不在乎。 我无法再爱别人, 我的心已远远漂向异地。
雨呀,你就不能告诉她 我多么地爱她, 请让太阳燃起她心中的爱苗, 让雨滋润她的心田。 让我们爱情之花重新盛开。
哦,听那雨声, 噼哩啪啦。
歌词、句型分析
1、Listen to the rhythm Of the falling rain,telling me just what a fool I have been.
= As I listen to the rhythm of the falling rain, it seems that it is telling me that I’ve been a stupid guy.
听那淅淅沥沥的雨声,它好像在说,我是个傻瓜。
2、I wish that it would go and let me cry in vain….
=I wish that the rain would stop and let me cry in vain…
我真希望雨停下来,让我无望地哭泣,
in vain 徒然,白费,无效,徒劳的
eg: All our efforts were in vain, which made us very angry.
我们所有的努力都白费了,真令人生气。
3、The only girl I care about has gone away, looking for a brand-new start!
=The only girl that I love has left me and is looking for a new life!
我唯一在乎的姑娘已经离去,去寻找她的新生活。
Care about 喜欢,在乎
eg: She doesn’t care about being ladylike
她不在乎淑女仪态
brand-new a. 全新的
eg: Peter is showing off his brand-new motorcycle to his friends
彼得正在对他的朋友们炫耀他的新摩托车。
4、But little does she know that when she left that day,along with her she took my heart.
=But she doesn’t know that when she left that day,she also took my heart with her.
然而,她不知道,当她离去的那天,也将我的心带走。
But little does she know…此为否定倒装句型。
eg: He was hardly able to tell right from wrong
=Hardly was he able to tell right from wrong

中文版

(红苹果演唱)
歌词:
大雨哗啦啦淋湿我的梦
你我曾经相遇在雨中
那青春年少无知可爱的笑容
像雨后美丽的彩虹
等大雨再次击醒你我的美梦
你却消失无影踪
等心中攒成点点滴滴的感动
有星光闪烁在夜空
也许你我生来太轻松
初恋故事短暂而冲动
我也幻想成为你的大英雄 谁能够
等大雨再次击醒你我的美梦
你却消失无影踪
等心中攒成点点滴滴的感动
有星光闪烁在夜空
等大雨再次击醒你我的美梦
你却消失无影踪
等心中攒成点点滴滴的感动
有星光闪烁在夜空
也许你我生来太轻松
初恋故事短暂而冲动
我也幻想成为你的大英雄 谁能够
噢 听那大雨还在下
哗啦啦啦哗啦啦啦噢
啦啦啦啦啦啦还在下
啦啦啦啦啦啦啦.
啦啦啦啦还在下.
啦啦啦啦啦啦啦
噢 听那大雨还在下
啦啦啦啦啦啦啦啦噢
啦啦啦啦啦啦还在下

卡巴斯基悲催:美国全力封杀全球第一杀软

虽然在AV-TEST最新杀软评测中,卡巴斯基得到了满分成为第一,但美国依然不允许它出现在政府采购名录中,而这个封杀的事态还在加剧。

据外媒CNET报道称,除了美国的政府机构外,FBI也在悄悄暗示那些私营机构停止使用卡巴斯基,情况十分严重。

报道中提到,能源行业以及使用工业控制系统等企业,都在被警告的名单中,而按照美国的意思,就是先让该国企业尽可能快的从其系统中移除卡巴斯基。

虽然卡巴严正否认自己进行涉嫌收集不法信息的“间谍”活动,甚至可以交出软件源代码,但目前的情况是,这丝毫没有打动当局控制者,而消息中还透露,俄罗斯也正努力移除美国科技公司如微软的操作系统。

对于微软来说,这件事他们暗地里非常开心,因为这样可以让更多的用户来换用Windows Defender,尤其是随着创意者更新全面升级的“新安全中心”。

来自:驱动之家

转自:https://www.oschina.net/news/87919/kaspersky-banned-by-american-government

据说只有程序员才能看懂的时钟 [转]

据说只有程序员才能看懂的时钟,你看明白了吗?

最近发现一个关于程序员的“数学钟”,也就是非常流行的下面这幅图:

以前,只知道其中十一个点钟的分析;对于3点钟,一直没有思路。于是发了一条朋友圈,求助大神解释其中的3点钟。在刘梓溪、贾顾森、黎鸣等大神的指导下,明白了其中是怎么回事。所以这里介绍下这十二个点,应该如何解释。个人观点,仅供参考。

12点

不用说了,1728的立方根。

1点

可能很多人不大知道,这是勒让德常数:
勒让德常数

其中的π(x)表示不大于x的素数的个数,可以用近似。

这个值经过勒让德、高斯等一批数学大佬的努力,最后被数学家Charles Jean证明为1。

2点

无穷递缩等比级数的求和,首项为1,公比为1/2,所以它的和为

3点

在刘梓溪、贾顾森、黎鸣等大神的帮助下,终于知道了。

广泛用于XML、HTML中。&#后面接十进制字符,&#x后面接十六进制字符。相当于转义序列吧。

其中十六进制33,等于十进制51,即’3’。

4点

同余问题(Modular Multiplicative Inverse)


5点

ϕ表示黄金分割比,

黄金分割比在斐波那契数列的通项公式中出现。

不过这个地方,我没搞懂,不知道这是不是这幅图作者的笔误?个人认为应该是 而不是

6点

不用说了,阶乘。

7点

表示6.999999999…其中9的头上一横,表示循环节是9。

那么,6.9999….为什么等于7呢?恩,还是无穷递缩等比级数的视角来考虑,就老少皆宜了。

6.9999…= 6 + 0.9 + 0.09 + 0.009 + 0.0009 + …

后面的那个,

0.9 + 0.09 + 0.009 + 0.0009 + …

首项为0.9,公比为0.1,收敛于1。

因此6.9999… = 7

8点

代表1000(二进制),因为只有第一个是亮的,其他是暗的。(亮为1,暗为0,bitmap的感觉。可能是盲文),因此为8。

9点

四进制。21(四进制) = 2 * 4 + 1 = 9。

10点

组合数,5! /(2! * 3!) = 10

11点

十六进制,A是10,B是11,C是12。注意,注意,这里是0x0B,不是0x08。哈哈。

点评:知识点有点重复,比如进制就有好几个。

来源:程序师

原标题:程序员的时钟

原文:https://www.oschina.net/news/87686/programmer-clock

IceGrid应用配置[转]

1. 概述

1.1 配置目标

本文档是描述Ice中间件中的IceGrid服务的应用配置,通过使用IceGrid服务来实现:
1. 服务器端服务分布式部署。
2. 服务器端服务按需激活。
3. 服务器端服务多节点负载均衡。
4. 注册服务主/从热备(Master/Slaves)
5. 集成IceBox服务

1.2 实验环境

1. 硬件:hp服务器,3台
2. 操作环境:Red Hat 5
3. 服务器程序:ServerApp.jar
4. 说明:实际应用中,服务器节点可任意扩充、操作系统可被更换、服务器程序可用实际项目的服务程序替换,本文档所描述的配置方式具有通用性,适用但不局限于当前实验环境。

1.3 局限

本文档不详细描述IceGrid服务的运行机制和实现原理,不详细介绍服务器端和客户端程序的实现,主要描述IceGrid服务应用的配置步骤、主要配置项及验证配置结果等。

2. 配置过程

2.1 服务器端配置

配置步骤:
1. 创建主注册服务(Master)的配置文件config_master.grid,文件名称可以任意
2. 创建从注册服务(Slave)的配置文件 config_slave.grid, 文件名称可以任意
3. 创建各节点服务的配置文件config.node,文件名称可以任意
4. 创建分布式应用配置文件app.xml,文件名称可以任意,但格式最好定义成xml
5. 运行Ice提供的工具,启动我们的分布式应用,主要有如下两个工具:icegridnode和icegridadmin。详细启动过程如下:
1) icegridnode–Ice.Config=config_master.grid 启动主注册服务
2) icegridnode–Ice.Config=config_slave.grid 启动从注册服务
3) icegridadmin–Ice.Config= config_master.grid -e “application add app.xml” 部署分布式服务
icegridadmin –Ice.Config= config_master.grid-e “application update app.xml” 重新部署分布式服务
4) icegridnode–Ice.Config=config.node 将各节点注册到注册服务的注册表中
配置文件清单:
假设有n个节点(n > 0), 其中从注册服务有x个,(x > 0)
config_master.grid ———- 主注册服务配置文件 ——— 1份
config_slave.grid ———– 从注册服务配置文件 ——— x份
config.node —————– 节点配置文件 ————– n份
app.xml ———————- 部署配置文件 ————– 1份
通常情况下,由于注册服务占用资源很少,所以一般都会和一个节点集成在一起,并且可以和节点服务在一个进程中运行。因此,如果假设服务部署到n个服务器,通常情况下配置文件清单如下:
config_master.grid– 主注册服务配置文件 — 1份 — 主注册服务信息+节点信息
config_slave.grid— 从注册服务配置文件 — x份 — 从注册服务信息+节点信息
config.node——— 节点配置文件 —- n-1-x份 — 节点信息
app.xml————- 部署配置文件 ——– 1份 — 部署信息
其中app.xml要和config_master.grid放在一台服务器上,下面的各章节将详细介绍各配置文件。

2.1.1 主注册服务配置

config_master.grid的内容:

#
# The IceGrid InstanceName
#
IceGrid.InstanceName=YunIceGrid # 1
#
# The IceGridlocator proxy.
#
Ice.Default.Locator=YunIceGrid/Locator:default-h liyunde.com -p 4061:default -h ice.liyunde.com -p 4061 #2
#
# IceGridregistry configuration.
#
IceGrid.Registry.Client.Endpoints=default-p 4061 #3
IceGrid.Registry.Server.Endpoints=default #4
IceGrid.Registry.Internal.Endpoints=default #5
IceGrid.Registry.Data=master #6
IceGrid.Registry.PermissionsVerifier=YunIceGrid/NullPermissionsVerifier #7
IceGrid.Registry.AdminPermissionsVerifier=YunIceGrid/NullPermissionsVerifier#8
IceGrid.Registry.SSLPermissionsVerifier=YunIceGrid/NullSSLPermissionsVerifier#9
IceGrid.Registry.AdminSSLPermissionsVerifier=YunIceGrid/NullSSLPermissionsVerifier #10
#
# IceGrid SQLconfiguration if using SQL database.
#
#Ice.Plugin.DB=IceGridSqlDB:createSqlDB #11
#IceGrid.SQL.DatabaseType=QSQLITE #12
#IceGrid.SQL.DatabaseName=register/Registry.db #13
#
#
#Ice Error andStandard output Set
#
#Ice.StdErr=master/stderr.txt #14
#Ice.StdOut= master/stdout.txt #15
#
#Trace Registryproperties
#
Ice.ProgramName=Master #16
IceGrid.Registry.Trace.Node=3 #17
IceGrid.Registry.Trace.Replica=3 #18
#
# IceGrid nodeconfiguration.
#
IceGrid.Node.Name=node_1 #19
IceGrid.Node.Endpoints=default #20
IceGrid.Node.Data=node_1 #21
IceGrid.Node.CollocateRegistry=1 #22
#IceGrid.Node.Output=node_1 #23
#IceGrid.Node.RedirectErrToOut=1 #24
# Traceproperties.
#
IceGrid.Node.Trace.Activator=1 #25
#IceGrid.Node.Trace.Adapter=2 #26
#IceGrid.Node.Trace.Server=3 #27
#
# Dummy usernameand password for icegridadmin.
#
IceGridAdmin.Username=mygrid #28
IceGridAdmin.Password=mygrid #29

配置项说明:
#1 为这个应用实例指定一个唯一的标识
# 2 注册服务的端点信息(主注册服务和所有的从注册服务),节点注册时要用到
# 3 客户端访问注册服务器的端点信息
# 4 服务访问注册服务器的端点信息,通常是default
# 5 内部访问端点信息,通常是default,节点用这个端口和注册服务通信
# 6 注册服务的数据目录的路径
# 7 设定防火墙安全代理,从而控制客户端访问注册表时可用的权限
# 8 设定防火墙安全代理,从而控制注册表管理者可用的权限
# 9 设定SSL安全代理,从而设定客户端访问注册表时的SSL安全访问机制
# 10 设定SSL安全代理,从而设定注册表管理者的SSL安全访问机制
# 11 指定Ice对象序列化的机制,如果不设置,默认用Freeze机制
# 12 指定使用数据库的类型
#13 指定使用数据库的名称
#14 指定标准错误输出文件
#15 指定标准输出文件
#16 指定主注册服务的名称
#17 指定主注册服务跟踪节点信息的级别(0~3),默认为0
#18 指定主/从热备注册服务的跟踪级别(0~3),默认为0
# 19 定义节点的名称,必须唯一
# 20 节点被访问的端口信息,注册服务使用这个端点和节点通信,通常设为default
# 21 节点的数据目录的路径
# 22 定义节点是否和注册服务并置在一起,设为1时并置,设为0时不并置
# 23 节点标准输出信息重定向蹈的目录路径,会自动生成输出文件
# 24 节点上的服务程序的标准错误重定向到标准输出
# 25 激活器跟踪级别,通常有0,1,2,3级,默认是0
# 26 对象适配器跟踪级别,通常有0,1,2,3级,默认是0
# 27 服务跟踪级别,通常有0,1,2,3级,默认是0
# 28 IceGrid管理器登录该应用的用户名
# 29 IceGrid管理器登录该应用的密码
未涉及的属性还有一些,如果需要请参考官方文档。

2.1.2 从注册服务配置

config_slave.grid的内容:
#
# The IceGridlocator proxy.
#
Ice.Default.Locator=YunIceGrid/Locator:default-h 10.0.2.241 -p 4061:default -h 10.0.2.242-p 4061 #1
#
# IceGridregistry configuration.
#
IceGrid.Registry.Client.Endpoints=default-p 4061 #2
IceGrid.Registry.Server.Endpoints=default #3
IceGrid.Registry.Internal.Endpoints=default #4
IceGrid.Registry.Data=slave_1 #5
IceGrid.Registry.ReplicaName=slave_1 #6
IceGrid.Registry.PermissionsVerifier=YunIceGrid/NullPermissionsVerifier #7
IceGrid.Registry.AdminPermissionsVerifier=YunIceGrid/NullPermissionsVerifier#8
IceGrid.Registry.SSLPermissionsVerifier=YunIceGrid/NullSSLPermissionsVerifier#9
IceGrid.Registry.AdminSSLPermissionsVerifier=YunIceGrid/NullSSLPermissionsVerifier #10
#
# IceGrid SQLconfiguration if using SQL database.
#
#Ice.Plugin.DB=IceGridSqlDB:createSqlDB #11
#IceGrid.SQL.DatabaseType=QSQLITE #12
#IceGrid.SQL.DatabaseName=register/Registry.db #13
#
#Ice Error andStandard output Set
#
#Ice.StdErr=slave_1/stderr.txt #14
#Ice.StdOut=slave_1/stdout.txt #15
#
#Trace Registryproperties
#
Ice.ProgramName=Slave_1 #16
IceGrid.Registry.Trace.Node=3 #17
IceGrid.Registry.Trace.Replica=3 #18
#
# IceGrid nodeconfiguration.
#
IceGrid.Node.Name=node_2 #19
IceGrid.Node.Endpoints=default #20
IceGrid.Node.Data=node_2 #21
IceGrid.Node.CollocateRegistry=1 #22
#IceGrid.Node.Output=node_2 #23
#IceGrid.Node.RedirectErrToOut=1 #24
# Traceproperties.
#
IceGrid.Node.Trace.Activator=1 #25
#IceGrid.Node.Trace.Adapter=2 #26
#IceGrid.Node.Trace.Server=3 #27
#
# Dummy usernameand password for icegridadmin.
#
IceGridAdmin.Username=mygrid #28
IceGridAdmin.Password=mygrid #29
配置项说明:
其实这个文件和主注册配置文件基本一样,差别只有一点:
1. 没有指定应用实例名,因为在主注册服务中已经有了定义
2. 多了第6行,IceGrid.Registry.ReplicaName=slave_1,指定从注册服务的名称
其它的基本就没有差别了,大部分属性项在config_master.grid里面都有定义,为了方便阅读,下面也将用到的各项给出说明:
# 1 注册服务的端点信息(主注册服务和所有的从注册服务),节点注册时要用到
# 2 客户端访问注册服务器的端点信息
# 3 服务访问注册服务器的端点信息,通常是default
#4 内部访问端点信息,通常是default,节点用这个端口和注册服务通信
# 5 注册服务的数据目录的路径
# 6 指定从注册服务的名称
# 7 设定防火墙安全代理,从而控制客户端访问注册表时可用的权限
#8 设定防火墙安全代理,从而控制注册表管理者可用的权限
# 9 设定SSL安全代理,从而设定客户端访问注册表时的SSL安全访问机制
#10 设定SSL安全代理,从而设定注册表管理者的SSL安全访问机制
# 11 指定Ice对象序列化的机制,如果不设置,默认用Freeze机制
# 12 指定使用数据库的类型
#13 指定使用数据库的名称
#14 指定标准错误输出文件
#15 指定标准输出文件
#16 指定从注册服务运行时程序名称
#17 指定从注册服务跟踪节点信息的级别(0~3),默认为0
#18 指定主/从热备注册服务的跟踪级别(0~3),默认为0
# 19 定义节点的名称,必须唯一
# 20 节点被访问的端口信息,注册服务使用这个端点和节点通信,通常设为default
# 21 节点的数据目录的路径
# 22 定义节点是否和注册服务并置在一起,设为1时并置,设为0时不并置
# 23 节点标准输出信息重定向蹈的目录路径,会自动生成输出文件
# 24 节点上的服务程序的标准错误重定向到标准输出
# 25 激活器跟踪级别,通常有0,1,2,3级,默认是0
# 26 对象适配器跟踪级别,通常有0,1,2,3级,默认是0
# 27 服务跟踪级别,通常有0,1,2,3级,默认是0
# 28 IceGrid管理器登录该应用的用户名
# 29 IceGrid管理器登录该应用的密码

2.1.3 应用部署配置

app.xml配置文件内容:

1<icegrid>

2 <application name=“RTDSSystem”>

3 <server-template id=“RTDSSystemServer”>

4 <parameter name=“index”/>

5 <server id=“RTDSSystemServer-${index}”exe=Java activation=“on-demand”>

6 <adapter name=“RTDataSysytem” endpoints=“tcp” replica-group=“ReplicatedRTDataSysytemAdp”/>

7 <option>-jar</option>

8 <option>ServerApp.jar</option>

9 </server>

10 </server-template>

11

12 <replica-group id=“ReplicatedRTDataSysytemAdp”>

13 <load-balancing type=“round-robin”/>

14 <object identity=“RTDataSource” type=“::RTDataSystem::RTDataSource”/>

15 </replica-group>

16

17 <node name=“node_1”>

18 <server-instance template=“RTDSSystemServer” index=“1”/>

19 <server-instance template=“RTDSSystemServer” index=“11”/>

20 <server-instance template=“RTDSSystemServer” index=“111”/>

21 </node>

22 <node name=“node_2”>

23 <server-instance template=“RTDSSystemServer” index=“2”/>

24 <!–server-instancetemplate=”RTDSSystemServer” index=”22″/–>

25 <!–server-instancetemplate=”RTDSSystemServer” index=”222″/–>

26 </node>

27 <node name=“node_3”>

28 <server-instance template=“RTDSSystemServer” index=“3”/>

29 <!–server-instancetemplate=”RTDSSystemServer” index=”33″/–>

30 <!–server-instancetemplate=”RTDSSystemServer” index=”333″/–>

31 </node>

32 </application>

33</icegrid>

配置文件结构分析:

IceGrid里,部署是一个在注册服务中表述一个应用(Application)的过程,而部署配置文件就是来描述这些配置信息的文件,这个配置文件是用xml标记性语言来描述的。通常一个部署应该包含如下信息:

1. 应用标签(application),name属性定义这个应用的名字

2. 服务(server), 一个逻辑上的服务器,能够通过exe命令而启动的一个服务程序。activation属性,是设置服务的启动方式,on-demand是最常用的方式,另外还有always等启动方式;option标签是exe执行命令命令行的参数;

3. 适配器(adpter),定义服务器端的适配器。

name属性唯一标志这个适配器;

endpoints属性指定端点信息;

replica-group属性标示该适配器是个可复制组集群,并指定这个可复制组的名称;

register-process属性定义了是否这个节点是否可以被icegrid关闭;

4. 节点(node),它应该代表了一个物理上的节点。

name属性指定节点的名字,并且是唯一的。

5. 可复制组(replica-group),一组对象适配器的集合。

id属性唯一标识一个可复制组;

load-balancing子项中type属性指定负载均衡策略,icegrid提供了四种负载均衡策略: Random (随机方式)

Adaptive(适配方式)

Round Robin(最近最少使用)

Ordered(顺序方式)

object子项定义适配器绑定的服务对象信息。其中identity属性指定对象的标识,type属性指定了对象的层次结构类型。这两个属性都可以唯一的标识一个服务对象。

6. 服务模板(server-temple),服务模板是对服务的一个抽象,避免了重复定义。这样,在节点中描述服务时只需要实例化它的服务模板就可以了。

id属性唯一标识一个服务模板;

parameter子项定义服务模板的参数,可包含多个,主要实例化服务时用;

server子项就是上面2中的服务定义;

另外还有一些特殊的服务模板,比如:icebox服务模板,它的定义和通用的服务模板的定义不太一样。

解析app.xml文件:

通过对配置文件结构的分析,来解析一下app.xml。

第1行,标识这是一个icegrid的配置文件;

第2行,标识应用的名称为RTDSSystem,这个名称是唯一的;

第3~10行,定义了一个服务模板RTDSSystemServer,并有一个参数index;

其中5~9定义了这个模板包含的服务定义,第6行是这个服务包含的对象适配器

的定义;

第12~15行,是对可复制组的定义,包括服务对象的定义和负载均衡策略;

第17~21行,是对节点node_1的定义,指定了节点的名称,包含的服务(3个服务);

第22~26行,是对节点node_2的定义

第27~31行,是对节点node_3的定义

最后两行是闭合标签,至此一个icegrid的分布式部署配置文件就完成了。

部署配置文件的扩展:

app.xml中对服务模板、适配器、服务对象等的配置都是一个,事实上这些可以在文件中定义多个,比如可以有多个服务模板,一个服务里可以有多个适配器,可以有多个可复制组,一个节点里可以有多个不同类型的服务等。

另外,app.xml可以包含其它的xml。

2.1.4 节点配置

config.grid文件的内容:

# The IceGridlocator proxy.
#
Ice.Default.Locator=YunIceGrid/Locator:default-h 10.0.2.241 -p 4061:default -h 10.0.2.242-p 4061 #1
#
# IceGrid nodeconfiguration.
#
IceGrid.Node.Name=node_2 #2
IceGrid.Node.Endpoints=default #3
IceGrid.Node.Data=node_2 #4
IceGrid.Node.Output=node_2 #5
IceGrid.Node.RedirectErrToOut=1 #6
# Trace properties.
#
IceGrid.Node.Trace.Activator=1 #7
#IceGrid.Node.Trace.Adapter=2 #8
#IceGrid.Node.Trace.Server=3 #9

配置项说明:
事实上,这个文件里面的配置项,在config_slave.grid中都有描述,但这里也列出来,方便阅读。
#1 注册服务的端点信息(主注册服务和所有的从注册服务),节点注册时要用到
#2 定义节点的名称,必须唯一
#3 节点被访问的端口信息,注册服务使用这个端点和节点通信,通常设为default
#4 节点的数据目录的路径
#5 节点标准输出信息重定向的目录路径,会自动生成输出文件
#6 节点上的服务程序的标准错误重定向到标准输出
#7 激活器跟踪级别,通常有0,1,2,3级,默认是0
#8 对象适配器跟踪级别,通常有0,1,2,3级,默认是0
#9 服务跟踪级别,通常有0,1,2,3级,默认是0

2.2 客户端配置

客户端的配置很简单,和分布式相关的配置就一项,添加如下:
#
# The IceGridlocator proxy.
#注册服务的端点信息(主注册服务和所有的从注册服务),用于定位
Ice.Default.Locator=YunIceGrid/Locator:default-h 10.0.2.241 -p 4061:default -h 10.0.2.242-p 4061

3. 结果验证

3.1 程序方式

1. 启动服务器
1) icegridnode–Ice.Config=config_master.grid 启动主注册服务和节点1
2) icegridnode–Ice.Config=config_slave.grid 启动从注册服务和节点2
3) icegridadmin–Ice.Config=config_master.grid -e “application add app.xml” 部署分布式服务
4) icegridnode–Ice.Config=config.node 启动节点3
2. 启动客户端,进行多次远程调用,根据执行情况就可以判断服务器端是否配置成功。

3.2 工具方式

用Ice官方提供的可视化管理工具IceGridGUI.jar来验证和管理icegrid的部署。
打开dos窗口,在命令行下进入C:\Program Files\ZeroC\Ice-3.4.1\bin目录下,然后运行“java –jar IceGridGUI.jar”,弹出IceGrid Admin的主界面

1. 高级应用配置

4.1 集成IceBox

在文档《IceBox开发和配置》(当前是1.0版)中,介绍了一个IceBox服务程序的开发方法和单独应用中配置和管理的过程。在实际的应用中,IceBox服务通常集成到IceGrid中,并通过IceGrid进行激活和部署。
本章节中IceBox服务是集成在IceGrid中,并通过IceGrid进行部署,所以IceBox服务的配置信息不再同《IceBox开发和配置》中一样在config.icebox中描述,而是直接配置在部署文件app.xml中。那也就是说,IceGrid集成IceBox服务,只需要在app.xml文件中添加Icebox服务相关的配置信息就可以了。事实上,有关Ice所有的配置信息(除IceGrid自身的配置信息),都可以添加到app.xml中,并通过icegrid部署后生效。
下面各节详细描述IceBox服务的集成过程。

4.1.1 IceBox服务程序编写

请参考文档《IceBox开发和配置》,这里不再详述。由于IceBox服务相关的配置信息都放在了app.xml中,并且服务是通过IceGrid按需激活的,因此这里程序代码略有调整。下面列出IceBox服务的实现代码:
文件名:ServerService.java

import main.java.DataSource;

import IceBox.Service;

public class ServerService implements IceBox.Service {

/**

* @param name 配置文件中的service名称

* @param communicator对象,由IceBox.ServiceManager负责创建和销毁。

* 可能同时被其他服务共享使用(由配置文件决定),object Adapter的名

* 称必须是唯一的;

* @param args 配置文件中的参数列表

* @Override

**/

public void start(String name,Ice.Communicator communicator,

String[] args){

//创建objectAdapter,名称有配置文件决定

Adapter =communicator.createObjectAdapter(

“RTDataSystem-“+name);

//创建servant

StringRTDataSourceIdentity = communicator.getProperties().

getProperty(“RTDataSource.Identity”);

DataSourceobjDataSrc = new DataSource(“dataSource”);

Adapter.add(objDataSrc,

communicator.stringToIdentity(RTDataSourceIdentity));

Adapter.activate();

}

/**

*

* @param args

* @Override

*

**/

public void stop()

{

Adapter.destroy();

}

private Ice.ObjectAdapter Adapter;

}

4.1.2 IceGrid集成IceBox服务

IceGrid集成IceBox只和部署文件(app.xml)有关,IceBox服务(service)的粒度和普通的server是一样的,因此IceBoxservice的部署和普通的server非常类似,它同样有模板、服务(service)和实例化的概念,可以将IceBox service理解为一个特殊的server。
为了能更清楚的描述这个集成配置的过程,在IceGrid配置的基础上,添加IceBox服务。具体目标如下:
1. 集成ServerService服务(service),并且ServerService服务(service)使用的服务对象和之前server的服务对象使用同一个(type–::RTDataSystem::RTDataSource)
2. 在节点1(node_1)上添加IceBox服务功能(IceBox-Node1),这个IceBox服务包含了5个ServerService服务;同样的在节点2(node_2)上也添加一个IceBox服务功能(IceBox-Node2),也包含了5个ServerService服务
3. 这些IceBox服务中分布的多个服务(service)和之前已经存在的服务(server)一起通过IceGrid实现负载均衡
为了实现上述的功能,需要添加IceBox服务的相关配置,首先看一下此时app.xml的变化,变化和添加部分用浅灰阴影标出。
app.xml
<?xml version=”1.0″encoding=”UTF-8″ ?>
<icegrid>
<applicationname=”RTDSSystem“>
<server-templateid=”RTDSSystemServer“>
<parameter name=”index“/>
<server id=”RTDSSystemServer-${index}” exe=”java“activation=”on-demand“>
<adapter name=”RTDataSysytem“endpoints=”tcp
replica-group=”RTDataSystemGroup“/>
<option>jar</option>
<option>ServerApp.jar</option>
</server>
</server-template>
<!— begin服务模板定义–>
1 <service-templateid=”RTDSystemService“>
2 <parameter name=”name“/>
3 <service name=”${name}” entry=”ServerService“>
4 <description>A simple service named after ${name}</description>
5 <properties>
6 <property name=”RTDataSource.Identity” value=”RTDataSource“/>
7 </properties>
8 <adapter name=”RTDataSystem-${name}” endpoints=”tcp
id=”RTDataSystem-${name}” replica-group=”RTDataSystemGroup
server-lifetime=”false“/>
11 </service>
12 </service-template>
<!– end服务模板定义–>
<replica-groupid=”RTDataSystemGroup“>
<load-balancingtype=”round-robin“/>
<!–load-balancingtype=”ordered” /–>
<!–load-balancingtype=”adaptive” /–>
<!–load-balancingtype=”random” n-replicas=”0″/–>
<object identity=”RTDataSource” type=”::RTDataSystem::RTDataSource“/>
</replica-group>
<node name=”node_1“>
<server-instancetemplate=”RTDSSystemServer” index=”1“/>
<server-instancetemplate=”RTDSSystemServer” index=”11“/>
<server-instancetemplate=”RTDSSystemServer” index=”111“/>
<!— begin IceBox服务配置 IceBox-Node1–>
1 <icebox id=”IceBox-Node1” activation=”on-demand“exe=”java”>
2 <description>Asample IceBox server IceBox-Node1</description>
3 <option>IceBox.Server</option>
4 <properties>
5 <property name=”IceBox.InstanceName” value=”${server}“/>
6 <property name=”Ice.Admin.Endpoints” value=”tcp -h 10.0.2.241“/>
7 <property name=”IceBox.Trace.ServiceObserver” value=”1“/>
8 </properties>
9 <service-instance template=”RTDSystemService” name=”one“/>
10 <service-instancetemplate=”RTDSystemService” name=”two“/>
11 <service-instancetemplate=”RTDSystemService” name=”three“/>
12 <service-instancetemplate=”RTDSystemService” name=”four“/>
13 <service-instancetemplate=”RTDSystemService” name=”five“/>
14 </icebox>
<!— end IceBox服务配置 IceBox-Node1–>
</node>
<node name=”node_2“>
<server-instancetemplate=”RTDSSystemServer” index=”2“/>
<server-instancetemplate=”RTDSSystemServer” index=”22“/>
<server-instancetemplate=”RTDSSystemServer” index=”222“/>
<!— begin IceBox服务配置 IceBox-Node2–>
1 <icebox id=”IceBox-Node2” activation=”on-demand“exe=”java“>
2 <description>Asample IceBox server IceBox-Node2</description>
3 <option>IceBox.Server</option>
4 <properties>
5 <property name=”IceBox.InstanceName” value=”${server}“/>
6 <property name=”Ice.Admin.Endpoints” value=”tcp -h 10.0.2.242“/>
7 <property name=”IceBox.Trace.ServiceObserver” value=”1“/>
8 </properties>
9 <service-instancetemplate=”RTDSystemService” name=”2-one”/>
10 <service-instancetemplate=”RTDSystemService” name=”2-two“/>
11 <service-instancetemplate=”RTDSystemService” name=”2-three“/>
12 <service-instancetemplate=”RTDSystemService” name=”2-four“/>
13 <service-instancetemplate=”RTDSystemService” name=”2-five“/>
14 </icebox>
<!— begin IceBox服务配置 IceBox-Node2–>
</node>
<node name=”node_3“>
<server-instancetemplate=”RTDSSystemServer” index=”3“/>
</node>
</application>
</icegrid>
app.xml中增加的IceBox服务相关的配置部分如下:
n 服务摸板(Service Template):
可以对比一下servertemplate的定义,两者基本上没有什么区别,最大的不同是
Server template中server是指定一个可执行的程序,而service中指定的是动态加载
的组件入口。以下解释上述配置中的服务模板的定义:
第1行指定定义模板的id,唯一标志一个服务模板,第12是闭合标签;
第2行定义了一个参数name,默认值是“name”;
第3~11行定义了模板中使用的服务(service),并在该service中指定了名称、
入口、描述信息、配置属性,定义了一个对象适配器;
第4行,是该服务的描述信息;
第5~7行,是属性定义列表,这里定义了一个属性RTDataSource.Identity,并
指定其值为RTDataSource;
第8行,定义了一个对象适配器,指定了其name、endpoints、id、replica-group
等属性信息,这个基本上和server中adapter的定义没有什么区别
以上内容就是service模板的定义。
n IceBox服务(IceBox-Node1):
icebox服务的定义被包含在分布的服务器节点中,主要包括三部分的信息:
1. IceBox服务的启动配置信息
2. IceBox的属性配置信息
3. Service服务实例化列表
下面解释这块内容:
第1~3行,指定了IceBox服务的名称,启动方式,启动执行程序等
第4~8行,指定了IceBox服务的属性配置列表,这里定义了IceBox服务的实
例名称、管理器访问端点以及service被跟踪的级别
第9~13行,实例化了5个service服务
至此,一个包含了5个serverservice服务的IceBox服务被集成在node1中。
n IceBox服务(IceBox-Node2)
同IceBox服务(IceBox-Node1)中描述,只是具体value有所不同,这里不再解释。

4.1.3 测试验证

验证方式同第3章,这里不再赘述。部署完成后,就可以通过IceGridGUI.jar程序来进行管理
参考来源:http://blog.csdn.net/educast/article/details/9414789

struts2 upgrade 2.3 to 2.5 migration 升级向导

Dependencies

Update Struts dependencies to 2.5.

Remove the following plugin dependencies because they were dropped and aren’t supported anymore.

  • Dojo Plugin
  • Codebehind Plugin
  • JSF Plugin
  • Struts1 Plugin

StrutsPrepareAndExecuteFilter

The org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter was moved to org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.

In web.xml replace this:

<filter>
    <filter-name>struts2</filter-name>
    <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>

with that:

<filter>
    <filter-name>struts2</filter-name>
    <filter-class>org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>

There were other package changes, please read Version Notes 2.5 for more details.

DTD

Struts DTD was updated to 2.5 version.

In struts.xml replace 2.3 DTD version:

<!DOCTYPE struts PUBLIC
        "-//Apache Software Foundation//DTD Struts Configuration 2.3//EN"

with 2.5:

<!DOCTYPE struts PUBLIC
        "-//Apache Software Foundation//DTD Struts Configuration 2.5//EN"

Tags attributes

The id attribute was replaced with var attribute in the following tags.

  • <s:action>
  • <s:append>
  • <s:bean>
  • <s:date>
  • <s:generator>
  • <s:iterator>
  • <s:merge>
  • <s:number>
  • <s:set>
  • <s:sort>
  • <s:subset>
  • <s:text>
  • <s:url>

If you have something like that in your code:

<s:url id="url" action="login">

change it to:

<s:url var="url" action="login">

The <s:set> tag name attribute is replaced with var attribute.

From:

<s:set id="str1" value="'string1 value'" />
<s:set name="str2" value="'string2 value'" />

to:

<s:set var="str1" value="'string1 value'" />
<s:set var="str2" value="'string2 value'" />

Also escape attribute was renamed to escapeHtml attribute.

From:

<s:property escape="true" var="someProperty"/>

to:

<s:property escapeHtml="true" var="someProperty"/>

Div tag

The <s:div> tag was dropped.

Replace <s:div> with plain HTML <div> tag.

Field names

If you have field names which starts with single lower case letter, for example:

private String sTrng;
public String getSTrng() {...}
public void setSTrng(String str) {...}

change accessors to getsTrng and setsTrng.

Or better yet, change field names to not contain single lower case letter:

private String strng;
public String getStrng() {...}
public void setStrng(String str) {...}

For additional info see WW-3909.

Tiles

Depending on from which version of struts you upgrade and whether you used tiles-plugin or tiles3-plugin you may need to do different steps.

Struts 2.5 just provides a tiles-plugin which uses Tiles3. So support for Tiles2 has been dropped as well as the name tiles3-plugin.

Now the only maven dependency looks like this:

maven dependecy for tiles-plugin
<dependency>
    <groupId>org.apache.struts</groupId>
    <artifactId>struts2-tiles-plugin</artifactId>
    <version>${struts2.version}</version>
</dependency>

You may need to update DTD in your tiles.xml files to Tiles3:

tiles3 dtd
<!DOCTYPE tiles-definitions PUBLIC
       "-//Apache Software Foundation//DTD Tiles Configuration 3.0//EN"

A Listener in web.xml is required. It is not necessary to configure paths to tiles.xml files here as they are picked up automatically.

StrutsTilesListener in web.xml
<listener>
  <listener-class>org.apache.struts2.tiles.StrutsTilesListener</listener-class>
</listener>

Optionally you may remove TilesDefinitions from XML and annotate actions instead. See Tiles Plugin for more details.

Temp/Work directory of ApplicationServer/ServletContainer

Users reported it was necessary for them to remove temp/work directory of their ApplicationServer/ServletContainer. Likely to force server to recompile JSPs.

来源:https://cwiki.apache.org/confluence/display/WW/Struts%202.3%20to%202.5%20migration

WordPress错误:无法安装这个包。PCLZIP_ERR_MISSING_FILE (-4) : Missing archive file

WordPress更新或是上传插件或主题错误时出现“无法安装这个包。PCLZIP_ERR_MISSING_FILE (-4) : Missing archive file”错误在某些配置不够完善的主机中可能会出现这种情况。这是因为空间中temp目录没有设置访问权限的问题,需要空间商为你设置目录访问权限,一般这种要求他们是不会理的,所以我们只能改变WordPress的上传临时目录。

解决方法如下

1. 通过网站FTP打开WordPress根目录下的 wp-config.php 文件,找到如下代码:

/** WordPress 目录的绝对路径。 */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

2. 在下面增加如下代码即可:

/** 指定WordPress的临时目录 */
define('WP_TEMP_DIR', ABSPATH . 'wp-content/temp');

3. 最后在 /wp-content/ 文件夹下新建个一个名为 temp 的文件夹,然后再重新上传或者更新下载插件和主题就可以了。

最好叫 temp 权限和系统中一致为777

Go 1.8 正式发布,编译时间比 Go 1.7 提高约 15%

今天Go 团队很高兴地宣布Go 1.8发布了。现已提供下载。整个标准库有了显著的性能提升和变化。该版本主要的更新内容如下:

  • Go 1.7中为64位x86引入的编译器后端现在用于所有体系结构,这些体系结构将会有显著的性能改进。例如,我们的基准程序所需的CPU时间在32位ARM系统上减少了20-30%。在此版本中,64位x86系统还有一些性能改进,编译器和链接器更快了,编译时间应该比Go 1.7提高约15%。但是在这一领域还有很长的路要走:我们希望在未来版本中实现更快的编译速度。
  • 垃圾收集暂停时间明显更短,通常在100微秒以下,有时候甚至低至10微秒。
  • HTTP服务器添加对 HTTP/2 Push的支持,允许服务器抢先发送响应到客户端。这对于通过消除往返行程来最小化网络延迟非常有用。HTTP服务器现在还支持正常关机了,允许服务器通过在服务所有正在运行的请求之后关闭,而最小化停机时间。
  • 上下文(添加到Go 1.7中的标准库)提供了取消和超时机制。Go 1.8在标准库中添加了更多对上下文的支持,包括数据库/ sql和net包以及net / http包中的Server.Shutdown。
  • 现在使用新添加的Slice函数在排序包中对切片进行排序更简单。例如,要通过“名称”字段对结构体片段进行排序:
sort.Slice(s,func(i,j intbool {return s [i] .Name <s [j] .Name})

更多新版本的添加、改进和修复内容,以及上面列出的改进的详细信息请查看Go 1.8发行说明。

为了庆祝发布,世界各地的Go用户组都在本周举办发布会,这已经成为Go社区的一个传统,所以如果你错过了这一次,那么请在 GO 1.9 发布前留意。

via:https://blog.golang.org/go1.8

Java 9进入第一轮问题修复阶段

来源:infoq.com  作者:Abraham Marín Pérez ,译者 尚剑

Java 9功能特性正式完成,这意味着第一个问题修复阶段已经开始。HTTP/2客户端没有在截止日期前完成,现已降级为孵化器功能。由于现在的目标是在7月准备好可发布的Java 9,所以目前不太可能添加任何新的JEP。

InfoQ此前的报道中提到,第一轮问题修复阶段,或者说“启动Rampdown”阶段的目的是解决P1至P3级别的问题。其中,根据Java平台的首席架构师Mark Reinhold提出的流程,问题修复应该优先考虑Java 9中的新问题,而不是影响Java 9但已经存在于Java 8或更早版本Java中的问题,之所以这么做,可能是因为相对于新的问题,公众更容易忍受已经存在的问题。Reinhold提供的缺陷列表显式地过滤掉了只与文档、演示和测试相关的缺陷,这似乎表明了他们对用户体验的关注。在撰写本文时,该列表中有194个缺陷。

这一阶段还包括一个规定,如果有正当理由,可以留下一些未解决的P1至P2级别的问题。希望推迟其解决方案的问题所有者必须在错误报告中指出其请求的原因(复杂性、风险、时间不足等),然后相关区域负责人、小组负责人和JDK 9 Project 负责人将分析这些数据并同意或拒绝延期。在写这篇文章的时候,这个列表中暂时还没有推迟请求,但以后可能会出现。

这个Rampdown阶段在特定的扩展功能完成阶段之后进行,以给予一些JEP完成的时间。HTTP/2客户端以及增强弃用、jlink、和新的HotSpot编译系统都是在2016年7月出现风险的功能。其中,HTTP/2 Client是唯一一个没有最终做出来的功能,转而成为孵化器功能。这意味着,尽管HTTP/2 Client将包含在Java 9中,但默认情况下不可访问:该功能将被打包在前缀为jdk.incubator.的模块下,开发人员必须显式地使用–add-mod标记才能访问该功能。然而,如果开发人员选择这样做,他们将需要考虑到孵化器功能不是标准API的一部分,因此该功能可能随时被修改。

阅读英文原文Java 9 Enters First Bug Fixing Round

Linux Kernel 3.18 LTS 终止支持 请升至 4.9 或 4.4 分支

在发布最后一个维护版本更新之后,Linux 稳定版内核维护者 Greg Kroah-Hartman 宣布 Linux Kernel 3.18 分支走到了生命的尽头。而 3.18 LTS 原计划于今年 1 月终止支持。

Linux Kernel 3.18.48 LTS 是该分支的最后版本,根据短日志显示该版本共计调整了 50 个文件,插入 159 处删除 351 处。升级网络堆栈的同时改善了 Bluetooth, Bridge, IPv4, IPv6, CAIF 和 Netfilter,并升级了 USB, SCSI, ATA, media, GPU, ATM, HID, MTD, SPI 和网络(有线和无线)驱动。新发布的 3.18.48 还修正了 3.18.47 和 3.18.27 中的一个 bug。

LTS 版通常会提供大约两年的支持时间,3.18 是在 2014 年 12 月发布的。如果你当前还在使用该内核分支,那么现在你应该升级至更新的 LTS 版本,例如 Linux Kernel 4.9 或者 4.4,这两个版本要比 3.18 更加的安全和强悍。不过 Linux Kernel 3.18 主要被 Google 和其他供应商应用于一些 Android 设备、部分 Chromebook 上,Kroah-Hartman 建议用户拒绝购买仍然使用 3.18 LTS 的供应商的设备。如果无法升级内核开发者也提供了一些建议。

“如果你在使用 Linux Kernel 3.18 中有困难,那么我可以给你提供一些帮助。首先,你需要和硬件供应商反馈,要求尽快升级否则不再购买他们的产品。如果供应商还是不升级,请致信我们让我们出面和厂商进行沟通,出现这个问题的肯定不止你一个人。”

来源:http://www.oschina.net/news/81799/linux-kernel-3-18-48-released

Firebug 宣布不再维护,讲不出再见!

Firebug 在其官方网站上宣布 —— “Firebug 扩展不再进行开发或维护,我们邀请您使用 Firefox 的内置开发工具以代替”。

Firebug 是 Firefox 下的一款开发类插件,现属于 Firefox 的五星级强力推荐插件之一。它集 HTML 查看和编辑、Javascript 控制台、网络状况监视器于一体,是开发 JavaScript、CSS、HTML 和 Ajax 的得力助手。Firebug 如同一把精巧的瑞士军刀,从各个不同的角度剖析 Web 页面内部的细节层面,给 Web 开发者带来很大的便利。

来自:http://getfirebug.com/

WordPress 4.7 “Vaughan”发布,内容管理系统

WordPress 开发团队发布了 WordPress 4.7 正式版 —“Vaughan” 。取名“Vaughan”以纪念传奇的爵士乐歌手Sarah“Sassy”Vaughan。现在可以更新了。新版带来全新的默认主题,定制器加入了新功能,REST API 内容端点,更多开发者工具。

更新如下:

  • 新的主题 — Twenty Seventeen。全新的默认主题可让您的网站通过引人入胜的精选图片和视频头部生动呈现。

  • WordPress 4.7 为自定义程序添加了新功能,帮助您完成主题的初始设置,在一个不间断的工作流程中对所有更改进行非破坏性实时预览。
  • WordPress 4.7 带来了针对帖子、评论、条款、用户,元和设置的 REST API 端点。

来源

下载地址:https://wordpress.org/download/