4.0

在编译之前呢要有交叉编译环境阿,android内核 自带 有交叉编译器 进入android4.0.3 源码内核包中lichee #cd buildroot/dl/ 你将会看到 arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 编译kernal #cd lichee/linux-3.0 #make clean 如果你之前没有编译过那么这一步就不用了 #make ARCH=arm sun4i_crane_defconfig -->我的产品是sun4i_crane,这个一步是为了省略将来编译的时候让你选择ARM system type列出的选项 #make ARCH=arm menuconfig 这一步就是如果你没有指定的产品，那么省略上一步进行这一步操作，进行kernal图形界面的模块加载了 一切都配置完了呢，就该编译了 回到上一目录lichee中 #./build.sh -p sun4i_crane -k 3.0 参数-k表示选择的内核版本 如果中途没有出现意外的话，你会在最后看到，如下是针对（全志Allwinner出现的编译成功提示） ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ 编译成功 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ #cd out #ls 有个android 文件夹，里面包含了bImage,lib

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 装了64位的Win7后，装了VS再装IIS，结果IIS里面有.NET4.0，但是程序始终是跑不起来，最后觉得可能是因为4.0没有注册到IIS，因为之前在win2003中有遇到类似的情况。最终成功解决， 总结：在win7下如果先安装vs2010 （附带会安装Microsoft .NET Framework 4）后安装iis7的话，必须注册iis才可以用。 附带我安装命令吧： C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i 来源： oschina 链接： https://my.oschina.net/u/167767/blog/100924

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Android 4.1项目：使用新浪微博分享时报： 　　android.os.NetworkOnMainThreadException 网上搜索后知道是因为版本问题，在4.0之后在主线程里面执行Http请求都会报这个错，也许是怕Http请求时间太长造成程序假死的情况吧。那么网上的朋友也给出了相应的解决方案，这叫上有政策下有对策： 一：在发起Http请求的Activity里面的onCreate函数里面添加如下代码： // 详见StrictMode文档 StrictMode.setThreadPolicy( new StrictMode.ThreadPolicy.Builder().detectDiskReads().detectDiskWrites().detectNetwork().penaltyLog().build()); StrictMode.setVmPolicy( new StrictMode.VmPolicy.Builder().detectLeakedSqlLiteObjects().detectLeakedClosableObjects().penaltyLog().penaltyDeath().build()); 如果正在做的项目不是Android 4.0的是看不到StrictMode类的

每日构建版更新日志 版本号:20130310.228.116 构建日期：2013-03-10 228.打开首页显示更新列表的功能By madj 227.将默认编辑器调整为百度UEditorBy madj 226.系统菜单管理的菜单详细说明由原来的TextAreaBox类型修改为Richtextbox类型By madj 版本号:20130310.225.115 构建日期：2013-03-10 225.解决主界面修改密码对话框不显示的问题 解决用户管理模块重置密码对话框无法关闭的问题 解决发布日志模块修改日志对话框无法关闭的问题 来源： oschina 链接： https://my.oschina.net/u/92916/blog/112812

FreeEast有10来天没有更新，最近一段时间并没有闲着，先是等Wabacus4.0的发布，然后就是整合Wabacus4.0。这次Wabacus4.0整合的很不顺利，但总算是告一段落了。 目前这个版本里面还有好多BUG，因此暂时不会往稳定版本上整合发布。 由于East功能模块整合起来工作量比较大，而且好像也没有什么人在使用，因此本次升级直接将该模块去掉。以后如果需要再重新整合吧。 跟踪了好长时间，总算找到富文本编辑器不显示的原因了，但是还是没有找到配置文件的位置，所以只能临时性在程序里面改了。 版本号:20130310.224.112 构建日期：2013-03-10 224.升级Wabacus框架到4.0版本 目前这个版本还不稳定，里面还有相当多的BUG 来源： oschina 链接： https://my.oschina.net/u/92916/blog/112708

