zz---话

男人要永远感谢在他20多岁的时候曾经陪在他身边的女人。
因为20多岁的男人处在一生中的最低点，没钱、没事业；
而20多岁的女人却是她最灿烂的时候。

女人要永远感谢在她20多岁的时候曾经陪在她身边的男人。
因为20多岁的男人处在一生中的最宝贵的时刻，一刻千金；
而20多岁的女人却是她最寂寞的时候。

珍惜在一起的时光，共同走过的路，互相扶持，谁都付出了所有。

java 常用属性

系统属性是指与用户程序相关的操作系统配置信息以及软件信息。通常与用户程序相关的属性关键字包括： 
●file.separator : 文件分隔符， Windows环境下为“\"，Unix环境下为“/”； 
●user.home ：用户主目录； 
●java.home ：Java实时运行环境的安装目录； 
●java.ext.dirs ：JDK的安装目录； 
●os.name ：操作系统名称； 
●user.name ：用户登录名称； 
●os.version ：操作系统版本； 
●path.separator ：当前操作系统的路径分隔符； 
●user.dir ：当前用户程序所在目录。

海盗分金币--zz

数学的逻辑有时会导致看来十分怪异的结论。一般的规则是，如果逻辑推理没有漏洞，那么结论就必定站得住脚，即使它与你的直觉矛盾。 1998年9月，加利福尼亚州帕洛阿尔托的Stephen M. Omohundro寄给我一道难题，它恰好就属于这一类。这难题已经流传了至少十年，但是Omohundro对它作了改动，使它的逻辑问题变得分外复杂了。 
    先来看看此难题原先的形状。10名海盗抢得了窖藏的100块金子，并打算瓜分这些战利品。这是一些讲民主的海盗（当然是他们自己特有的民主），他们的习惯是按下面的方式进行分配：最厉害的一名海盗提出分配方案，然后所有的海盗（包括提出方案者本人）就此方案进行表决。如果50%或更多的海盗赞同此方案，此方案就获得通过并据此分配战利品。否则提出方案的海盗将被扔到海里，然后下提名最厉害的海盗又重复上述过程。
    所有的海盗都乐于看到他们的一位同伙被扔进海里，不过，如果让他们选择的话，他们还是宁可得一笔现金。他们当然也不愿意自己被扔到海里。所有的海盗都是有理性的，而且知道其他的海盗也是有理性的。此外，没有两名海盗是同等厉害的――这些海盗按照完全由上到下的等级排好了座次，并且每个人都清楚自己和其他所有人的等级。这些金块不能再分，也不允许几名海盗共有金块，因为任何海盗都不相信他的同伙会遵守关于共享金块的安排。这是一伙每人都只为自己打算的海盗。最凶的一名海盗应当提出什么样的分配方案才能使他获得最多的金子呢？ 
    为方便起见，我们按照这些海盗的怯懦程度来给他们编号。最怯懦的海盗为1号海盗，次怯懦的海盗为2号海盗，如此类推。这样最厉害的海盗就应当得到最大的编号，而方案的提出就将倒过来从上至下地进行。 
    分析所有这类策略游戏的奥妙就在于应当从结尾出发倒推回去。游戏结束时，你容易知道何种决策有利而何种决策不利。确定了这一点后，你就可以把它用到倒数第2次决策上，如此类推。如果从游戏的开头出发进行分析，那是走不了多远的。其原因在于，所有的战略决策都是要确定：“如果我这样做，那么下一个人会怎样做？”
    因此在你以下海盗所做的决定对你来说是重要的，而在你之前的海盗所做的决定并不重要，因为你反正对这些决定也无能为力了。 
    记住了这一点，就可以知道我们的出发点应当是游戏进行到只剩两名海盗――即1号和2号――的时候。这时最厉害的海盗是2号，而他的最佳分配方案是一目了然的：100块金子全归他一人所有，1号海盗什么也得不到。由于他自己肯定为这个方案投赞成票，这样就占了总数的50%，因此方案获得通过。 
    现在加上3号海盗。1号海盗知道，如果3号的方案被否决，那么最后将只剩2个海盗，而1号将肯定一无所获――此外，3号也明白1号了解这一形势。因此，只要3号的分配方案给1号一点甜头使他不至于空手而归，那么不论3号提出什么样的分配方案，1号都将投赞成票。因此3号需要分出尽可能少的一点金子来贿赂1号海盗，这样就有了下面的分配方案： 3号海盗分得99块金子，2号海盗一无所获，1号海盗得1块金子。 
    4号海盗的策略也差不多。他需要有50%的支持票，因此同3号一样也需再找一人做同党。他可以给同党的最低贿赂是1块金子，而他可以用这块金子来收买2号海盗。因为如果4号被否决而3号得以通过，则2号将一文不名。因此，4号的分配方案应是：99块金子归自己，3号一块也得不到，2号得1块金子，1号也是一块也得不到。
    5号海盗的策略稍有不同。他需要收买另两名海盗，因此至少得用2块金子来贿赂，才能使自己的方案得到采纳。他的分配方案应该是：98块金子归自己，1块金子给3号，1块金子给1号。 
    这一分析过程可以照着上述思路继续进行下去。每个分配方案都是唯一确定的，它可以使提出该方案的海盗获得尽可能多的金子，同时又保证该方案肯定能通过。照这一模式进行下去，10号海盗提出的方案将是96块金子归他所有，其他编号为偶数的海盗各得1块金子，而编号为奇数的海盗则什么也得不到。这就解决了10名海盗的分配难题。
    Omohundro的贡献是他把这一问题扩大到有500名海盗的情形，即500名海盗瓜分100块金子。显然，类似的规律依然成立――至少是在一定范围内成立。事实上，前面所述的规律直到第200号海盗都成立。 200号海盗的方案将是：从1到199号的所有奇数号的海盗都将一无所获，而从2到198号的所有偶数号海盗将各得1块金子，剩下的1块金子归200号海盗自己所有。 
    乍看起来，这一论证方法到200号之后将不再适用了，因为201号拿不出更多的金子来收买其他海盗。但是即使分不到金子，201号至少还希望自己不会被扔进海里，因此他可以这样分配：给1到199号的所有奇数号海盗每人1块金子，自己一块也不要。
    202号海盗同样别无选择，只能一块金子都不要了――他必须把这100块金子全部用来收买100名海盗，而且这100名海盗还必须是那些按照201号方案将一无所获的人。由于这样的海盗有101名，因此202号的方案将不再是唯一的――贿赂方案有101种。
    203号海盗必须获得102张赞成票，但他显然没有足够的金子去收买101名同伙。因此，无论提出什么样的分配方案，他都注定会被扔到海里去喂鱼。不过，尽管203号命中注定死路一条，但并不是说他在游戏进程中不起任何作用。相反，204号现在知道，203号为了能保住性命，就必须避免由他自己来提出分配方案这么一种局面，所以无论204号海盗提出什么样的方案，203号都一定会投赞成票。这样204号海盗总算侥幸拣到一条命：他可以得到他自己的1票、203号的1票、以及另外100名收买的海盗的赞成票，刚好达到保命所需的50%。获得金子的海盗，必属于根据202号方案肯定将一无所获的那101名海盗之列。 
    205号海盗的命运又如何呢？他可没有这样走运了。他不能指望203号和204号支持他的方案，因为如果他们投票反对205号方案，就可以幸灾乐祸地看到205号被扔到海里去喂鱼，而他们自己的性命却仍然能够保全。这样，无论205号海盗提出什么方案都必死无疑。206号海盗也是如此――他肯定可以得到205号的支持，但这不足以救他一命。类似地，207号海盗需要104张赞成票――除了他收买的100张赞成票以及他自己的1张赞成票之外，他还需3张赞成票才能免于一死。他可以获得205号和206号的支持，但还差一张票却是无论如何也弄不到了，因此207号海盗的命运也是下海喂鱼。
    208号又时来运转了。他需要104张赞成票，而205、206、207号都会支持他，加上他自己一票及收买的100票，他得以过关保命。获得他贿赂的必属于那些根据204号方案肯定将一无所获的人（候选人包括2到200号中所有偶数号的海盗、以及201、203、204号）。 
    现在可以看出一条新的、此后将一直有效的规律：那些方案能过关的海盗（他们的分配方案全都是把金子用来收买100名同伙而自己一点都得不到）相隔的距离越来越远，而在他们之间的海盗则无论提什么样的方案都会被扔进海里――因此为了保命，他们必会投票支持比他们厉害的海盗提出的任何分配方案。得以避免葬身鱼腹的海盗包括201、202、204、208、216、232、264、328、456号，即其号码等于200加2的某一方幂的海盗。 
    现在我们来看看哪些海盗是获得贿赂的幸运儿。分配贿赂的方法是不唯一的，其中一种方法是让201号海盗把贿赂分给1到199号的所有奇数编号的海盗，让202号分给2到200号的所有偶数编号的海盗，然后是让204号贿赂奇数编号的海盗，208号贿赂偶数编号的海盗，如此类推，也就是轮流贿赂奇数编号和偶数编号的海盗。 
    结论是：当500名海盗运用最优策略来瓜分金子时，头44名海盗必死无疑，而456号海盗则给从1到199号中所有奇数编号的海盗每人分1块金子，问题就解决了。由于这些海盗所实行的那种民主制度，他们的事情就搞成了最厉害的一批海盗多半都是下海喂鱼，不过有时他们也会觉得自己很幸运――虽然分不到抢来的金子，但总可以免于一死。只有最怯懦的200名海盗有可能分得一份脏物，而他们之中又只有一半的人能真正得到一块金子，的确是怯懦者继承财富。

