PPTP一键安装脚本 for Ubuntu Xen VPS

最近avantehosting促销,推出了半年付6刀的Xen 128 VPS。
正好手头缺个VPS折腾点小东西,就入手了。

首先的需求是弄个VPN,于是根据别人的脚本改了个适合Xen VPS的一键安装脚本
使用方法:

wget https://gist.github.com/raw/3110375/70544548700d82e527fa716f28319940964c8a30/pptpinstall.sh -O pptpinstall.sh
chmod +x pptpinstall.sh
./pptpinstall.sh

多谈一下avantehosting的vps,如果图便宜,可以考虑买一个。
机房在佛罗里达,ping值在300左右。62G的月流量不算大,但也够用。
开通的时候,遇到些小问题。发ticket后大概12小时解决了。

附UnixBench跑分结果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
========================================================================
BYTE UNIX Benchmarks (Version 5.1.3)
System: GNU/Linux
OS: GNU/Linux -- 3.0.0-12-server -- #20-Ubuntu SMP Fri Oct 7 16:36:30 UTC 2011
Machine: x86_64 (x86_64)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
CPU 0: Intel(R) Xeon(R) CPU E31230 @ 3.20GHz (6385.5 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET
05:02:08 up 1:13, 1 user, load average: 0.74, 0.39, 0.47; runlevel 2
------------------------------------------------------------------------
Benchmark Run: Sat Jul 14 2012 05:02:08 - 05:30:20
1 CPU in system; running 1 parallel copy of tests
Dhrystone 2 using register variables 23631847.0 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2683.8 MWIPS (9.9 s, 7 samples)
Execl Throughput 1202.5 lps (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 264524.8 KBps (30.1 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 53671.6 KBps (30.1 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 908392.9 KBps (30.1 s, 2 samples)
Pipe Throughput 455343.1 lps (10.0 s, 7 samples)
Pipe-based Context Switching 59319.0 lps (10.0 s, 7 samples)
Process Creation 2945.3 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 2367.5 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 333.9 lpm (60.1 s, 2 samples)
System Call Overhead 429520.5 lps (10.0 s, 7 samples)
System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 23631847.0 2025.0
Double-Precision Whetstone 55.0 2683.8 488.0
Execl Throughput 43.0 1202.5 279.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 264524.8 668.0
File Copy 256 bufsize 500 maxblocks 1655.0 53671.6 324.3
File Copy 4096 bufsize 8000 maxblocks 5800.0 908392.9 1566.2
Pipe Throughput 12440.0 455343.1 366.0
Pipe-based Context Switching 4000.0 59319.0 148.3
Process Creation 126.0 2945.3 233.8
Shell Scripts (1 concurrent) 42.4 2367.5 558.4
Shell Scripts (8 concurrent) 6.0 333.9 556.5
System Call Overhead 15000.0 429520.5 286.3
========
System Benchmarks Index Score 466.4

附小广告一则:唱吧iOS团队诚招iOS工程师,推荐成功即奖励6000元现金或iPhone 6一部,详见这篇blog


了解iOS 6开发第一篇:新的Objective-C语法

写在前面:由于iOS Developer Program的NDA的限制,这系列文章会等到iOS 6正式发布时,再push到github上。因此你看到的这些文章,很可能是我两、三个月前学习iOS 6的时候写下的,难免会有不准确的地方,但我持续修改。如果你发现了问题,请在文章下面留言或者发邮件给我。另外我没有看中文文档的习惯,所以翻译术语真的很困难,如果你知道怎么翻译更好,也请告诉我。

iOS 6是激动人心的,也带来了一些比较大的改变。最近在看WWDC 2012 Video Session,这一系列的文章,是我在学习iOS 6的一些新特性的时候写的一些笔记,也希望对其它中国开发者有帮助。

WWDC 2012,介绍了新的Objective-C的语法。这些语法依赖于LLVM 4.0编译器,由Xcode 4.4/4.5提供。主要有三点变化:

  • Objective-C Literals & Boxing Expressions (Objective-C字面量 & 表达式装箱)
  • Collection Subscription (集合下标)
  • Automatic Property Synthesis (自动属性综合,Synthesis怎么翻译?)

Objective-C Literals & Boxing Expressions

LLVM 4.0之前:

1
2
3
4
[NSNumber numberWithInt:42]
[NSNumber numberWithDouble:10.8]
[NSNumber numberWithBool:YES]
[NSNumber numberWithInt:6 + x * 2012]

LLVM 4.0之后:

1
2
3
4
@42
@10.8
@YES
@(6 + x * 2012) //表达式要用(),这就是Boxing Expressions

Collection Subscription

LLVM 4.0之前:

1
2
3
4
[NSArray arrayWithObjects:a, b, c, nil]
[array objectAtIndex:i]
[NSDictionary dictionaryWithObjectsAndKeys:v1, k1, v2, k2, nil]
[dictionary valueForKey:k]

LLVM 4.0之后:

1
2
3
4
@[a,b,c] //这里没有nil
array[i]
@{k1: v1, k2: v2} //这里没有nil
dictionary[k]

Automatic Property Synthesis

LLVM 4.0之前:

1
@synthesize property;

LLVM 4.0之后:不需要使用@synthesize directive了

如何将代码转换为Modern Objective-C

Xcode 4.4+,Edit->Refactor->Convert to Modern Objective-C Syntax

少写了很多代码,可读性也提高了很多(我被nil哨兵坑了好多次- -!)。Less code, less bug.

参考资料:

附小广告一则:唱吧iOS团队诚招iOS工程师,推荐成功即奖励6000元现金或iPhone 6一部,详见这篇blog


了解iOS 6开发第三篇:内存管理 - 手动引用计数与自动引用计数

本文不会举例介绍MRC,如果不了解MRC,最好先简单了解一下,再回来读这篇文章。

从iOS 5开始,iOS开发就可以使用自动引用计数(Automatic Reference Counting)了。一直想写一篇详细的笔记,来整理这方面的信息,但一直拖到现在。这篇文章是
WWDC 2012 Session 406 - Adopting Automatic Reference Counting的笔记,如果对LLVM感兴趣,可以去llvm.org深入了解一下。

关于自动引用计数(Automatic Reference Counting, aka ARC)

很多工程师都是最近一、两年才开始接触iOS开发的。但大多数工程师都接触过Java/C#这样的静态编译语言,或者python/ruby这样的动态脚本语言。这些“现代”语言的都提供Garbage Collection的机制,由GC来负责内存的回收。我先强调一点:ARC是编译器提供的机制,而不是GC这种运行时提供的机制。要了解ARC,必须明白什么是引用计数,必须从MRC开始。此外,你会遇到很多旧的开源代码和静态库(比如广告平台)。这些很可能不支持ARC,所以还是要理解MRC。

关于手动引用计数(Manully Reference Counting, aka MRC)

Objective-C的MRC,简单来说就是一句话:谁创建,谁释放。复杂一点的解释如下:

  • 所有由alloc、copy(mutablecopy)、retain、new创建的object,必须手动release(或autorelease)
  • 反之,则不需要也不可以
  • autorelease不是自动释放,是AutoreleasePool的实例,在runloop中被”稍后“释放。

MRC有什么问题

常犯的错误:

  • Crash! Reject! 内存管理是导致app crash的最主要原因。也是App Store审核时拒审的最多的原因;
  • 规则简单,但细节太多,依赖于工程师的清醒头脑和良好习惯,依赖于命名规范
  • Dangling Pointer,delegate需要手动设置为nil
  • 触发NSError、或者有复杂的条件分支逻辑时,忘记释放内存

需要使用一堆工具,帮助你检测代码:

  • Instruments: Allocations, Leaks, Zombies
  • Static Analyzer
  • Heap
  • ObjectAlloc
  • vmmap
  • Debugger

工程师需要做的事情:

  • 理解MRC,写正确的代码
  • 正确的命名规范
  • 使用五花八门的辅助工具,来保证代码没问题
  • 保持清醒的头脑,不犯低级错误

这不是工程师所擅长的事情,这个工作应该由编译器来做才对—LLVM 3.1

什么是ARC

  • Objective-C对象的自动管理机制
  • 由LLVM编译器来保证
  • 与MRC完全兼容
  • 引入新的运行时特性:弱指针、性能优化

ARC不是

  • 新的运行时模型
  • 自动malloc/free, CF等等(不负责纯C代码的内存管理)
  • 不是GC。不扫描堆、不暂停进程运行、没有不确定的内存释放

ARC如何工作

  • 编译器在编译期,帮你动态添加retain/release/autorelease
  • 返回同样结果的不同API,在内存方面,没有区别(把alloc/init模式与convenient method当成一样就可以了)

ARC有什么好处

  • 不用写retain/release/autorelease这样的代码,甚至连dealloc方法都不需要(前提是类不需要管理C指针)
  • 更好的性能,ARC智能地在”适当“的地方插入retain/release
  • Block just work
  • Less code, less bug
  • 少浪费脑细胞和脑时钟周期

如何打开ARC

  • Xcode的Project Setting中,设置Objective-C Automatic Reference Counting为YES
  • Xcode 4.2+,新的Project默认为ARC

为了实现ARC,LLVM编译器必须保证4条规则

  • 不能调用或实现跟引用计数相关的方法(retain/release/autorelease/retaincount等),否则产生编译错误
  • C的结构体里面,不能有Object指针;如果必须使用,那么可以用Objective-C的类代替
  • 编译器必须清楚void*是否被retained。引入新的API来转换Objective-C和Core Foundation类型的对象
  • 编译器必须清楚自动释放的对象,因此AutoreleasePool不能是对象,而只是语义上的符号。@autoreleasepool directive甚至可能在MRC中使用

如何理解ARC

  • 从对象的从属关系角度考虑:强引用(retain)保证对象的存在,或没有强引用,则对象被自动销毁
  • 想清楚程序的对象图
  • 不要再考虑retain, release, autorelease了

弱引用(必须在iOS 5中使用)

  • 安全的”弱指针“,引用的对象被销毁时,自动变成nil;避免了Dangling Pointer
  • 在property中使用weak关键字声明,ivar中使用_weak声明

循环引用

  • ARC依然存在循环引用的可能
  • 手动设置某一个引用为nil,破坏循环引用
  • 使用弱引用来避免

性能

  • 与MRC没有实质的性能区别,甚至更好(有时候好得多),内存峰值比MRC低
  • 没有GC的开销;没有延迟的销毁,没有进程暂停,没有不能确定的释放

ARC的优点

  • 更容易理解
  • 写更少的代码,更少的bug
  • 更容易维护,甚至更好的性能
  • 安全、稳定

iOS的什么版本才能支持ARC

  • iOS 6发布后,以iOS 5.0作为Deployment Target完全没问题。所以都可以使用ARC。如果你必须支持5.0以下的设备,那么看后两条。
  • ARC由LLVM 3.1保证,LLVM 3.1在安装Xcode 4.2自动安装;也就是说只要Xcode 4.2以上的版本,可以设置的Deployment Target的最低版本,都支持ARC。笔者在4.0+的app中使用ARC。
  • 弱引用(Weak Reference)必须在iOS 5以上的设备才支持

总结

笔者其实觉得MRC很容易掌握,profile的工具也容易掌握。但ARC实实在在的从安全、可维护性、代码量、性能上有全面的提升。所以除非维护旧的代码,笔者都建议使用ARC。不用担心app依赖第三方的MRC代码,可以通过编译器设置文件的编译属性来混合使用ARC和MRC。

如果想更多地了解LLVM是如何智能地保证ARC,请阅读文章头部引用的两篇文章,里面有详细的解释和代码例子。

附小广告一则:唱吧iOS团队诚招iOS工程师,推荐成功即奖励6000元现金或iPhone 6一部,详见这篇blog


了解iOS 6开发第二篇:iOS常见设计误区

在iOS应用的设计上,存在一些常见的误区。WWDC 2012 Session 221 - iOS User Interface Design,指出了以下十种常见的误区。

误区一:糟糕的图标设计

iOS 4添加了文件夹功能,iOS 6的App Store中,用户可以进行批量下载。App Store发展的这四年,已经有了60多万的iPhone应用。制作一个App,周期一般从1个多月到半年、甚至一年不等,做几个、甚至十几个版本的图标,反复推敲,是完全值得的。优秀的图标设计,是每个优秀App的标配,也是每个设计师的必修课。

如何设计优秀的图标呢?苹果给的建议只有两条:美观漂亮;可以一眼识别。第一条是设计师取决于设计师的修养和风格。这里说下第二条。

如何设计“可以一眼识别的图标”:

  • 专注于一个独特的轮廓。如Music, iBooks, Instapaper。
  • 慎重地选择色系及颜色搭配。如Day One, Instagram。
  • 避免使用照片。
  • 避免图标上出现一堆文字。比较一下Vimeo、Pinterest、Tumblr的Logo和App图标。
  • 正确使用材质。如iCal、Notes、Camera应用。
  • 保持创新。这里要赞一下Evernote Food的图标设计(Sushi放在一个方形的碟子上)。
  • 在不同色系的主屏壁纸下,测试你的图标是否清晰。
  • 把App放进文件夹中,测试图标是否清晰。

误区二:强制用户注册

一些app是有账号系统的,比如社交网络类型的应用,或者Readability类型的应用。不要强制用户注册才可以使用,至少允许用户在不注册的情况下,使用app的一大部分功能。承受着用户获取成本的提高,这种粗暴的直接把用户拦在门外的做法,越来越不可取。

误区三:过小的控件

保证每个控件以及任何可点击的区域,不小于44 * 44的尺寸。大概是导航条的高度,也是内置Calculator应用的按钮高度。如果设计上为了突出一些功能,可以把最主要的功能的按钮变大,但要保证其它按钮不能小于最小范围。Instagram就是这样做的,拍照按钮在下方的UITabBar的最小间,但比其它按钮要大一些。

误区四:难以阅读的文本

正面代表是Mail,在列表界面和邮件正文界面,通过字体的阴影、大小、对齐等变化,达到最佳的阅读体验。

一些原则:

  • 使用阴影和字体大小,来区分不同层级的内容
  • 保证文字的主体清晰,易于阅读
  • 对齐文本,以便用户快速浏览
  • 右对齐Label,左对齐文本内容
  • 在iPhone和iPad上,分别测试你的应用

误区五:令人摸不着头脑的警告信息

  • 作为程序员和曾经的Windows用户,我只知道Error: 0xc000007b这样的信息可能是内存泄露;而普通用户甚至认为显示屏是PC的运算核心。不要把这些糟糕的提示风格带到Mac和iOS应用中。对用户要“说人话”。
  • 有歧义的提示:您想要取消交易吗?(OK, Cancel)两个选项,用户是搞不清楚应该选哪个的。
  • 避免不必要的警告提示;提示信息可以用非模态的方式展现,参见Mail里面,更新邮件后下方的状态条
  • 以直接的动作描述,来命名警告提示的待选按钮。如(Close, View)
  • 把确定、确认的按钮放在右边,取消、中断的按钮放在左边
  • 使用ActionSheet或者Popover来确认危险的操作(destructive operation)。如删除操作。

误区六:使用易于用户理解的语言

举一个正面例子:iOS 6的Settings中,Do Not Disturb开关,如果把Label文本换成System Alerts,明显会变得对用户不友好。“说人话”。

误区七:过度的品牌宣传

想象一下,把一个应用的导航条标题,全部换成产品名或者公司名,会怎么样?

误区八:无意义的后退按钮

Windows过来的设计师的通病。要使用有意义的标题来命名按钮,如上一个导航层级的标题,就比“后退”描述了更多信息。

误区九:令人困惑的动画变换

在视图切换,或者用户执行操作的时候,进行动画变换,可以增加逻辑感、沉浸感和“空间感”。但不要滥用。

误区十:应用的“风格”不恰当

  • 应用主要两种类型:娱乐类和工具类。娱乐类的应用更强调乐趣、沉浸感,工具类的应用更强调稳定性和效率。不要搞反了,强调风格也要适度。
  • 苹果建议尽可能地使用“仿真”的思路去设计:比如温度计、指南针这样的app,用户在物理世界中已经习得如何使用,没有额外的学习成本。

总结:

附小广告一则:唱吧iOS团队诚招iOS工程师,推荐成功即奖励6000元现金或iPhone 6一部,详见这篇blog