兴趣爱好 今日: 0|主题: 1874|排名: 47 

最后发表： xblues
回复内容：
你是说死亡么？不要惧怕，饲料饲料，一丝白了。

最后发表： cello
回复内容：
啊，那个是日文的网站呀？不懂的说

最后发表： xblues
回复内容：
同文。用过的介绍一下感受。

最后发表： coredump
回复内容：
maybe

最后发表： 土豆
回复内容：
I'm so so so sorry!

最后发表： 悠悠
回复内容：
LSs all professinal

最后发表： houliang
回复内容：
是大连的星海公园，前两天刚去过，不过没有发现有这么干净啊？

最后发表： xblues
回复内容：
如果以此为标准，那中国还有广告可以播放么？


驱动之家[原创] 作者：Skyangeles 编辑：Skyangeles　2008-08-28 11:39:38 5492 人阅读 [投递]

由于收到两起指责iPhone广告误导消费者的投诉，英国广告标准管理局（ASA）日前禁止了一则苹果iPhone广告在英国播出。

这则广告展示了iPhone的各种网络功能，内容假想一个要到南非旅游的用户，首先查看开普敦天气，随后用Google Map指出到伦敦希思罗机场的路线，接着到浏览器查看当地旅馆海景房图片，最后在查阅股票行情看自己是否负担得起这次旅行。最终，画外音总结：“这就是为什么我们把互联网的所有部分都放在iPhone里的原因。”

但正是这则广告，让两位英国消费者投诉：iPhone并不支持Flash和Java，因此无法正常使用许多网站，宣称iPhone支持互联网所有功能显然有误导消费者之嫌。在该广告上线前，当地审查部门在广告商进行现场演示并作出保证后开出了绿灯。但现在ASA认为，该广告让用户认为iPhone可以访问所有网站并完整显示，因此以“误导消费者对iPhone互联网功能印象”的原因将该广告禁播。

苹果对此的解释是，该广告的目的是演示iPhone对所有网站的访问能力，而不像许多手机一样仅能访问WAP网站。iPhone中的Safari浏览器实在开放互联网标准的基础上构建的，Flash和Java并非开源标准，因此他们并不能保证支持“市场上的所有第三方技术”。广告中的所有内容都不是基于Flash或Java，“互联网的所有部分”指的是网站可访问，并不是“所有功能”。

http://www.youtube.com/v/OfxNITMt1l4

最后发表： xblues
回复内容：
这个我也想要！



驱动之家[原创] 作者：Alright 编辑：Alright　2008-08-28 15:05:36 2904 人阅读 [投递]

根据罗技官方消息，罗技Squeezebox™Boom多合一网络音乐播放器产品已经上市，该产品集成放大器，扬声器安装并不复杂。

据罗技介绍，网络音乐播放器产品将成为21世纪的CD播放机。此产品的特色在于用户可以在卧室、厨房或其他房间收听数字音乐，而无需额外网线连接。只要家中拥有无线网络，那么你就可以从PC机上播放流媒体音频。即便电脑关闭的状态，用户仍然可以从互联网电台获取音乐内容。

Squeezebox Boom拥有802.11g网络支持，据称可以支持数以千计的互联网电台。除了互联网电台，该机型还可以作为闹钟使用，通过预制按钮，用户可存储6个Internet广播电台，在需要的时候进行播放。

另外，Squeezebox背部包括一个微型磁体，在厨房用餐的时候，你甚至可以把它贴在冰箱上。罗技表示，这种网络音乐播放器将从9月份开始销售，建议零售价299.99美元。

最后发表： langchu
回复内容：
很可惜。。。偶还没能去澳洲。。。。

最后发表： coredump
回复内容：
FROM: http://weblogs.mozillazine.org/roadmap/archives/2008/08/tracemonkey_javascript_lightsp.html

TraceMonkey: JavaScript LightspeedI'm extremely pleased to announce the launch of TraceMonkey, an evolution of Firefox's SpiderMonkey JavaScript engine for Firefox 3.1 that uses a new kind of Just-In-Time (JIT) compiler to boost JS performance by an order of magnitude or more.

