Video and photo solution on WordPress

1. Video Solution

在Wordpress的Plugins->Add New页面里搜索”HTML5 and Flash Video Player”,安装完成并激活后,就可以用下面的方式嵌入视频:

  • Without Html5 Video Support:
    [ videoplayer file=”video/xxx.flv” /]
  • With Html5 Video Support:
    [ videoplayer file=”video/xxx.(mp4, ogg, webm)” /]

注意, 去掉'[‘后面的空格,但保留 ‘/]’前面的空格。具体效果,见这里

2. Photo Solution

在Wordpress的Plugins->Add New页面里搜索”NextGEN Gallery“和”NextGEN Monoslideshow“,安装完成后,需要先下载相关SWF文件到’wp-contentuploads’,然后再激活。

需要下载的文件有:

  • JW Image Rotator – 非商业用途,免费
    下载地址是这里:http://www.longtailvideo.com/players/jw-image-rotator/
    解压缩后,释放imagerotator.swf文件到’wp-contentuploads’目录。
  • Mono Slideshow – 收费,25欧
    Demo地址:http://www.monoslideshow.com/demo
    需要的文件是monoslideshow.swf,同样需要释放到’wp-contentuploads’目录。
    如果你很邪恶或者你很穷困潦倒,欢迎使用google的filetype:swf,自行查找,大家共同鄙视之…
    小声说,最好的偷窃地方是这里

好了,最后配置一下路径:

  • Gallery->Options->Slideshow下面的路径;
  • Gallery->Monoslideshow下面的路径;

在Gallery里放好图片,获得Gallery的ID,你就可以开始插入图片了:

  • 基于JW Image Rotator的Slide show方式:
    [ slideshow id=2 ]
  • 基于Mono Slideshow的Mono Slideshow方式:
    [ monoslideshow id=2 ]

注意去掉'[‘后面和’]’前面的空格,效果如下:(如果要指定长宽,请用w和h参数)

  • Slide Show – 这种方式很实用,一定要试试全屏按钮,很震撼…
    [slideshow id=2 w=500 h=375]
  • Mono Slide Show – 这种方式有很多参数,特别是preset参数可以选择,具体请参考上面的Demo地址和下面的附录,效果也很炫…
    [monoslideshow id=2 w=500 h=375]

附:Mono Slideshow的preset参数:

  • preset=’iris’
  • preset=’melt’
  • preset=’ news-flash’
  • preset=’ rgb-separation’
  • preset=’ simple-focus-fade’
  • preset=’ simple-shatter’
  • preset=’ sparkles’
  • preset=’ spot’
  • preset=’ tv-swap’
  • preset=’ widescreen’
  • preset=’ white-water-drop’
  • preset=’ wipe-3d’
  • preset=’ zoom’

Symantec

看资料不说话:(from LinkedIn)

Subsidiaries

  • Huawei Symantec
  • Matika srl
  • MessageLabs
  • Bravo Tecnologia

Acquisitions

  • Relicore
  • Company-i
  • Brightmail
  • @stake
  • SwapDrive, Inc.
  • PC Tools
  • AppStream
  • ON Technology
  • Transparent Logic
  • IMlogic
  • BindView
  • Sygate Technologies
  • PowerQuest
  • Vontu
  • Altiris

Mergers

  • VERITAS Software

Career path for Symantec employees

[before]

  • Sun…
  • Hewlett-Packard

[after]

  • Cisco Systems
  • Microsoft

三悼谷歌

上一篇文章:http://blog.axqd.net/2010/03/23/mourn-again/

Google an update on china

Ever since we launched Google.cn, our search engine for mainland Chinese users, we have done our best to increase access to information while abiding by Chinese law. This has not always been an easy balance to strike, especially since our January announcement that we were no longer willing to censor results on Google.cn.

We currently automatically redirect everyone using Google.cn to Google.com.hk, our Hong Kong search engine. This redirect, which offers unfiltered search in simplified Chinese, has been working well for our users and for Google. However, it’s clear from conversations we have had with Chinese government officials that they find the redirect unacceptable—and that if we continue redirecting users our Internet Content Provider license will not be renewed (it’s up for renewal on June 30). Without an ICP license, we can’t operate a commercial website like Google.cn—so Google would effectively go dark in China.

That’s a prospect dreaded by many of our Chinese users, who have been vocal about their desire to keep Google.cn alive. We have therefore been looking at possible alternatives, and instead of automatically redirecting all our users, we have started taking a small percentage of them to a landing page on Google.cn that links to Google.com.hk—where users can conduct web search or continue to use Google.cn services like music and text translate, which we can provide locally without filtering. This approach ensures we stay true to our commitment not to censor our results on Google.cn and gives users access to all of our services from one page.

