AnySQL.net

23:00 Chawp! – 切线 | 小众软件 > 游戏 (4308 Bytes) » 小众软件

Chawp! 是个动作游戏，目标是把 Boss 的各个组件的联系切断。一共有十个 Boss。如图，用左键划出一条线来切断各个组件直接的联系。

操作方式：

左键按住并拖拽 —— 放置锚点并拖出一条线
松开左键 —— 切之
右键 —— 变换线的颜色
Esc —— 退出
F4 —— 切换全屏或窗口模式

官方技巧：

拖拽出越长的线，杀伤力越低。
用同样颜色的线切敌人的话，杀伤力是其他颜色的两倍。
你只有 2 秒的机会进行一个连击。

下载(2.7 MB): skydrive | 官方网站 | 来自小众软件 | uushare

How long it may take MySQL with Innodb tables to shut down ? It can be quite a while.
In default configuration innodb_fast_shutdown=ON the main job Innodb has to do to complete shutdown is flushing dirty buffers. The number of dirty buffers in the buffer pool varies depending on innodb_max_dirty_pages_pct as well as workload and innodb_log_buffer_size and can be anywhere from 10 to 90% in the real life workloads. Innodb_buffer_pool_pages_dirty status will show you the actual data. Now the flush speed also depends on number of factors. First it is your storage configuration – you may be looking at less than 200 writes/sec for single entry level hard drive to tens of thousands of writes/sec for high end SSD card. Flushing can be done using multiple threads (in XtraDB and Innodb Plugin at least) so it scales well with multiple hard drives. The second important variable is your workload, especially how dirty pages would line up on the hard drive. If there are a lot of sequential pages which are dirty Innodb will be able to use larger size IOs – up to 1MB flushing dirty pages which can be a lot faster than flushing data page by page.

So if we have system with single hard drive doing 200 IO/ssc, 48G buffer pool which is 90% dirty and completely random page writes we’ll look at 13500 seconds or about 5min per 1GB of Buffer pool size.
This is worse case scenario though it is quite common in practice to see shutdown time of about 1min per GB of buffer pool per hard drive.

Baron has written a nice post how to decrease innodb shutdown time which you may want to read on this topic.

Entry posted by peter | 6 comments

Add to: | | | |

17:15 A Global Greeting (990 Bytes) » Inside AdSense

Members of the AdSense team from all over the world say hello from Mountain View, CA!

Posted by Katrina Kurnit - Inside AdSense Team

14:26 Distributed Hashing Algorithms by Example: Consistent Hashing (826 Bytes) » High Scalability

Consistent Hashing is a specific implementation of hashing that is well suited for many of today’s web-scale load balancing problems. Specifically, it can be seen in use in various caching solutions like Memcached and is applicable to NoSQL solutions as well. Consistent Hashing is used particularly because it provides a solution for the typical “hashcode mod n” method of distributing keys across a series of servers. It does this by allowing servers to be added or removed without significantly upsetting the distribution of keys, nor does it require that all keys be rehashed to accommodate the change in the number of servers.

You can read the full store here.

12:15 backtrace-mingw 更新 (394 Bytes) » 云风的 BLOG

backtrace-mingw 今天更新了一下。原来的版本不能正确显示 dll 里的符号信息。现在可以了。只是打了个补丁，所以代码比较乱。

不知道 backtrace-mingw 的同学，可以看这里。

09:08 给某些自信到爆的粉丝 (6645 Bytes) » 槽边往事

我的《HTC HERO苦难史》发布之后，在网络上引起了很多反馈。从Twitter、Google Buzz以及我的三个Blog的留言进行分析，反馈分为以下几类：

1、难兄难弟型---通过这篇Blog，我找到了许多对HTC HERO的不便感通身受的难友。相类似的经历，使得大家具有共同话题，从而降低了各自的心理负担，不再因为怀疑自己有“人品问题”而觉得愧疚。

2、人品爆发型---也有相当数量的HTC HERO使用者宣称自己不曾遇到任何问题，这款产品用起来得心应手。通过亲历的方式，间接反驳了我的Blog。并表示会继续使用下去，和HTC一直到天荒地老。

3、自信粉丝型---这一型人牛逼轰轰、居高临下地教育我。告诉我说：不会刷机就别他妈用HTC HERO。或者：连后台关闭进程都不会，你还是用NOKIA吧！他们觉得我只所以遇见那么多问题，主要原因在我自身，而非产品。

这里，我要对最后一类自信到爆的粉丝多说几句：

对于我这样的用户来说，刷机从来不是个问题。我的iPhone是自己刷的，我的HTC HERO第一次刷机也是我亲手做的。我不认为刷机有多难，真正的难点在于：我凭什么要刷机？我凭什么要花费那么多时间去下载？去跟踪某个版本的进展？