A brief history of Eclipse---zz

Gary Cernosek, Market Manager, IBM Software Group, IBM

15 Nov 2005

from The Rational Edge: In the late 1990s, IBM began development of what we now know as Eclipse. This article reviews the inception and growing acceptance of this popular computing platform, illustrating the role Eclipse plays in today's development tool arena.

In the late 1990s, IBM began development of what we now know as Eclipse. Today we see high adoption rates and evidence of successful application of this technology across the software industry. The purpose of this article is to review the inception of Eclipse, to illustrate the role it plays in today's development tools, and to convey how we see the technology evolving over time.

The development tool landscape of the mid-to-late 90s

In the mid-1990s, a number of powerful commercial development environments were available; Microsoft Visual Studio was becoming a more general-purpose tools platform. A number of Java-based IDEs were also coming into play, including Symantec's Visual Café, Borland's JBuilder, IBM's Visual Age for Java, and others.

This period also saw the emergence of application servers designed to decouple a client-side programmer from the many details found in the operating system and associated interfaces. For Java development, the marketplace offered us IBM's WebSphere Application Server, BEA's WebLogic, and Sun's iPlanet suite. From Microsoft, MTS and COM+ were the runtime environments in play at the time.

IBM's primary goals

This landscape actually contained two worlds: one centered on tools that enabled Microsoft's directions on runtime execution support, the other focused on a more open industry approach centered on the Java platform. Confident that a more open approach to IT was the best way to ensure its customer's long-term success, IBM saw Java development tooling as key to enabling growth in the open community. So its goal at the time was to bring developers closer to Java-based middleware.