Over the next few days we’ll end the redirect entirely, taking all our Chinese users to our new landing page—and today we re-submitted our ICP license renewal application based on this approach.

As a company we aspire to make information available to users everywhere, including China. It’s why we have worked so hard to keep Google.cn alive, as well as to continue our research and development work in China. This new approach is consistent with our commitment not to self censor and, we believe, with local law. We are therefore hopeful that our license will be renewed on this basis so we can continue to offer our Chinese users services via Google.cn.

Posted by David Drummond, SVP, Corporate Development and Chief Legal Officer

关于谷歌中国的最新声明

2010 年 6 月 28 日

David Drummond, SVP, Corporate Development and Chief Legal Officer

自从为中国大陆用户推出 Google.cn 这个 搜索引擎以来,我们一直在尽最大的努力来提高用户对信息的访问,同时遵守中国法律。做到这样的平衡并不容易,尤其是我们在今年1月份宣布不愿意继续在 Google.cn 上对搜索结果进行审查。

当前,我们把所有访问 Google.cn 的用户自动指向了我们香港的搜索引擎 Google.com.hk,通过这种方法,我们可以提供未经审查的简体中文 搜索结果。目前这种方法无论对用户还是对 Google 都运行良好。然而,在与中国有关部门的沟通中我们明确获知:自动指向的做法是不可接受的。如果我们继 续进行自动指向,我们的 ICP 牌照将无法通过年检(年检截止时间是6月30日)。没有 ICP 牌照,我们将不能在中国运营 Google.cn 这样的商业网站——这意味着 Google.cn 将不能被访问。

那是许多 Google 中国用户所担忧的结果,因为他们都清楚表明了希望 Google.cn 继续运营的愿望。为此,我们开始寻找其他可能的替代办法,我们开始为一小部分用户提供一个新的 google.cn 访问页面,该页面与 Google.com.hk 链接,在那里,用户可以进行搜索,或继续使用在 google.cn 上的音乐搜索(Music Search)和文本翻译(Translate)等不涉及内容审查的服务。这个新做法确保 Google.cn 不对搜索结果进行审查的承诺,同时让用户可以在一个页面上访问我们所有的服务。

未来几天,我们将全部停止自动指向,让所有中国用户都直接访问这个新页面——今天,基于这样一个新页面,我们重新提交了 ICP 牌照年检申请。

作为一家公司,我们的追求是让用户随时随地访问到他们所需的信息,包括中国的用户。这就是为什么我们一直在努力地保持 Google.cn 的运营,以及继续我们在中国的研发工作。这个新做法确保了 Google.cn 不对搜索结果进行审查的承诺,并且,我们相信,符合中国法律。因此我们希望能够通过 ICP 牌照年检,让我们可以继续通过 Google.cn 为中国用户提供服务。

McAfee’s Crisis PR

只简单说几句:

  1. 一定要快,隔离影响,提供解决办法;
  2. 不要在说对不起之前,做大量的解释,这人很愚蠢;
    http://siblog.mcafee.com/support/mcafee-response-on-current-false-positive-issue/
    http://siblog.mcafee.com/support/a-long-day-at-mcafee/
  3. 技术上没任何理由,在赛门“误杀门”之后,白名单还能漏掉系统重要文件;
  4. QA Test Matrix漏掉Windows XP SP3是足以让所有用户震怒的事情;

转载自:http://blogs.zdnet.com/Bott/?p=2031

McAfee admits “inadequate” quality control caused PC meltdown

Update 23-Apr: Late Thursday night, McAfee posted a FAQ on this issue at their web site. The FAQ includes some of the text from the confidential document I received yesterday and is clearly a later version of that document. However, the details of why the problem occurred and the specific steps that the company plans to take to avoid similar problems in the future have been replaced with general statements. I have highlighted the differences in updates below.

As of 6AM Pacific time on 23-Apr, there is still no statement, apology, or clearly labeled link to support resources related to this issue on McAfee’s home page.

If your company uses enterprise security products from McAfee, you probably had a bad day yesterday. If you’re an IT professional at one of those companies, you’re probably still cleaning up the mess caused by a defective virus signature update that disabled systems running Windows XP with the most recent service pack (SP3). The worst part? According to a confidential document from McAfee, the cause was a fundamental breakdown in the most basic of quality-assurance processes.

From an IT perspective, this is a nightmare scenario: an automatic update that wipes out a crucial system file and that can only be repaired manually. I’ve heard from more than a dozen IT pros and consultants over the past 24 hours who shared their experiences. They are, to put it mildly, unhappy.

What went wrong?

That was the question I asked in my post yesterday, and I formally asked a McAfee spokesperson for an explanation this morning. I was told that an answer will be posted on McAfee’s blog later today. As of this writing, that blog post has not been published.