TraceMonkey是Firefox SpiderMonkey (Firefox现在的Javascript执行引擎)的革新版本，将在Firefox3.1中出现在大家面前。 这个版本的Javascript引擎将像JVM一样通过引入JIT技术来提升Javascript的性能。

ResultsLet's cut straight to the charts. Here are the popular SunSpider macro- and micro-benchmarks average scores, plus results for an image manipulation benchmark and a test using the Sylvester 3D JS library's matrix multiplication methods:
测试结果让人非常惊喜啊，各个方面都有显著的性能提升，看来以后用gamil能更快了！
Here are some select SunSpider micro-benchmarks, to show some near-term upper bounds on performance: This chart shows speedup ratios over the SpiderMonkey interpreter, which is why "empty loop with globals" (a loop using global loop control and accumulator variables) shows a greater speedup -- global variables in JavaScript, especially if undeclared by var, can be harder to optimize in an interpreter than local variables in a function. Here are the fastest test-by-test SunSpider results, sorted from greatest speedup to least: The lesser speedups need their own chart, or they would be dwarfed by the above results: (Any slowdown is a bug we will fix; we're in hot pursuit of the one biting binary-trees, which is heavily recursive -- it will be fixed.) With SunSpider, some of the longest-running tests are string and regular-expression monsters, and since like most JS engines, we use native (compiled C++) code for most of the work, there's not as much speedup. Amdahl's Law predicts that this will bound the weighted-average total Sunspider score, probably to around 2. No matter how fast we JIT the rest of the code, the total score will be... 2. But this is only a start. With tracing, performance will keep going up. We have easy small linear speedup tasks remaining (better register allocation, spill reduction around built-in calls). We will trace string and regular expression code and break through the "2" barrier. We will even trace into DOM methods. The tracing JIT approach scales as you move more code into JS, or otherwise into view of the tracing machinery. Finally, schrep created a screencast (UPDATE: link fixed) that visually demonstrates the speedup gained by TraceMonkey. These speedups are not just for micro-benchmarks. You can see and feel them. How We Did ItWe've been working with Andreas Gal of UC Irvine on TraceMonkey, and it has been a blast. We started a little over sixty days (and nights ;-) ago, and just yesterday, shaver pushed the results of our work into the mozilla-central Hg repository for inclusion in Firefox 3.1. The JIT is currently pref'ed off, but you can enable it via about:config -- just search for "jit" and, if you are willing to report any bugs you find, toggle the javascript.options.jit.content preference (there's a jit.chrome pref too, for the truly adventurous).
Before TraceMonkey, for Firefox 3, we made serious performance improvements to SpiderMonkey, both to its Array code and to its interpreter. The interpreter speedups entailed two major pieces of work:

• Making bytecode cases in the threaded interpreter even fatter, so the fast cases can stay in the interpreter function.
• Adding a polymorphic property cache, for addressing properties found in prototype and scope objects quickly, without having to look in each object along the chain.

I will talk about the property cache and the "shape inference" it is based on in another post.
By the way, we are not letting moss grow under our interpreter's feet. Dave Mandelin is working on a combination of inline-threading and call-threading that will take interpreter performance up another notch. While doing this Firefox 3 work, I was reminded again of the adage:

Neurosis is doing the same thing over and over again, expecting to get a different result each time.

