Scroll Reverser – 逆向滚轮[Mac]

Mac OS X 10.7 Lion 里面门槛最高的功能就是默认颠倒了鼠标滚轮的方向。原来向下滚轮页面下滑,而现在恰恰相反。显然,这样使用起来和 iOS 设备更加相像。宰父二狗已经决定完全投入教主怀抱。为了加速放弃原有习惯,在  Mac OS X 10.7 发布之前为自己的雪豹装了 Scroll Reverser。软件唯一功能就是翻转鼠标滚轮方向,和 Lion 中一样。@appinn

https://pilotmoon.com/scrollreverser/

 

为什么 Mac 的鼠标滚轮方向与 PC 相反?

我觉得苹果最傻逼的一点是明明提供了鼠标和触控板分别设定的选项,却必须强迫鼠标也跟随触控板的设定···自然滚动用在鼠标滚轮上特别别扭,但是改过来的话,用触摸板就别扭了

OS X 10.10.4 支持为第三方SSD开启TRIM

  威锋网讯,苹果昨天晚上发布了 OS X 10.10.4 更新,这个目前 Mac 上最新的系统最终还为第三方的固态硬盘(SSD)带来了 TRIM 支持,用户必须要手动开启,但过程并不繁琐。



  通过紧密监控未用的区域和报告 OS X 可抹除和编写的数据,TRIM 可以让 SSD 变得更高效。相反,当 SSD 被填满的时候就会变得比较缓慢,这也是 OS X 中存在的一个问题。



  其它不少的系统都支持 SSD 开启 TRIM,但此前在 OS X 中开启 TRIM 仅限苹果的自家 SSD,升级到 OS X 10.10.4 后,就可以为第三方 SSD 也开启 TRIM。



  根据外媒 Ars Technica 指出,在 OS X 10.10.4 中开启 TRIM 只需简单的一条终端命令即可。首先打开 Mac 上的“终端”然后输入“sudo trimforce enable”(引号不要),并点击返回即可。OS X 会提醒你开启 TRIM 可能会导致意想不到的数据丢失或者数据损坏,所以最好先对硬盘进行备份。



  输入指令开启 TRIM 后 Mac 会进行重启,这样就可以为第三方 SSD 开启 TRIM。之前有报道指出 OS X El Capitan 将原生开启第三方 SSD TRIM 支持,不过现在看起来苹果提前将这项功能推出。

How to fix warning: setlocale: LC_CTYPE: cannot change local

 After some googling found this blogpost from André Bergonse :

http://bergspot.com/blog/2012/02/how-to-fix-warning-setlocale-lc_ctype-cannot-change-locale-utf-8/

 
I made the mistake to put the export in the servers .bash_profile, but off course you need to put in your own OS X account .bash_profile or create this file.

$ vim .bash_profile
# OSX Lion ssh logon:
# -bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8)
export LC_CTYPE="en_US.UTF-8"

Afterwards you need to restart your terminal program, I use iTerm2, to have the settings take affect.

 
 

 

From http://ibohm.blogspot.jp/2012/03/how-to-fix-warning-setlocale-lcctype.html

Mac OS X下自带的字典,扩充英汉、汉英字典包

 google到的帖子,大多都是要用DictUnifier自行转换后,将转换后的dictionary文件拖入~/Library/Dictionaries目录,启动自带的字典程序,在偏好设置中启用新字典;





在此,给大家省一步转换的过程,找到转换好的朗道的英汉、汉英字典,分享链接如下:

 

 

google :langdao-ec-gb.dictionary.zip

 

iPhone的UDID与push中使用的device token的关系

 转自:http://idev.etao.com/?p=14

先简单介绍下push的机制

客户端通过

  • (void)registerForRemoteNotificationTypes:(UIRemoteNotificationType)types