But I found the answer, straight from the source, in a document forwarded to me by an anonymous source. According to my source, the document was “a confidential communication to enterprise customers” sent via e-mail. In it, the anonymous author acknowledges that the screw-up was thoroughly preventable. The document, titled “McAfee FAQ on bad DAT issue,” is written in Q&A format and includes the following exchange:

8. How did this DAT file get through McAfee’s Quality Assurance process?

There are two primary causes for why this DAT file got through our quality processes:

1) Process – Some specific steps of the existing Quality Assurance processes were not followed: Standard Peer Review of the driver was not done, and the Risk Assessment of the driver in question was inadequate. Had it been adequate it would have triggered additional Quality Assurance steps.

2) Product Testing – there was inadequate coverage of Product and Operating System combinations in the test systems used. Specifically, XP SP3 with VSE 8.7 was not included in the test configuration at the time of release.

Update 23-Apr: The details I quoted above have been scrubbed from the FAQ posted at McAfee’s website. The corresponding section of the FAQ now reads as follows: “The DAT release was designed to target the W32/Wecorl.a threat that attacks system executables and memory. The problem arose during the testing process for this solution. We had recently made a change to our QA environment. Unfortunately, this change resulted in a faulty DAT making its way out of our test environment.”

McAfee has also sanitized the portion of the FAQ that describes its plans to adapt its quality control procedures. Here’s the original text of the confidential document sent to enterprise customers:

9. What is McAfee going to do to ensure this does not repeat?

McAfee is currently conducting an exhaustive audit of internal processes associated with DAT creation and Quality Assurance. In the immediate term McAfee will do the following to provide mitigation from false detections:

1) Strict enforcement of rules and processes regarding DAT creation and Quality Assurance.
2) Addition of the missing Operating Systems and Product configurations.
3) Leveraging of cloud based technologies for false remediation.
4) A revision of Risk Assessment criteria is underway.

And here is the corresponding text as it appears in the final FAQ, published overnight:

What is McAfee going to do to prevent this from happening again?

Nearly all of our 7,000 employees have been working around the clock to help customers like you get back to business as usual and to make sure this never happens again. The vast majority of our customers are now back up and running and we remain focused on those that remain affected.

We are implementing additional QA protocols for any releases that directly impact critical system files. We are also rolling out additional capabilities in Artemis that will provide another level of protection against false positives by leveraging an expansive whitelist of critical system files and their associated cryptographic hashes.

That is mind-boggling. For enterprise customers, Windows XP SP3 is probably the most widely used desktop PC configuration. Leaving it out of a test matrix is about as close as one can get to IT malpractice. Any enterprise customer who received this document has every right to be furious.

Meanwhile, McAfee’s website is almost completely silent on the issue. Customers who have been affected by the issue who visit the McAfee U.S. home page see business as usual, with a rotation of large ads trumpeting McAfee’s latest products. More than 24 hours after the problem occurred, only a single front-page link is available, and it’s blandly headlined, “McAfee Response on Current False Positive Issue.” If you go to McAfee’s Enterprise home page, there is no mention of the problem and no link to any support resources. An overseas correspondent sent me a screen shot of McAfee’s UK home page, which also has no mention of the issue.

That link leads to a blog post by McAfee’s Barry McPherson, published yesterday at 4:29PM. McPherson seems more intent on praising McAfee’s researchers and minimizing the problem than helping users. He writes: “We believe that this incident has impacted less than one half of one percent of our enterprise accounts globally…” I find it difficult to believe that the company could come up with an accurate estimate at all, much less do so within hours after the problem was identified. It certainly doesn’t match up with the reports I’m hearing from the field.

Update 23-Apr: Yesterday afternoon, the McAfee blog post was edited to remove this reference. The sentence now reads, ” We believe that this incident has impacted a small percentage of our enterprise accounts globally and a fraction of our consumer base…”

From a crisis management perspective, McAfee’s response has been disastrous. If the company truly cared about its customers, the home page would contain an apology from the CEO and links to detailed support information. Instead, it appears that the company is hoping its customers will just forget about it.

Based on the 100+ comments to McPherson’s post, customers who were hit by this error aren’t likely to forget about it soon. And when they figure out that a lapse in the most basic of quality control steps caused them to spend thousands of dollars in IT manpower and lost productivity, they’re likely to be angrier still.

转载自:https://kc.mcafee.com/corporate/index?page=content&id=KB68787

McAfee DAT 5958 False Positive Error – FAQ

Summary
Please note that investigation of this issue is ongoing, and these FAQs will be updated appropriately as we learn more.