But this is exactly what dynamically typed language interpreters must do. Consider the + operator:
a = b + c;Is this string concatenation, or number addition? Without static analysis (generally too costly), we can't know ahead of time. For SpiderMonkey, we have to ask further: if number, can we keep the operands and result in machine integers of some kind?
Any interpreter will have to cope with unlikely (but allowed) overflow from int to double precision binary floating point, or even change of variable type from number to string. But this is neurotic, because for the vast majority of JS code, in spite of the freedom to mutate type of variable, types are stable. (This stability holds for other dynamic languages including Python.) Another insight, which is key to the tracing JIT approach: if you are spending much time in JS, you are probably looping. There's simply not enough straight line code in Firefox's JS, or in a web app, to take that much runtime. Native code may go out to lunch, of course, but if you are spending time in JS, you're either looping or doing recursion. The Trace Trees approach to tracing JIT compilation that Andreas pioneered can handle loops and recursion. Everything starts in the interpreter, when TraceMonkey notices a hot loop by keeping cheap count of how often a particular backward jump (or any backward jump) has happened. for (var i = 0; i < BIG; i++) {    // Loop header starts here:    if (usuallyTrue())        commonPath();    else        uncommonPath();}Once a hot loop has been detected, TraceMonkey starts recording a trace. We use the Tamarin Tracing Nanojit to generate low-level intermediate representation instructions specialized from the SpiderMonkey bytecodes, their immediate and incoming stack operands, and the property cache "hit" case fast-lookup information. The trace recorder completes when the loop header (see the comment in the code above) is reached by a backward jump. If the trace does not complete this way, the recorder aborts and the interpreter resumes without recording traces. Let's suppose the usuallyTrue() function returns true (it could return any truthy, e.g. 1 or "non-empty" -- we can cope). The trace recorder emits a special guard instruction to check that the truthy condition matches, allowing native machine-code trace execution to continue if so. If the condition does not match, the guard exits (so-called "side-exits") the trace, returning to the interpreter at the exact point in the bytecode where the guard was recorded, with all the necessary interpreter state restored. If the interpreter sees usuallyTrue() return true, then the commonPath(); case will be traced. After that function has been traced comes the loop update part i++ (which might or might not stay in SpiderMonkey's integer representation depending on the value of BIG -- again we guard). Finally, the condition i < BIG will be recorded as a guard. // Loop header starts here:inlined usuallyTrue() call, with guardsguard on truthy return valueguard that the function being invoked at this point is commonPathinlined commonPath() call, with any calls it makes inlined, guardedi++ code, with overflow to double guardi < BIG condition and loop-edge guardjump back to loop headerThus tracing is all about speculating that what the interpreter sees is what will happen next time -- that the virtual machine can stop being neurotic. And as you can see, tracing JITs can inline method calls easily -- just record the interpreter as it follows a JSOP_CALL instruction into an interpreted function. One point about Trace Trees (as opposed to less structured kinds of tracing): you get function inlining without having to build interpreter frames at all, because the trace recording must reach the loop header in the outer function in order to complete. Therefore, so long as the JITted code stays "on trace", no interpreter frames need to be built. If the commonPath function itself contains a guard that side-exits at runtime, then (and only then) will one or more interpreter frames need to be reconstructed. Let's say after some number of iterations, the loop shown above side-exits at the guard for usuallyTrue() because that function returns a falsy value. We abort correctly back to the interpreter, but keep recording in case we can complete another trace back to the same loop header, and extend the first into a trace tree. This allows us to handle different paths through the control flow graph (including inlined functions) under a hot loop. What It All MeansPulling back from the details, a few points deserve to be called out:

• We have, right now, x86, x86-64, and ARM support in TraceMonkey. This means we are ready for mobile and desktop target platforms out of the box.
• As the performance keeps going up, people will write and transport code that was "too slow" to run in the browser as JS. This means the web can accomodate workloads that right now require a proprietary plugin.
• As we trace more of the DOM and our other native code, we increase the memory-safe codebase that must be trusted not to have an exploitable bug.
• Tracing follows only the hot paths, and builds a trace-tree cache. Cold code never gets traced or JITted, avoiding the memory bloat that whole-method JITs incur. Tracing is mobile-friendly.
• JS-driven <canvas> rendering, with toolkits, scene graphs, game logic, etc. all in JS, are one wave of the future that is about to crest.

TraceMonkey advances us toward the Mozilla 2 future where even more Firefox code is written in JS. Firefox gets faster and safer as this process unfolds.
I believe that other browsers will follow our lead and take JS performance through current interpreter speed barriers, using just-in-time native code compilation. Beyond what TraceMonkey means for Firefox and other Mozilla projects, it heralds the JavaScript Lightspeed future we've all been anticipating. We are moving the goal posts and changing the game, for the benefit of all web developers. AcknowledgmentsI would like to thank Michael Franz and the rest of his group at UC Irvine, especially Michael Bebenita, Mason Chang, and Gregor Wagner; also the National Science Foundation for supporting Andreas Gal's thesis. I'm also grateful to Ed Smith and the Tamarin Tracing team at Adobe for the TT Nanojit, which was a huge boost to developing TraceMonkey.
And of course, mad props and late night thanks to Team TraceMonkey: Andreas, Shaver, David Anderson, with valuable assists from Bob Clary, Rob Sayre, Blake Kaplan, Boris Zbarsky, and Vladimir Vukićević.

最后发表： 唐男唐种
回复内容：
嘿嘿，那种生态环境有几个能活到60岁呢

最后发表： atelier
回复内容：
18+73 目前来说可以了，上面还有3个空着的bay，如果觉得有需要，上ebay淘几个hot swap的scsi硬盘。

这台服务器$161.5， 墨尔本自取。呵呵

最后发表： kingsking
回复内容：



哦,加油了...

最后发表： duke2
回复内容：
我的UB暂时还没有出现国这个问题。

最后发表： ubuntuhk
回复内容：
你原来用的是什么数据库?

最后发表： media000
回复内容：



你需要系统的安装盘来reinstall it.

最后发表： lilianaya
回复内容：
对这样的网站，缓存、搜索、分布是最关键的。不知道是怎么个架构。

最后发表： kingsking
回复内容：
哦,这样啊,我还以为对 他是推荐  大教堂的呢..

因为教堂比市集好多了,重要多了,长久多了..

事实恰恰相反,,,windows老坏, linux却少坏.

也许我比的就不对,应该用unix和linux比.

unix也是闭源的吧?哪能个更稳定一些呢?

最后发表： nicole_zjy
回复内容：
都很美啊！
第5张 夕阳孤帆 第一眼看上去怎么那么像青岛呢？

最后发表： niuzefeng
回复内容：
惭愧，我从来没有集中精力关注过任何一门编程语言。硬件发展作为编程语言C++也随之发展，好事情。感谢coredump所作的介绍。呵呵，楼上的兄弟应该不是理想问题而是金钱问题。

最后发表： xblues
回复内容：
这个patch的功能，主要是定制界面，去掉那些不想要的地方，我用来去掉广告和收费信息。

最后发表： xblues
回复内容：
今天回来，吧SQL Express 2005卸载了。
这样安装，就不是兼容安装了，因为原来SQL Express 2005装的是32位的。
可是提示错误说：我有什么Visual Studio 2008 SP1的兼容性问题。

没办法，我又重新把Visual Studio 2008 SP1覆盖安装了一下。
再安装SQL Express 2008顺利通过！

先去上班，因为安装这个已经迟到了！
回来试验，报告回头补。

最后发表： coredump
回复内容：
我的Tunner不接墙上的天线的话也只能收SBS，接上墙上的天线能收到7,9,ABC等6个台，但是却收不到SBS了。

最后发表： langchu
回复内容：
无语了。。。。。。。。

最后发表： maaboo
回复内容：
最近一直没接着玩ME.
没时间。前段时间FF, 这两天在看24小时，另外还在玩英雄传说6, 还想玩MGS4(买来之后还没玩呢)……

等签时间都用在游戏上了。

最后发表： canberraharbour
回复内容：
ADSL2 Plus兼容ADSL 1，要买就买ADSL2 Plus的，别买ADSL1，要淘汰了。

最后发表： langchu
回复内容：
看看现在的韩国人，可以理解这种行为。。。。

最后发表： xblues
回复内容：
这个是我的必用软件之一。主要是清除系统垃圾（不用的文件，临时文件，清理注册表），完全安全。我一直用！

http://www.filehippo.com/download_ccleaner/

CCleaner (formerly Crap Cleaner) is a freeware system optimization and privacy tool. It removes unused and temporary files from your system - allowing Windows to run faster, more efficiently and giving you more hard disk space. The best part is that it's fast! (normally taking less than a second to run) and Free.

Cleans the following:

    * Internet Explorer Cache, History, Cookies, Index.dat.
    * Recycle Bin, Temporary files and Log files.
    * Recently opened URLs and files.
    * Third-party application temp files and recent file lists (MRUs).
      Including: Firefox, Opera, Media Player, eMule, Kazaa, Google Toolbar, Netscape, Office XP, Nero, Adobe Acrobat, WinRAR, WinAce, WinZip and more...
    * Advanced Registry scanner and cleaner to remove unused and old entries.
      Including File Extensions, ActiveX Controls, ClassIDs, ProgIDs, Uninstallers, Shared DLLs, Fonts, Help Files, Application Paths, Icons, Invalid Shortcuts and more... Backup for registry clean.
    * Windows Startup tool.

If you like and use this software then it is polite to make a donation to the author.

最后发表： kyu
回复内容：
~~~~~`

最后发表： akai
回复内容：
U版，你的OSD出来了吗。
我现在T60+Hardy但 FN+F5以及声音 brightness等OSD和win下的不一样
我已经装了tpb了。 不知道你的情况如何。
我在 RHEL Client 下 osd是正常的。

最后发表： maggie2007
回复内容：
拍得不错呀

最后发表： akai
回复内容：
问你问题的人也是傻子。
1。lvs
2. 后端server
如果用动态 后面还要有
3. 后端数据库
所以他说的瘫是 lvs瘫痪 or 后端server瘫痪 or后端数据库瘫痪？
如果是3的话 可能几个并发就把数据库搞瘫痪了如果sql写的很滥。 我遇到过 10个并发把我们数据库搞瘫痪的。

纯粹静态的境况下。
曾经有用一台alteon 2424 做到60万的session 还没有到alteon cpu瓶颈的地步 但带宽满了1G 后面是20台 IIS 静态页面. iis上显示的session每台2万多（apache 当时的j这方面地确比不上iis）.

对于http 并发是个很模糊的概念。
我所说的session是 指 已经establish的connection. 当时的带宽 已经是下行 1G了 平线。并发到底多少呢 只能用log分析了。可惜当时的log 分析我从来也不看。。。。但我想几万并发是肯定有的。

最后发表： akai
回复内容：
哥们是备份的吧。

最后发表： kaka999
回复内容：
为了部落。...

最后发表： coredump
回复内容：
FROM:http://software.solidot.org/software/08/08/23/035221.shtml

35公里 写道 "本年度的Firefox 3 扩展插件大赛已经揭晓，获奖者包括全新扩展和已有扩展的升级。以下为获奖扩展名单： 最佳新扩展：
Pencil(作者： Dương Thành An )——Pencil 将 Firefox 3 扩展成一个开源的示意图绘制工具。Pencil 使用 Firefox 所支持的 SVG 功能，用来编写 SVG 脚本并输出图形。
Tagmarks （作者： Felipe Tassario Gomes）——该扩展在 Firefox 书签处添加了几个新按纽，你可以快速地为你的书签添加 Tag。
HandyTag （作者： Rémi Szymkowiak)——HandyTag 提供了一套完整的关键词，你可以在书签编辑界面中直接取用。

最佳扩展升级Read it Later (作者：Nate Weiner）——Read It Later 允许你将当前网页保存下来以后再读，和书签不同的是，这个功能适合于那些临时感兴趣的网页。
TagSifter （作者：Chiisai Tsu）——Firefox 3 允许你对书签做 Tag，但没有提供很好的功能让你根据 Tag 浏览书签，这个扩展允许你选择一组 Tag，然后将相应 Tag 下的书签显示出来。
Bookmark Previews by John Marshall——这个扩展为书签添加预览图，将鼠标放到书签上，就会显示其预览图。

最佳音乐扩展Fire.fm （作者：Jorge Villalobos and Jose Enrique Bolaños）——该扩展允许你从 Last.fm 访问大量音乐资源，根据你的口味。

最后发表： 木头瓶子
回复内容：
第一张！第一张太赞了！

最后发表： zlsiva
回复内容：
还有一个问题，结局卡是怎么抽的？什么时候抽？
每人只有1张结局卡？或者手头的结局卡只要有一张完成就胜利？

最后发表： coredump
回复内容：
So many online IM web sites already

最后发表： Microhard
回复内容：
局