这个函数向APNs(Apple Push Service)注册push,types可标明接收的push的类型,声音,数字等。

  • (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken;

当app成功注册通知后,会调用这个函数,并把deviceToken返回给应用。

然后我们的程序就会把返回的这个deviceToken以及设备的udid及软件版本(淘宝 for iPhone还是淘宝 for iPad)及系统版本,用户名等发送到我们的服务器(下图中的provider)上,然后存储在数据库里。整个获取device token的过程可参见下图所示:

 

在需要发送push时,我们的服务端就会取出要发送的设备的device token,然后以下图所示的结构,组成符合特定结构的字符串,然后将其发送到的APNs

APNs可以根据与APNs建立连接的Provider所使用的证书判断是要哪个app请求发送的notification,继而把这个notification发送到的设备上。

下图为一个简单的从Provider到Device发送push的过程:

device token到底是什么呢? 不同的app的device token相同么? 一个设备会产生多个device token么? 一个的device token可能对应多个UDID么?

结论:device token是对APNs来说,设备的标识符,与app无关,所以同一台设备上,不同的app获得的device token是一样的; 一个设备可能会产生多个device token, 一个device token也可能对应多个UDID,下面进行解释。

device token是什么?

文档中如下描述的:

对于APS来说,token是设备的标识符。device token不同于UIDevice的uniqueIdentifier(即UDID),因为出于安全和隐私原因,当设备被擦除后,token必须变化。

所以也就是说,一般情况下,token是不变的,但是在设备被擦除后,token会变的。

今天无心说在我们的服务器上的数据库里,存在同一个UDID对应有多个token的情况,之前是没有考虑到设备擦除的情况,所以就怀疑是不是同一个 设备上同时装了taobao4iphone和taobao4ipad,而token是与app关联的,所以产生的这种情况,于是就找了杨匡的ipad来做 测试,结果发现taobao4iphone和taobao4ipad收到的token是相同的,所以token应该是与app无关的,而是针对设备的(文 档上也是如此描述的),是设备的标识,那除了设备被擦除的情况外,设备的device token 应该是相同的,可是杨匡说之前崇厚给他查出来的他的iPad的token和我log出来的device token是不同的,后来就想到了,push是有两套的,development和product,即调试和release,在这两种情况下,服务端使用 的push证书是不一样的,而程序使用的证书也不一样,那同一个设备在development和distribution情况下收到的device token是否一样呢,于是就做了实验,实际结果如下

实验设备:iPad 1

可以看出,同一个设备在development和distribution情况下,收到的device token是不同的,而token是与app无关的。

综合文档及上述实验结果可以得到以下结果:

同一个udid对应有不同的device token的情况暂时有如下两种:

  1. 设备擦除过,token变化过,老的新的都存储在数据库里
  2. 设备同时装过development和distribution的程序

不知道还有没有其它原因造成的同一个设备有不同的device token的情况,大家如果有什么相关的经验,可以补充一下。

无心说数据库里也有同一个device token对应多个UDID的情况,这种情况就比较诡异了,按理说不应该的,比较APNs把token作为设备的标识的,如果同一个device token可以对应多个udid,那发push不是就会混乱了么,在网上查了相关资料,发现还真的有这种情况,参见

http://blog.csdn.net/sjzsp/article/details/6314896, 文章里写的很详细,下面把重点部分提出来,详情自己去看,呵呵

设备令牌是怎么生成的呢?是每次建立TLS连接时,APNS通过前一层次(TLS层)里我们提到的每台正常的iPhone唯一的设备证书(unique device certificate),并用令牌密钥(token key)加密生成的。

最重要的部分——每台iPhone独有的设备证书和密钥的来历

正常的iPhone刷系统之后,是没有设备证书和密钥的。这就是为什么iPhone会需要连接到iTunes上进行激活——激活过程中,Apple会分配给每台iPhone独一无二的设备证书(device certificate)和密钥(key) 。

iPhone OS 3.X 使用blacksn0w进行解锁 的过程,是不经过iTunes的,而blacksn0w本身又不生成对应的设备证书(device certificate)和密钥(key) ,因此这样解锁完的iPhone根本不可能与APNS建立任何的TLS链接,Push自然废了。

但当多个iPhone的设备证书(device certificate)完全一致时,就存在一定几率使得多个iPhone获得相同的设备令牌(device token)

要修补这个问题,唯一的办法就是重新生成唯一且有效的设备证书(device certificate)和密钥(key) 。于是,最早,dev team推出了一个测试版补丁,Push fix by dev team(通过他们的twitter发布的,因此官网没有消息)。这个补丁初期很有效。但是仅在iPhone 2G上比较正常。之后某人士发布pushfix 1.0了。由于使用了不同的生成方法,因此在新版本iPhone上也正常工作了。于是风靡一时。

然而,以上两个补丁都有严重的隐患——他们使用了一个固定的证书作为设备证书(device certificate)。因此在不同iPhone上的区别仅仅在于生成的密钥(key)不同。 (待确认)

而随着这两个补丁的使用人数不断增加,使得出现获得相同设备令牌(device token)的iPhone数量大大增加了。

当这些相同设备令牌(device token)的iPhone上启用了同一个应用程序的Push的时候,就极有可能出现彼此间的Push串发的现象。——如某论坛目前N多人抱怨QQ的Push到别人iPhone上的情况就是如此。

以上大概解释了同一个device token对应多个UDID的原因,

由于我们后续也会把与用户相关的信息push到用户的设备上,所以这个问题,我们也要考虑下应该怎么处理,否则也可能会出现,收到别人的物流的push。。。

另外,由于iOS5.0后,UIDevice中的uniqueIdentifier会逐步被废弃,所以,后面的版本中,我们会使用把设备的mac地 址md5计算后的结果做为设备的唯一标识,用其去代替UDID上传到我们的服务端上,但是无论是UDID还是mac地址的md5值,都只是作为设备的标 识,在发送push时,唯一需要与设备相关的信息就是device token,所以这个应该不影响我们的push。

使用 dns.v2ex 来加速 iTunes 下载。

国内用户访问iOS平台以及Mac系统App Store应用商店下载程序速度缓慢是由于苹果未在大陆地区设置iTunes下载服务器且域名默认解析至美国服务器,延时基本超过190毫秒。解决这种窘境的方法

使用第三方的DNS域名解析服务器。比如可是使用V2EX的DNS服务器 

 

 

如果你使用V2EX DNS后感觉不到效果,甚至上网出现问题。只需重复设置操作,把DNS清空即可。

 

也可以在更新完之后,恢复到原来的dns。

 

 

 

 

 

 

mac os lion 终端的编码问题。

warning: setlocale: LC_CTYPE: cannot change locale (UTF-8)

 

 

Problem: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8)

 