What threat was McAfee trying to detect that resulted in a false positive error?
McAfee added detection for variants of the W32/Wecorl.a threat in DAT file 5958. This detection caused a false positive on the svchost.exe Windows system file. The threat parasitically patches the svchost.exe file by modifying data at the entry point or the entry point itself of the original file, to maintain control on the system. In some instances the patch has been found to be polymorphic in nature. McAfee had observed prior infected versions of svchost.exe files and had detection for this threat. This specific detection was added to target a cluster of infected svchost.exe files gathered through our malware collections, directly associated with samples from the W32/Wecorl.a families.

The false positive occurred as a result of new signatures targeting new variants of the Wecorl family of malware when invoked on the file svchost.exe as a part of the memory scanning process. Details of this threat family can be found here: http://vil.nai.com/vil/content/v_153184.htm. Enhanced drivers in the 5958 DAT were authored to detect some low prevalence variants seen recently.

Why did detection for this threat require an invasive approach for detection and remediation?
To remediate this type of threat, detection is customarily written to kill the infected process, in some instances causing a reboot (a standard Microsoft safety action), and allowing for full remediation of the infected system. This type of remediation is standard implementation to gain access to the file objects that may be locked by the running processes.

Unfortunately this caused removal or attempted removal of legitimate svchost.exe file causing issues from network connectivity loss to rendering systems unstable due to the false positive.

Doesn’t McAfee white list known Windows system files?
Complex and sophisticated malware frequently target Windows system executables and attack their memory space (e.g. via DLL injection). McAfee DATs use Whitelisting techniques to avoid scanning and preventing false positives on Microsoft files in the majority of situations, for example, if this was a simple scan of the file as it was accessed on the file system, a false positive would have been prevented. But because this was a memory scan of the running process that then caused a subsequent scan of the file on disk these mitigation techniques were unfortunately not invoked.

Exactly which versions of Windows operating system and the svchost.exe file were affected?
A subset of systems running Windows XP Service Pack 3 and having specific versions of the svchost.exe file were affected. Svchost.exe files found on Windows 2000, Windows 2003, Windows XP Service Pack 1, Windows XP Service Pack 2, Windows Vista, Windows 7 and older versions of Windows were not affected.

Details of svchost.exe files affected are:

File Size OS File Version Md5
14,336 XPPRO_SP3_x86_v1 5.1.2600.5512 E4 10 EC 73 E2 BE 2A 41 D9 23 B0 06 F5 1C 84 27
14,336 XPPRO_SP3_x86_v2 5.1.2600.5512 27 C6 D0 3B CD B8 CF EB 96 B7 16 F3 D8 BE 3E 18
14,336 XPPRO_SP3_x86_v3 5.1.2600.5512 A7 81 24 26 8A 77 F4 19 02 DB 18 F6 22 AF E6 13

How exactly were user systems impacted?
McAfee corporate customers who have the McAfee VirusScan Enterprise product have reported a variety of symptoms, ranging from a system “blue screen” (not to be confused with BSOD, but due to the issues with Explorer and svchost.exe), loss of network connectivity, inability to use USB, and experiencing a perpetual state of reboot. Users have reported these symptoms when both the file is present on the system (in quarantine), or has been deleted entirely.

Minimal impact has been observed to McAfee’s consumer customers because McAfee rolled back the faulty DAT before the update hit the majority of consumer user systems.

Why was VirusScan Enterprise 8.7 primarily affected as compared to VirusScan Enterprise 8.5?
Because of the different implementation of memory scanning within the products, VirusScan Enterprise 8.7 customers were more broadly affected by the false positive.

How do affected customers restore their systems?
McAfee has enumerated instructions to restore systems to their normal functional state with the right critical Windows files in place. McAfee has also developed a SuperDAT remediation tool to restore the svchost.exe file on affected systems.

Specific instructions are available in the McAfee KnowledgeBase in KB68780.

How did this DAT file get through McAfee’s Quality Assurance process?
The DAT release was designed to target the W32/Wecorl.a threat that attacks system executables and memory. The problem arose during the testing process for this solution. We had recently made a change to our QA environment. Unfortunately, this change resulted in a faulty DAT making its way out of our test environment.

What is McAfee going to do to prevent this from happening again?
Nearly all of our 7,000 employees have been working around the clock to help customers like you get back to business as usual and to make sure this never happens again. The vast majority of our customers are now back up and running and we remain focused on those that remain affected.

We are implementing additional QA protocols for any releases that directly impact critical system files. We are also rolling out additional capabilities in Artemis that will provide another level of protection against false positives by leveraging an expansive whitelist of critical system files and their associated cryptographic hashes.

McAfee recommends customers sign up for our Support Notification Service to get real critical product information via e-mail. Go to the SNS Subscription Preference Center to subscribe. For more information, view the SNS KnowledgeBase article and FAQ: KB67828.