Comments (0) I used to love this song very much and it is still one of my favourite rock n roll till today.
and of course there is R.E.M.’s “Losing My Religion”, I can still remember clearly that unforgettable night in England, everyone in the pub were so high singing this song altogether.
自從去年四月初首次看到Mulsanne的極不認同﹐到今天越發喜歡的那份強烈對比﹐只說明了一個原因﹕賓利的設計的確與時並進了﹐令我的審美觀也產生了根本的變化﹐也就是更加接受了對現代汽車肌肉型設計的認同﹗
自己一直比較喜歡Bentley那種獨特的英倫味道﹕豪華的來又不失運動的神韻﹐比Rolls Royce的那種令人窒息的霸氣感覺更加有人情味。這就好比擁有Rolls Royce的人幾乎一定有司機﹐但擁有Bentley的人就沒這種潛在的規則﹐君不見現在連Rolls Royce都給Bentley逼得急忙推出了所謂悠閑版的Phantom (叫Ghost)﹐就知道Bentley是多麼的受世界各地買家的歡迎﹐Bentley的那種獨特的豪華悠閑氣息的確令人陶醉。
英國Bentley精品網站的回復說他們不會有這款車模﹐所以只能3天前從美國的Bentley代理商那里訂購，想不到今天就送到了，速度真快，剛好赶上農歷新年作為自己送給自己的最佳紅包。
打開包裝後﹐就發現這款賓利車模的綠色盒子比以往版本來的長﹐而且盒子只寫著Minichamps for Bentley﹐連型號都省略了﹐還真對得起這價錢。
Mulsanne在光洁亮麗的銀灰色高雅顏色下，格外顯得那肌肉的動感，龐大的鬼面罩旁加上兩只曾極度惹人爭議的渾圓大眼睛，更加顯得這新一代的賓利旗艦与過去的不同，翻查資料才發現原來五六十年代的Bentley S1和S2其實都是這種大眼睛的設計﹐加上賓利最出名的內飾刻劃細膩﹐配合的天衣無縫﹐整體散發出一如既往的优美和典雅。
最後D.E.版与即將推出的黑色普通版本外形最大的不同之處，就是D.E.版的車頭擁有那精致的B標志！
如果用三個字來總結﹐那莫非只有“真完美”可勝任﹗
1/18 Minichamps Bentley Mulsanne Dealer Version – Brodgar
以下是賓利新設立的中文網站對于Mulsanne的貼切描述﹕
賓利創始人，華特.奧文. 賓利先生想要制造出一輛汽車界的頂峰之作：大、快速、宁靜、舒适。 這一理念深深地影響著賓利。隨著時間推移，豐厚的精神財富發揮出惊人的效力，賓利特質一一展現出來：屢次打破記錄、技藝發展、大膽開拓、精湛的手工藝和靚麗的設計。 如今，90載歲月過去，一款全新旗艦型豪華賓利Mulsanne轎車實現了華特.奧文. 賓利的愿景。當賓利Mulsanne行駛在路上，其強大動力和精致典雅足以令其他轎車黯然失色
設計出一輛動力強卻又敏捷靈動的豪華轎車并非易事。但這一設想卻真實的藉由賓利 Mulsanne實現了。 有如一名強壯且又靈活优雅的運動員一般，賓利 Mulsanne將力量、优雅和運動風格獨特融合為一體。
整體的車身造型展現出豐富的設計對比。它顯得如此剛毅，仿佛是用一塊巨石，一蹴而就雕刻而成，同時又散發著优美和典雅。 純粹不失圓潤，經典而又現代。 它的設計能夠讓不同的特殊材質得以物盡其用。 例如，對不同厚度的鋼板，手工焊接創造出獨特、無縫且緊密擬合的感覺。 試想下，比如在焊接后門背部一個冗長的金屬部件時，這個過程需要花費整整45分鐘的時間。
通過采取這些額外的工序，賓利的技術人員能夠創造出一件圓潤的藝術品，并以此進一步突出那些經典的、英國賓利的元素： 大弧度的線條飽含著運動的激情，強勁的車腰揭示著尚待噴涌的動感。 這樣做難嗎？ 是的，很難。 無法實現嗎？ 不，可以實現。
近距离觀察賓利 Mulsanne，您可能會有似曾相識的感覺，但這份熟悉感之外又有几分特別。 大而圓的LED頭燈，位置更加靠近格柵，在開車時帶來燈光交錯的效果——這与我們1930年的8升引擎轎車的配置彼此呼應。“為實現這一目標，我們花花費大量時間去研究過去的標志性的賓利轎車。例如：賓利8升轎車，20世紀50年代的飛馳、Brooklands、雅駿和雅致。這些都是我們考慮到的結合點”，首席外型設計師Raul Pires表示說， “我們希望得到的是更加運動和更有特色的賓利汽車外觀。”
真的很耐用﹐省回不少錢﹐因為一年才需要穿一次(因為自己完全不介意跌磅的問題)﹐下次會穿低磅些這樣POG會更加好打。
![LuxilonBigBangerACETouch_Z9955[1]](http://www.modelcar.hk/wp-content/uploads/2011/01/LuxilonBigBangerACETouch_Z99551.jpg "LuxilonBigBangerACETouch_Z9955[1]")
Luxilon Big Banger ACE TOUCH Hybrid, Ace 18 (Main), Supersense 16L (Cross)
多謝兩位師兄今天來切磋﹐天公造美﹐原來還擔心會下雨﹐但到了3點竟然陽光普照﹐讓我們一共享受了3小時的Happy Tennis。
高手原來表面是完全看不出來的﹐直至上了場才知道今天遇到了兩位above 4.0高手中的高手。
一個power serve+top spin打兩邊﹐底線穩的無懈可擊﹐有頭腦又有plan﹐今天是我第一次比人打到連底線都要叫救命。原來還以為底線還可以﹐慚愧﹐見識了什麼是真正的底線抽擊才知道自己的渺小﹐哈哈。。。要改進和學習的東西實在太多了。
另一個也是打了二十多年的高手﹐電腳+平擊大斜角﹐他們兩個派左無數個蛋比我﹐記憶中好像只贏了他們各一個game﹐而且還要是他們自己多unforce error。有幾個game自己的開球還不錯﹐有角度也有速度﹐但還是給對手輕易的一個短球+nice angle﹐then game over。真的拗晒頭都沒方法可以打贏他們。
今天的學到的重點是速度+spin﹐第一次感受到什麼是新式的powerful top spin打法﹐還有就是他們兩位的下盤極之穩定﹐foot work almost perfect﹐打波其實真的靠對腳﹐腳到進攻就成功了一半﹐正如開球好一樣。
我的其中最大的缺點就是下盤不穩﹐foot work almost none﹐改了好多次﹐比當初已經進步了些﹐但離他們的水平實在相差太遠﹐還需繼續努力。
希望下次有機會再和你們學習。
這兩天住所附近的商場在做Top Gear Car Show﹐所有的展品都沒有欄杆阻擋﹐是可以用手觸摸的﹐正想接近SLS时﹐突然看見有一頑童拼命用手拍打SLS車頭﹐而且哼哼有聲﹐看樣子SLS肯定是刮花了。保安叔叔面色大驚﹐忙說“小朋友﹐這不是玩具﹐請別拍打車”﹐OMG﹗
I didn’t know this could happen until last night. I restarted VMware vCenter server after installing Microsoft patches for Windows Serve 2008 R2. Then used vSphere client to connect to vCenter, suddenly it started to pop up with error, also found vCenter Server Service has stopped or crashed to be precious and error logs showed Event 1000 ID, luckily I found this is to do with vCenter port conflicts. I was also able to confirm this by another user’s post in VMware community who’s having the same port conflicting problem with PRTG and ESX 4.
As usual, my memory needs to rewind and back to the point where I installed PRTG Network Monitor 4 days ago, by trial and error, I stopped the PRTG Server and Probe Services, then I was able to restart vCenter server again and login with vSphere client. Finally, I was also able to restart PRTG server without any problem, PRTG somehow was able to bind itself dynamically to another port which vCenter couldn’t.
In additional, I did try to change the port for PRTG and its Probe services, but after restarting the server, somehow PRTG is still conflicting with vCenter’s port (I don’t know which port, but PRTG is using a range of ports above 23560)
The solution is quite simple but a bit troublesome, as it’s a matter of precedence, I just need to start vCenter Server service before starting the PRTG services MANUALLY every time after restarting the server.
If you know how to change the service start dependence or any proper way to solve this, please do let me know, as somehow I still couldn’t figure out the permanent solution for this port conflict problem, thanks!
Dell has a new “Build-in OS” called System Service (USC) that you can simple update firmware and deploy different OS using the simple GUI. I like it a lot for OS deployment as it indeed saved me a lot of time in finding different drivers, but until recently, I found the specific USC module that is the Platform (Firmware) update feature isn’t very stable and may cause various system problems.
The following is what I’ve encountered:
I press F10 during boot time and enter USC and select Platform Update for firmware update process, configure IP for USC and then next connect to ftp.us.dell.com to check a list of update firmware, after 5 minutes, as usual, USC found a list of outdated firmware (about 15 of them) and asked me if I would like to continue to update those. Great! then click apply, “Please Wait” is what I get on screen and wait, and wait and wait, I waited for more than 2 hours and definitely sensed some kind of strangeness as my last update using USC for BIOS and IDRAC only took 15 mins.
Immediately I called Dell Pro-Support regarding this issue, they suggested me to wait and they ensure me everything should be ok, as even bad thing happens, I can still use Firmware Roll Back under USC, and if a particular firmware download process isn’t completed then the update won’t carry on.
O.K., then I went to sleep, after 12 hours, I checked the server, it is still showing the annoying “Please Wait”, NOTE there is NO WAY for me to know the status of the update progress as it won’t tell me which module/firmware it has finished downloading or completed the upgrade process for a particular firmware.
I have no choice but to reboot the server, luckily, the server (OS is Windows Server 2008 R2) came back ok, and I checked the firmware information in OpenManage, NOTHING HAS BEEN UPDATED, and worst some of the sensors in OpenManage are gone such as temperature/voltage/fan, etc. Right away I KNEW iDRAC Must Have Been Damaged during the firmware update under USC, so I connected to R610 iDRAC and indeed found all of the sensors showing reading errors. Huh???
Then I thought by updating the iDRAC firmware may help, so I tried to update iDRAC6 to latest 1.5.4 using the standard windows firmware file, immediately error shows “This update package is not compatible with your system configuration”, thank you very much!
After searching Google with no solution found, I suddenly thought of a way to update it by downloading the raw iDRAC6 firmware update file and using iDRAC’s own update feature from Remote Access > Update and I have successfully updated it! Yeah! Then I reboot the server, and checked OpenMange again, thank god, everything is back to normal this time!
Finally, I simply go back to the traditional way of updating firmware on Poweredge which I have been doing for the past 10+ years, that is download the firmware one by one and update my Poweredge R610 BIOS/Network/Raid etc one by one.
So my conclusion is:
1. Platform Update utility under USC is NOT A MATURED PRODUCT!
2. Probably USC FTP process hanged, network issue, but USC won’t alert at all, just showing “Please Wait” that really DOESN’T HELP AT ALL!
3. You NEED TO UPDATE iDRAC first (probably using the above method) before using USC, as USC uses iDRAC to facilitate the rest firmware upgrade process. I remembered ont time USC warned me it will upgrade iDRAC first before anything else, but it didn’t warm me this time.
Dell please correct this bug ASAP in USC Platform Update, at least show us the update process bar or some useful detail information!
If you want to read about my first disappointment regarding firmware update, please refer to Do not update firmware/BIOS from within ESX console.
Update:
Just received an update from Virtualization Buster, which is the proper way to update firmware using an USB method via F10 Unified Server Configuration (USC).
Updating Dell R-Series aka 11-th Generation Servers via USB and Repository Manager
http://www.virtualizationbuster.com/?p=1301
Finally, since there is no way to attach an USB via iDRAC6, so if you need to update Driver thru USC, you can use Dell Repository Manager, export the drivers to an ISO. (Tips from Dell Pro-Support)
Saw these two piece of useful information on Veeam’s forum today, mostly contributed by Tom:
Block Size Optimization
In the job properties, on the “Backup Destination” if you hit “Advanced” and then select the “Storage” tab with V5 you can now select to optimize for Local disk, LAN target, and WAN target. What this is really doing is setting the “block size” of the VBK. Previous version of Veeam always used 1MB blocks, which is now the equivalent of the “Local disk” option. LAN target uses 512KB blocks, and WAN target uses 256KB blocks. The smaller blocks sizes typically mean that incrementals are smaller and thus less data is transferred over the LAN or WAN at the cost of some CPU. Because we push our backups across sites we always use the WAN target settings.
Reversed Incremental or Synthetic Full
As a general rule, reverse incrementals are going to use the least amount of space on disk, but the most amount on tape, while the reverse is true of forward incrementals, they will use more disk space, but significantly less tape space. The only exception might be if you have a fairly small retention period.
Assume you have a 100GB full backup with 10GB of changes a day, here’s how the space would break down assuming 4 weeks retention:
Reverse Incremental:
Disk — 100GB Full + 280GB (10GB/day * 28 days) of reverse incrementals = 380GB
Tape — 100GB VBK copied to tape every day * 28 days = 2.8TBForward Incremental w/Synthetic Full:
Disk — 400GB (100GB Full * 1 per week) + 240GB (10GB/day incrementals * 24 days) = 640GB
Tape — Same as disk, since you simply copy the full or incremental to tape every day = 640GBSo, the Forward Incremental/Synthetic option in this scenario would use ~70% more disk space, but less than 25% of the tape space. If you’re planning to keep only a short period of disks on retention and use tape for long term storage then forward incrementals will save space, but that’s about the only scenario where it will save space. For the best space savings with on disk retention, reverse incremental are the way to go, but at the cost of a large amount of tape space.
Personally I prefer reversed incremental because my main strategy is to get a full working backup to tape every night without the need to merge increments when in an emergency need to get my files back from tape.
價值愈千萬港元的英國超級跑車ASTON MARTIN ONE-77，雖然未知香港可以獲得的配額究竟有幾多，但可以肯定是在全球77台限額中，已經有60台成功售出，只餘下17台配額而已。與此同時，廠方亦已為這台限量超跑新貴展開亞洲巡迴展，日本東京站已於日前結束，緊接會是新加坡和台灣等地，至於擁有大量超跑的香港亦會在當中之列，不過仍有待代理公布才可作實。