手机在我看来就是一种电器，如果我的电视机、冰箱、洗衣机不需要刷机，我凭什么要刷手机？所以，从09年开始起，我拒绝自己刷机，宁可花钱让别人刷。因为我的时间，我的精力，还要花在别的事情上。同时，我认为一台电器入手，厂方就要保证它能够良好运作，否则就是残次品。刷机那是工程师在出厂前就应该做好的事情，而不是让消费者买回家后替厂方做工。我花了4200块钱买这台手机，还要贴自己的时间去刷机，做厂商原本应该做好的事情，HTC发我工资么？

我不知道拥有一点点技能居然可以让一个人自信心爆棚到这个程度。在后台KILL一下进程，都会让人得意地上升到“知道不知道”的层面。OK，我不知道Kill进程。不过，我当年用WM系统的HP的时候，好像是可以直接杀进程的。让我想想，好像安卓电子市场里很早就有一个中国人开发的杀进程APP，结果因为版权问题被投诉，被迫下架，所以才有后来那个貌似很专业很流行的APP。嗯，那个哥们的Blog写得很好。你知道杀进程的APP，我不同，我还知道杀进程APP他爹。

OK，这些屁话就不用再哈拉了。上面的几小段话里，已经有太多缩写，太多专业名词。接下来，让我用浅白的中文说说我的想法：

任何时代里，都有孙子不甘于做普通人。因此，他们总要找到点区别于普通人的特质。当年买砖头大哥大的是这样的人，今天要过低碳环保走路健身的也是这样的人。形式多种多样，但是内核是一致的。我认为：以是否会刷机作为这种特质，并且以此认定别人不刷机是技术或者智力问题，那就有点傻逼到类似尤物的境界了。

为什么说是傻逼？第一，无论是塞班、安卓还是苹果手机系统的刷机固件，都不是老几位你们写的。不是么？你们不过是在论坛里泡着，一遍遍F5着，等到别人放出来，老几位立即下载，安装，然后第一时间跟帖，写测评。你瞧，我的Blog起码是我原创的。所以，我写完《HTC HERO苦难史》之后，你们做的也依然是跟帖，点评。知道么？有的人永远是拉屎的，有更多人永远是吃屎的。吃屎的要和拉屎的牛逼，不怕断了自己的饭食，那不是傻逼还能是什么？

第二、为了维持这一点点小小虚荣，为了自己可以在所谓“技术盲”、“文科生”面前的小小优越感，不惜一次次呛声任何敢于反对的人。喂，这么做的意义何在？我可以不批评，没问题的。我甚至可以幡然悔悟，加入赞美的大合唱，也去攻击任何小白用户。结果是什么？结果是烂产品依旧那么生产出来了，因为起码市场反响很好，看似所有用户都会刷机。而真正的用户面对这种产品的时候，心存畏惧，根本不去掏钱购买，他们才不会写什么Blog呢。最终智能机就是一个小众市场，各位也就别想着什么3G资费下降，带宽提升。爱刷机，那就永远刷下去，就那么点人慢慢玩吧。使用智能机，是为了更为强大的功能，有朝一日能够在手机平台上完成以前许多做不到的事情。那么，断绝或者延缓这种可能的到来，同时掏高价买机器，花时间刷机器，这不是傻逼还能是什么？

最后，所有大众消费的产品，都应该越来越简单，越来越人性化。所以，才会有万用遥控器的出现，才会有触摸屏而不是键盘的技术革新。所以，那么多手机商生产了那么多年手机，iPhone却依然可以后来居上。迷恋复杂，迷恋门槛，那是很私人的事情。但是，这不是大众需要的东西。大众不需要一个180个键钮控制的马桶，也玩不转一个需要10个步骤才能启动的音响，更不需要一个复杂如飞机驾驶舱的的手机键盘。如此，生活对于人们来说，才可以人人直接享受，而无需专门训练。如果一个不牛逼的人，也能很快上手一台智能手机，无需自行维护，那才是智能手机的未来。而偏偏有人要反对这种需求，像中世纪僧侣维护对《圣经》的诠释权一样，维护着那点可怜可悲的所谓“刷机知识”，这不是傻逼还能是什么？

手机作为一种产品，是给人用的。不是给小众用的，而是给大众用的。当你给父母买KJAVA、MDK、塞班手机的时候，有没有想过，凭什么他们不能用上智能手机？是什么阻碍了他们使用新技术？你自己是不是这阻碍的一部分？

阿门！

+++++++这是一条分割线++++++++

摄影：方加玮
鲜花总会长出来，不在墙这边相见，就在墙外面思念。请使用E-mail订阅《槽边往事》：订阅地址

03:52 Oracle 11g默认用户密码增强-default_pwd$ (11671 Bytes) » Oracle Life

作者：eygle 发布在 eygle.com

昨天看到老杨写的 11g新增默认用户密码监测，也顺便看了一下这个新特性。

Oracle 11g中增加了一个新的视图DBA_USERS_WITH_DEFPWD用于显示那些具有缺省口令的用户：

SQL> desc DBA_USERS_WITH_DEFPWD
名称是否为空? 类型
----------------------------------------- -------- ----------------------------
USERNAME NOT NULL VARCHAR2(30)
SQL> select * from dba_users_with_defpwd;