We wanted to establish a common platform for all IBM development products to avoid duplicating the most common elements of infrastructure. This would allow customers using multiple tools built by different parts of IBM to have a more integrated experience as they switched from one tool to another. We envisioned the customer's complete development environment to be composed of a heterogeneous combination of tools from IBM, the customer's custom toolbox, and third-party tools. This heterogeneous, but compatible, tool environment was the inception of a software tools ecosystem.

Building the technology: The emerging role of open source

In November 1998, IBM Software Group began creating a development tools platform that eventually became known as Eclipse. We first built a new Java IDE with resources from our Object Technology International (OTI) labs, along with the broader platform to go with it. The OTI team had extensive experience building several generations of IDEs with small, highly skilled teams. At the same time, the larger IBM began setting up additional teams to create new products built on top of this platform.

We knew that a vibrant ecosystem of third parties would be critical for achieving broad adoption of Eclipse. But business partners were initially reluctant to invest in our (as yet unproven) platform. So in November 2001, we decided to adopt the open source licensing and operating model for this technology to increase exposure and accelerate adoption. IBM, along with eight other organizations, established the Eclipse consortium and eclipse.org. Initial members included (then-partners) Rational Software and TogetherSoft, as well as competitors WebGain and Borland. Membership in the consortium required only a bona fide (but non-enforced) commitment to Eclipse to use it internally, to promote it, and to ship a product based on it.