Storage backends 存储后端 Intro varnish拥有可插入式的存储后端，它可以存储数据在在各种不同表现特性的后端中。默认的配置就是使用限制了大小的malloc后端（基于内存的）。对于一些vanish部署方式，你可能需要调整储存设置来适合相应的部署方式。 malloc syntax: malloc[,size] malloc是基于内存的后端。每个对象都将从内存中分配资源来存储。如果你的系统运行内存较小，swap将会被使用。 请注意，该尺寸限制只限制了实际存储，同时使用各种内部机制使得每个对象在内存中大约占1k，这种情况也包括在真实的存储中。 size参数指定最大分配给vanishd的内存数量。size的假定单位是byte，除非你指定下面的一个后缀： K, k The size is expressed in kibibytes. M, m The size is expressed in mebibytes. G, g The size is expressed in gibibytes. T, t The size is expressed in tebibytes. 默认size是不限制的 malloc的性能依赖于内存速度，所以很快。如果数据集大于可用内存，malloc的性能将依赖操作系统的实际分页能力。 file syntax: file[,path[

CLI-bossing Varnish around CLI 向Vanish下发指令 一旦vanish启动，你可以使用命令行接口来控制它。 最轻松的使用CLI的方法是在运行varnishd的机器上运行，varnishadm varnishadm help 如果你想远程使用varnishadm，有两种方法。 你可以使用ssh登录到运行varnishd的机器上然后varnishadm ssh $http_front_end varnishadm help 同时你也可以配置vanishd接受远程的CLI连接，（使用-T和-S参数） varnishd -T :6082 -S /etc/varnish_secret 然后在远程主机上运行vanishadm，像这样 varnishadm -T $http_front_end -S /etc/copy_of_varnish_secret help 但是你也看到，ssh是更方便的。 如果运行vanishadm没有添加参数，它将会从标准输入读取CLI命令，如果你指定了参数，它将这些参数作为单个CLI命令来执行。 CLI总是返回一个状态码，告诉你操作的结果，'200'为成功，其他状态码就有问题了。 vanishadm退出时使用状态1，并且如果不是200的状态码，它将在标准错误输出中打印状态码。 What can you do with the CLI

Varnish Installation varnish的安装 本节包含了varnish安装的准备工作，一步一步的安装过程，怎样获取帮助，在哪里寻求帮助，已经怎样报告bug。也包含了帮助你在某些特殊的系统上安装varnish的注意事项. Prerequisites Installing Varnish Source or packages? FreeBSD Red Hat / CentOS Debian/Ubuntu Compiling Varnish from source Build dependencies on Debian / Ubuntu Build dependencies on Red Hat / CentOS Compiling Varnish Installing Getting help IRC Channel Mailing Lists Trouble Tickets Commercial Support Reporting bugs Varnish crashes Varnish goes on vacation Varnish does something wrong Platform specific notes Transparent hugepages on Redhat Enterprise Linux 6 OpenVZ TCP keep

Security first 安全第一 如果你仅仅抓专注于运行varnish,或者所有人都是这个观点,那么就可以跳过该节了.我们保护你的方方面面当http请求来的时候. 如果你的web基础设施是外包的,管理是分开的,那么你就需要考虑安全了. Varnish在4个权威的等级提供安全,大致关系到怎样让命令生效和在哪儿生效. the command line arguments, the CLI interface, VCL programs, and HTTP requests. Command line arguments 命令行参数 最高安全定理是决定和定义varnish的启动参数在一个表单里面,我们使用这个策略是为了新的操作也是安全的. 最重要的的决定是确保这些: Who should have access to the Command Line Interface? 谁有命令行的权限? Which parameters can they change? 他们可以修改哪些参数? Will inline-C code be allowed? 哪些内建C代码是被允许的? If/how VMODs will be restricted? 是否VMODs是被限制,怎样被限制? CLI interface access CLI接口权限 命令行接口可以通过三个方式进入.

Parameters Varnish cache 拥有一个参数的集合，可以影响varnish的行为和性能。基本上所有的参数都可以在Varnish命令行接口（ varnishadm ）使用param.set关键词来设置。 一些参数，处于安全的目的只读的参数，只能使用-r参数来开启。同时在varnishd的man手册中也有相关的说明 -r param[,param...] Make the listed parameters read only. This gives the system administrator a way to limit what the Varnish CLI can do. Consider making parameters such as user, group, cc_command, vcc_allow_inline_c read only as these can potentially be used to escalate privileges from the CLI. Protecting listen_address may also be a good idea. 我们不建议你调整参数除非你确定你做的是什么。我们努力的使用稳定的默认值，同时varnish使用默认设置应当能处理大多数的工作情况。