USERNAME
------------------------------
DIP
MDSYS
XS$NULL
SPATIAL_WFS_ADMIN_USR
OUTLN
OLAPSYS
SPATIAL_CSW_ADMIN_USR
OWBSYS
ORACLE_OCM
EXFSYS
SCOTT
DBSNMP
ORDSYS
ORDPLUGINS
MDDATA
APPQOSSYS
ORDDATA
XDB
WMSYS
SI_INFORMTN_SCHEMA

已选择20行。

这里显示的20个用户，其账户都是锁定的，所以大可不必担心。

如果进一步的研究一下，这个视图的底层表是DEFAULT_PWD$：

SQL> set autotrace trace explain
SQL> select * from dba_users_with_defpwd;

执行计划
----------------------------------------------------------
Plan hash value: 180429094

---------------------------------------------------------------------------------------------------------
| Id | Operation                       | Name                  | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                       |     6 |   102 |    10 (10)| 00:00:01 |
|   1 | VIEW                           | DBA_USERS_WITH_DEFPWD |     6 |   102 |    10 (10)| 00:00:01 |
|   2 |   HASH UNIQUE                   |                       |     6 |   312 |    10 (10)| 00:00:01 |
|   3 |    CONCATENATION                |                       |       |       |            |       |
|   4 |     NESTED LOOPS                |                       |       |       |            |       |
|   5 |      NESTED LOOPS               |                       |     2 |   104 |     4   (0)| 00:00:01 |
|* 6 |       TABLE ACCESS FULL         | USER$                 |     2 |    54 |     2   (0)| 00:00:01 |
|* 7 |       INDEX UNIQUE SCAN         | I_DEFAULT_PWD         |     1 |       |     0   (0)| 00:00:01 |
|* 8 |      TABLE ACCESS BY INDEX ROWID| DEFAULT_PWD$          |     1 |    25 |     1   (0)| 00:00:01 |
|   9 |     NESTED LOOPS                |                       |    50 | 2600 |     5   (0)| 00:00:01 |
|* 10 |      TABLE ACCESS FULL          | USER$                 |     1 |    27 |     2   (0)| 00:00:01 |
|* 11 |      TABLE ACCESS FULL          | DEFAULT_PWD$          |   775 | 19375 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   6 - filter("U"."PASSWORD" IS NOT NULL AND "U"."TYPE#"=1)
   7 - access("U"."NAME"="DP"."USER_NAME" AND "U"."PASSWORD"="DP"."PWD_VERIFIER")
   8 - filter("DP"."PV_TYPE"=0)
10 - filter("U"."TYPE#"=1 AND BITAND("U"."ASTATUS",16)=16)
11 - filter(LNNVL("U"."PASSWORD"="DP"."PWD_VERIFIER") OR LNNVL("U"."NAME"="DP"."USER_NAME") OR
              LNNVL("DP"."PV_TYPE"=0) OR LNNVL("U"."PASSWORD" IS NOT NULL))

这个新的底层表记录了缺省用户的缺省口令：

SQL> desc default_pwd$
名称                                      是否为空? 类型
----------------------------------------- -------- ----------------
USER_NAME                                          VARCHAR2(128)
PWD_VERIFIER                                       VARCHAR2(512)
PV_TYPE                                            NUMBER
SQL> select * from default_pwd$ where user_name='SCOTT';

USER_NAME PWD_VERIFIER                      PV_TYPE
---------- ------------------------------ ----------
SCOTT      F894844C34402B67                        0

有了这个表之后，视图通过 u.password = dp.pwd_verifier比对就可以发现那些缺省口令了：

SQL> select text from dba_views where view_name='DBA_USERS_WITH_DEFPWD';

TEXT
-----------------------------------------------------------------------------
SELECT DISTINCT u.name
    FROM SYS.user$ u, SYS.default_pwd$ dp
   WHERE
     (u.type# = 1
      AND bitand(u.astatus, 16) = 16
     ) OR
     (u.type#    = 1
     AND u.password = dp.pwd_verifier
     AND u.name     = dp.user_name
     AND dp.pv_type = 0)

这个关于缺省口令的改进告知我们：缺省口令是极其危险的！

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2010/09/oracle_11g_default_pwd.html

20:45 Scale-out vs Scale-up (478 Bytes) » High Scalability

In this post I'll cover the difference between multi-core concurrency that is often referred to as Scale-Up and distributed computing that is often referred to as Scale-Out mode.

more..

17:40 Paper: The Case for Determinism in Database Systems (838 Bytes) » High Scalability

Can you have your ACID cake and eat your distributed database too? Yes explains Daniel Abadi, Assistant Professor of Computer Science at Yale University, in an epic post, The problems with ACID, and how to fix them without going NoSQL, coauthored with Alexander Thomson, on their paper The Case for Determinism in Database Systems. We've already seen VoltDB offer the best of both worlds, this sounds like a completely different approach.

The solution, they propose, is:

16:35 HTC Home for Windows – HTC 样式时间天气 | 小众软件 > 桌面工具 (5163 Bytes) » 小众软件