The consortium's operating principles assumed that the open source community would control the code and the commercial consortium would drive "marketing" and commercial relations. This was a new and interesting application of the open source model. It was still based on an open, free platform, but that base would be complemented by commercial companies encouraged to create for-profit tools built on top of it. Most of the committers and contributors to Eclipse came from a short list of the commercial vendors, with IBM being the largest contributor of both content and financial and staff resources.

But is it really open?

By 2003, the first major releases of Eclipse were well-received and were getting strong adoption by developers. But industry analysts told us that the marketplace perceived Eclipse as an IBM-controlled effort. Users were confused about what Eclipse really was. This perception left major vendors reluctant to make a strategic commitment to Eclipse while it was under IBM control. If we wanted to see more serious commitment from other vendors, Eclipse had to be perceived as more independent -- more decoupled from IBM.

So we began talking to others about how a more independent concern could take control of Eclipse so as to eliminate this perception. Working with these companies, we helped formulate and create the Eclipse Foundation. We then announced the new foundation, just in time for EclipseCon 2004, as a not-for-profit organization with its own independent, paid professional staff, supported by dues from member companies.

Results to date

The move has been a success. The new and independent Eclipse Foundation shipped Eclipse 3.0, and soon afterwards, Eclipse 3.1; both were received with even higher degrees of interest and adoption rates than the prior version. Soon afterwards, Eclipse 3.1 was released to resounding interest. We've seen dramatic growth in membership at all levels, and a deeper commitment by all independent tools vendors and most platform vendors. The Eclipse Foundation and its members made a number of announcements at EclipseCon 2005, including the emergence of powerful Eclipse projects such as Rich Client Platform, Web Tools Platform, Data Tools Platform, Business Intelligence Reporting Tool, and a dramatically reduced level of fragmentation in our efforts.

We've seen exciting levels of growth in Eclipse commitment and support. There are now twelve strategic developer member companies, each of whom commits at least eight full-time developers and up to $250,000 annually to the Eclipse foundation. The Eclipse Foundation also has four strategic consumers who also make a similar economic commitment. There are sixty-nine companies serving as add-in providers, and another thirteen associate member companies. If you peruse the software industry, you'll find hundreds of commercial plug-ins and products for Eclipse. Eclipse is now the industry's major non-Microsoft software tool platform.

IBM and Eclipse

In December 2004, IBM Rational aggressively revamped its product portfolio to move to a more Eclipse-based foundation. We referred to the result as the IBM Rational Software Development Platform, which includes new and improved products from IBM Rational, all built directly on top of the Eclipse platform, as illustrated in Figure 1. The platform also includes other lifecycle support tools that were already integrated with Eclipse.

Figure 1: As of December 2004, IBM Rational tools for the major roles in the software lifecycle are built on top of the Eclipse platform.

In this new platform, the developer role offerings extend the base Eclipse IDE with additional functionality to make developers more productive. We also created tools optimized for other practitioner roles throughout the application lifecycle, and, by leveraging the underlying mechanisms of Eclipse, we expanded the applicability of Eclipse across the lifecycle. Eclipse has become our next-generation tools integration platform.

A look into the future

IBM created Eclipse and is more committed to it now than ever. Eclipse is stable, mature, and independently managed. Most companies no longer view Eclipse as risky and, in fact, are comfortable starting with base Eclipse and adding support services and additional tools in an incremental fashion. We see commercial vendors evolving to support this shift, poised to offer more componentized versions of both value-added tooling and vendor support services. And as Eclipse and its associated plug-ins continue to grow, the Eclipse Foundation will be well-positioned to manage that growth and resulting complexity.

莫名其妙，突如其来的高烧

莫名其妙，突如其来的高烧。

在日语课上，突然觉得发冷，教室变得灰暗，眼皮很重很重，就这么压下来。然后高烧，然后口渴。在地大“网吧”等她的那十几分钟，感觉时间是如此漫长，不停的发抖，寒冷，零下4度。

喝了一杯热饮，没有味道，不过好多了。不忍让她担心，回来，天桥上的风，快要将我吹走。开始头晕，痛。药店的药30块钱，后来发现有效果的是那7毛钱的药。后悔当时买贵的药。头痛的只想快点好，贵也就买了。

闷睡，还是冷。