How to solve:

 

run following command in shell

export LC_ALL="en_US.UTF-8"

 

 

 

 

还可以

 

vim ~/.bash_profile

 

 

Microsoft 适用于 Mac 的远程桌面连接客户端 2.1.1

 适用于 Mac 的远程桌面连接客户端 2.1.1 允许您从自己的 Macintosh 计算机连接到一台基于 Windows 的计算机,或同时连接到多台基于 Windows 的计算机。连接之后,您就可以在基于 Windows 的计算机上使用应用程序和文件。

要了解适用于 Mac 的远程桌面连接客户端 2.1.1 的新功能,请访问 Microsoft 网站

  http://www.microsoft.com/downloads/zh-cn/details.aspx?familyid=68346e0d-44d3-4065-99bb-b664b27ee1f0&displaylang=zh-cn

防止 tunnelblick 每次自动启动。

 在 mac os x 下面每次tunnelblick都自动启动。

因为tunnelblick 都会插入一个自启动项。  

 

如果不想自动启动tunnelblick, 需要在关机,重启之前,退出tunnelblick

 

Automatically Starting Tunnelblick Upon Login

Tunnelblick was designed as a persistent menu icon that survives reboots. To this end, it inserts itself into the login items when it is started and only removes itself from the login items when you choose Quit from the menu or Command-Q from the "Details” window or "About…" window. So if you just log out, shut down, or restart your computer, or it crashes, the next time you log in, Tunnelblick will automatically start. If you do not want Tunnelblick to start automatically, quit Tunnelblick before you log out, shut down, or restart.

 

FROM:http://code.google.com/p/tunnelblick/wiki/zUsing#Automatically_Starting_Tunnelblick_Upon_Login