中间鲳鱼回来，又走了。因为这样发烧，也没有送他。不好意思，真的是招待不周。

继续睡，后来有转机，开始出汗了。整个寝室都是汗酸味。

想她在上体育课，不能打扰。想她快点过来。

给阿姨发了几条短信，嘱咐我一定要去医院看看。我说没事的，马上就会好得。

放心我没事的，我只是躺着就像起你了。就像远离家人的孩子，在头痛脑热的时候想起妈妈那样自然，记着的是被人照顾的温暖与舒心。无论将来我走多远，我都想就住在那个书房，那里给我家的感觉，而你就像妈妈，给我一切所需要的爱，照顾着我。在我人生性格形成的几年，开始有自己的人生观和价值观，你们影响着我去做一个乐观向上的人，而不像一般单亲家庭的孩子那样背负着太多的阴影与自卑。想起这些，都想流泪，这是永远都无法回报的。我只是想你了。

后来她过来了，给我带来吃的。我心情好很多。然后就渐渐的没有烧了。真的，烧得也快，退的也快。莫名其妙。虽然还是乏力，但是可以顽皮的做个男人了。哈哈。

早上洗完脸，弄了点香水，刚才她说好香，是不是洗澡了。我只是笑了。记得她说的，在病好的时候，弄一点香味，心情啊，身体啊，都会快点好起来的，于是就这样去做了。

随风潜入夜，润物细无声。

就这样被你影响着。

那座山和那个小水池

Shine bright morning light
now in the air the spring is coming。。。

听着尾浦由记的歌，忧伤而又缥缈，又是一个春天。

莫名地想起那片山，很久没有想起，也从来没有再踏进。不再悲伤，只有遗憾。

不知道你现在怎么样了？走的那天下着雨，忘了你是否有带伞。

我从来都不知道你为什么这么选择，我也无法知道。

只是现在回想起那天下午，我还知道你是用怎样的眼神，怎样的动作，帮我整理我的衣领。那是在城关中学破旧的台阶上。我一直都想不起你那天你和我说了什么。我很后悔，很懊恼，自己一直记不起。我只是很清楚的知道这是你和我说的最后的话。

你出事的时候，学校正在开运动会，连续三天。只是你没有出现。这其实都很正常。班很多人都和我一样，一点都没有感觉。其间有消息灵的女生在私下很神秘的讨论，被我知道。我很生气地说她们怎么可以这样不负责任的胡说八道。我那时候，从来都没有相信。你一直都笑着，我怎么也不会想到你会那样。后来我知道，一个人内心可以很脆弱，也可以很坚强。也知道一个人的内心可以掩盖得多么深。你办公室的那些同事也是惊讶。

你上课我从来都很仔细的听，因为你讲的好，偶尔还挺有趣。那年你刚评了“教坛新秀”，我记得你上课的时候提起过。还有，因为我叫你阿姨的，可是我都来不及告诉你。

后来我和几个朋友偶尔还去过那座山，带了鲜花。

在三门中学的时候，去过两次。一次很多人，一班二班都有。还有一次，就我和册砚。

现在人也不在三门了，回家的时间也不多了。好多人都出来了，各自忙着，我想这也是你希望看到的。

突然，想起你，问声好，祝老师。还有，你那年的暑假班，我没有去，是因为我要去上数学，呵呵，现在有点后悔哦。还有我以前日记都没有认真地写过，甚至还抄一下书。可你都原谅我了。

爱

爱既是肌肤相亲的缠绵，又是一粥一饭的平淡；既是心心相印的举案齐眉，又是疲惫生活的英雄幻想。
                                                             杜拉斯

what's time now?

Time is the motion of particles relative to each other. From a scientific perspective, without motion and without matter there is no time. If the material universe had a beginning, time as we know it began when the universe began. But science can postulate no such beginning.
So what't time now ? he:)

事

前几天下过小雪，于我南方人，感觉还是很好的。
要做毕业设计，确定题目。
元搜索或者爬虫，机器人。我想还是爬虫比较好。开题，上交。
准备拿人家的搜索结果，放到我们自己当中，偷袭？违法？不管了。
和她去吃了一条鲤鱼，红烧，慢，味道一般。
刚才聊天，中国队输了，其实和我无关。足球。