令我矛盾的法拉利458

By admin, December 9, 2010 23:31

從法拉利458新車發佈之前的無限盼望﹑至看到真車成為事實之後的極度失望﹐簡直令我這個標準的法拉利車迷感覺從天堂掉進了地獄般地難受。

這麼難看的車也配登堂入室進入法拉利的寶典之中﹖難道世人的審美觀真的完全變了﹖最不能讓自己接受的是那驚人的車頭入氣孔﹐好像兩個朝天的大鼻孔﹐完全破壞了法拉利那傳統的美感﹔車身側面像F430﹐車尾則像ENZO﹐換句話來說458就是簡單把F430硬生生地加上了ENZO的尾巴﹐它的面世讓我們這批在傳統法拉利美學中成長的這輩人覺得458就是不堪入目﹐它很可能會成為法拉利歷史上最難看的設計之一。

但做為標準的法拉利車迷的我﹐在收與不收之間掙扎了許久﹐最後還是決定要入一款。

BBR的1比18手版是好﹐但價錢偏貴﹐而且BBR近來正在向賺錢的方向全力前進﹐各種不同顏色﹐限量等458產品應有盡有﹐包保令閣下目不暇接﹐錢包也同時瘦身不少。

好了終于等到Hotwheels Elites的紅色和黃色458版本出了﹐但那門縫大得嚇人﹐比之前的普通版F430還要大許多﹐怎麼搞的﹖雖說價錢的確便宜了4/5﹐但這樣的品質實在有點令人失望和難以購買。

直到黑色的版本出現了﹐當然門縫還是大得嚇人﹐但因為黑色的原因﹐還好﹐看不太出來﹐而且紅色的運動內飾又格外令它份外醒目﹗認識我的朋友都知道我幾乎不收黑色的超跑﹐但今天碰到了它則是一個例外﹗Hotwheels Elites的黑色458其實是金屬黑色﹐不知為何﹐458在黑色的外殼下突然顯得沒那麼難看了﹐開始順眼了許多。

 

1/18 Hotwheels Elite 458 Italia Black

IMG_3817

 

今天看到MC TIKI的評論才恍然大悟﹕ 

F458 的丑,我一早已經有這個感覺,先前在東區走廊看見一部淺銀藍色的,真是不忍相信是法拉利。我也只是象徵式的收了一輛 hotwheel 的算了。458 是把 430 的頭加 Enzo 的尾复制過來,但敗筆是首尾的比例不協調,如果把駕駛室後移一些,或者把頭部加長少許也許會平衡一些。車頭入氣口的兩片翼不倫不類,沒有實質整流作用,又不能混入車身設計,像為了仿效 Enzo 而強行加上去。車頭燈是純為時尚設計而設計,刻意之餘有點做作,但卻與傳統的尾燈不呼應。而最丑的是那兩只超大碼的尾燈,應該設計一套新的跟頭燈的 LED 配合。車身後半部太臃腫,如果把兩邊側窗的線條開得低一點會好看些。

最近的一批車模令我打消了收藏的念頭

By admin, December 3, 2010 23:50

想說最近的一批車模水準十分之參次﹐之前好些打算買的最後都在看了實物後打消了收藏的念頭。

Autoart

Porsche 959 – 主要因為外型還不如幾年前的EXOTO準確。

LAMBORGHINI GALLARDO LP560-2 BALBONI – 我只收了青綠色這款﹐其它的顏色自己覺得多余。

Honda NSX – 太單薄了﹐外型不準﹐有偷工減料之嫌。

ALFA ROMEO GIULIA GTAm SPA 1971 BETZLER #154 – 竟然改變了車頭燈的裝飾﹐和車模實物的輪子覺得太小了﹐不符合比例。

BBR

一系列的ENZO不同顏色和限量的版本﹐模具已經嚴重損耗﹐從車模的縫隙就可以看的出來﹐而且蝕刻片貼的東歪西倒的﹐QC品質控制嚴重失衡。

CMC

Ferrari 250 GT Competition – 明明人家真車有兩條支撐柱子﹐但CMC就是偷工減料﹗

Hotwheels Elite

FERRARI 458 ITALIA Red 和 Yellow – 門縫實在大得驚人﹐比普通版F430還甚

FERRARI 410 SUPERAMERICA Red 和 Gold – 顏色難看得很  

FERRARI 512 S – 實在太玩具了﹐尤其是駕駛倉﹐Elite那出名的精緻內飾蕩然無存﹗

FERRARI 250 GT BERLINETTA LUSSO ERIC CLAPTON Silver – 本來是一定要收到﹐看了實物後就放棄了﹐QC實在做得太差了。

FERRARI 599XX – 好是好﹐但自己怎麼都不喜歡這外形﹐聽車模店主說Hotwheels已經決定取消Super Elite這系列了﹐所以這次的599XX有一半Super Elite的功力就是朝這個方向進發的﹐那我們車模愛好者可就謝天謝地啦﹐這可是車模界天大的新聞啊﹗

Kyosho

Lamborghini Countach LP400 Black – 我原來一定要收的﹐看真車黑得是一塌糊涂﹐倒胃口﹐跟以前那堆燦爛的LP400實在沒法比。

Octane這期的主題﹕Countach﹗四代同堂

By admin, December 2, 2010 21:49

IMG_3791

尋找回發球的信心

By admin, November 16, 2010 22:16

今天在一片高興的氣氛下結束了刺激的雙打比賽。我很驚訝地發現我今天的發球是如此的得心應手﹐很可能是今天的拋球姿勢正確了﹐所以出球無論是力量和旋轉都有了根本的變化﹐而且最主要是心理方面的調整﹐完全放開包袱和儘量放膽去開球﹐出來的效果跟昨天判若兩人﹐加上多了網前VOLLEY主動出擊﹐自己都覺得表現滿意﹐在場的另外3位可以為我做證。

恍如隔世 Back from Hell!

By admin, November 14, 2010 23:19

時間不知不覺飛一樣地過了3個月﹐我也終于捱過了這極度艱苦的3個月。

因為8月開始公司需要進行大型的系統升級而且加上時間緊迫﹐所以這段期間連睡覺時間都很寶貴﹐每天幾乎都要工作長達13-15個鐘頭﹐最低時薪$28肯定達不到。 (對IT/Network/Server有興趣的朋友﹐可以到我的Blog看看詳情)

有時在街上遇見波友﹐都只好苦笑一下﹐很無奈﹐沒辦法﹑生計緊要﹐網球只能排第二。

Now I am back from Hell!   又可以從新開始新的波季﹗

真心希望可以和大家從新再次享受Happy Tennis!  

單雙打無所謂﹐最緊要開心﹗放心我沒退步太多﹐因為上星期打了3個月正式的第一場﹐感覺十分良好。

而且這3個月我心理上得到了“極度充實的壓力測試”鍛煉﹐這下應該可以在球場上發揮得更加臨危不亂了。

人生中總有幾次大起伏﹐正如政府宣傳講“方法總比困難多”﹐只要從容面對﹐加上努力多數都可以克服﹐即使達不到﹐也無需要後悔。

而且我這次學會了放棄放下一些長期的心結﹐原來之後得到的更多。

Just like in a tennis game, sometimes, you need to learn when to let go for a shot or even a game and prepare for the next one that may eventually lead to a victory in a match.

正所謂”置之死地而后生“﹐我完全明白了這個道理﹐當然﹐過程之辛苦(尤其是心理上)﹐我想經歷過類似困難的朋友都應該知道我的意思。

Inception

By admin, November 6, 2010 15:22

看著他從13年前Titanic裡青澀的Jack到The Departed裡火爆的Billy﹐到近期一連兩套類似的戲Shutter Island裡面的Teddy和今天Inception裡的Cobb﹐Leonardo Dicaprio真的是越來越有魅力﹐短短十年內﹐演技已經達到爐火純青的地步﹐Hollywood有此等人才的確難得。

回到此片﹐可以說是近年來自Matrix後又一令觀眾深思的電影﹐它極有可能會成為以後這種題材的經典教材。

InceptionPoster3WBHD-691x1024

我的第一台白色Porsche 911 – Simple but Elegant

By admin, November 1, 2010 22:17

個人認為經典的保時捷系列裡最好看的是60年代的901﹑80年代的993以及90年代964﹐他們的外型絕對稱得上是一脈相傳﹐都擁有著正宗的911血統。

很喜歡最近出的這款1992年白色的Porsche 911 (964) Carrera RS﹐懂得欣賞911的人都會因為有著RS而更加喜出望外。

當然很多保時捷車迷們都會對Turbo系列的超凡性能如痴如醉﹐但唯獨我對Carrera紳士般的外型更為喜愛﹐它的氣質實在來的儒雅和有內涵。

經常留意我博客的朋友可能已經發現了個秘密﹐就是我很少談及超跑的性能。沒錯﹐我更為欣賞的是這些偉大跑車們的外型設計﹗我認為它們之所以吸引我完全是因為他們的“外在美”﹐所以擁有一台真正的超跑對于我來說完全可能是一種浪費﹐因為我對咆哮的引擎和性能暫時還並不發燒(3年前曾有朋友說我將來一定會的)﹐雖然自己大學修讀的專業是機械工程。

其實車模帶給我的最大樂趣莫過于把這些超跑美和吸引人的角度從照片上體現出來﹐很多時候我都深深地沉醉于場景構思和拍攝角度中﹐自得其樂﹐悠哉悠哉。

那麼車模帶給你們的最大樂趣又是什麼呢﹖

 

1/18 Autoart Porsche 911 (964) Carrera RS 1992

IMG_2991

Veeam Backup Space Required: Formula and Calculation

By admin, October 31, 2010 12:03

Found this really useful information in the Veeam’s forum (contributed by Anton), a great place to learn about the product and their staff are all very caring and warm.

The formulas we use for disk space estimation are the following:

Backup size = C * (F*Data + R*D*Data)
Replica size = Data + C*R*D*Data

Data = sum of processed VMs size (actually used, not provisioned)

C = average compression/dedupe ratio (depends on too many factors, compression and dedupe can be very high, but we use 50% – worst case)

F = number of full backups in retention policy (1, unless periodic fulls are enabled)

R = number of rollbacks according to retention policy (14 by default)

D = average amount of VM disk changes between cycles in percent (we use 10% right now, but will change it to 5% in v5 based on feedback… reportedly for most VMs it is just 1-2%, but active Exchange and SQL can be up to 10-20% due to transaction logs activity – so 5% seems to be good average)

傳聞中全開的BBR樹脂膠Ferrari 458

By admin, October 30, 2010 11:13

P1813OPEN_detail

p1813open-3

最近在MC看到上海沙沙的回答﹐估計如果真的成事﹐價格最少在6千以上﹕

我把我知道的和大家分享一下。摟主觀察得很仔細,的确那個白模(灰模)并非烽火輪的。合金模型的零部件眾多,他的灰模也不是這個樣子。這個其實是bbr 手版模型試圖生產開門版本的一個試驗模型。很遺憾這個模型最終沒有被通過,兩個原因—-第一造价的昂貴(1多開模,2必須用技術水平極高的師傅才能組裝,3損坏率高)用這樣的成本生產出來以后,能夠承受得了這個价格的客人估計已經很少了。 第二,要解決開啟次數能足夠多,而接縫不變形,這些存在一些技術上的難關。 所以BBR目前暫時放棄了生產開門458手版的計划。至于以后是否可以做開門的手版模型,這個不得而知。 BBR合金的458是否能生產開門版本的,目前沒有說會生產,但是也沒有說一定不生產。只能說生產的可能性很小,其實不必糾結在這里了。

bbr458

Some interesting findings about Veeam Backup v5

By admin, October 29, 2010 11:56

The followings are my own findings about Veeam Backup v5: 

  • If you have more than 30-50 VM (average 20-30GB) to backup, it’s better to setup a 2nd Veeam Backup server to load-balance the job. So eventually, you may have a number of load-balanced Veeam Backup servers to evenly spread out the loading, and this will greatly reduce the queue time and shorten the total backup windows.Don’t Worry, all Veeam Backup servers are managed centrally by Veeam Enterprise Manager (and the best part is additional Veeam Backup servers DOES NOT count towards your Veeam licenses, how thoughtful and care Veeam is, thank you!)It’s recommended by Veeam to create 3-4 jobs per Veeam Backup server due to high CPU usage during the backup windows for de-duplication and compression. However this doesn’t apply Replication which doesn’t use de-duplication and compression.Note: However there is another way to fully utilize your one and only Veeam Backup Server by adding more than 4 concurrent jobs. (See quote below)
  • The “Estimated required Space” within Job description is incorrect as it’s a know bug that VMware API or Veeam doesn’t know how to interpret Thin-Provisioning volume yet, so estimate by yourself. Most of the time, it will over-estimate the Total Required backup space by 3-10x more, so don’t worry!
  • After each job completes, you will see a Processing rate: (for example 251 MB/s), which means total size of VM divided by total time it took to process the VM. This is affected by time it takes to talk to vCenter, freeze guest OS, create and remove snapshot, backup small VM files (configuration), and backup actual disks.

I am still not sure if the target storage requires very fast I/O or high IOPS device like 4-12 RAID10/RAID50 10K/15K SAS disks as some say the backup process with de-duplication and compress is random, some say it’s sequential, so if it’s random, then we need fast spindle with lots of disks, if it’s sequential, then we only need cheap 7200RPM SATA disks, a 4 RAID 5 2TB will be the most cost effective solution for storing the vbk/vik/vrk images.

Some interesting comments quote from Veeam’s forum relating to my findings:

That’s why we run multiple jobs. Not only that, but when doing incremental backup, a high percentage of the time is spent simply prepping the guests OS, taking the snapshot, removing the snapshot, etc, etc. With Veeam V5 you get some more “job overhead” if you use the indexing feature since to system has to build the index file (can take quite some time on systems with large numbers of files) and then backup the zipped index via the VM tools interface. This time is all calculated in the final “MB/sec” for the job. That means that if you only have a single job running there will be lots of “down time” where no transfer is really occurring, especially with incremental backups because there’s relatively little data transferred for most VM’s compared to the amount of time spent taking and removing the snapshot. Multiple jobs help with this because, while one job may be “between VM’s” handling it’s housekeeping, the other job is likely to be transferring data.

There are also other things to consider as well. If you’re a 24×7 operation, you might not really want to saturate your production storage just to get backups done. This is admittedly less of an issue with CBT based incrementals, but used to be a big deal with ESX 3.5 and earlier, and full backups can still be impacting to your production storage. If I’m pushing 160MB/sec from one of my older SATA Equallogic arrays, it’s I/O latency will shoot to 15-20ms or more, which severely impacts server performance on that system. Might not be an issue if your not a 24×7 shop and you have a backup window where you can hammer you storage as much as you want, but is certainly an issue for us. Obviously we have times that are more quiet than others, and our backup windows coincide with our “quiet” time, but we’re a global manufacturer, so systems have to keep running and performance is important even during backups.

 

Finally, one thing often overlooked is the backup target. If you’re pulling data at 60MB/sec, can you write the data that fast? Since Veeam is compressing and deduping on the fly, it can have a somewhat random write pattern even when it’s running fulls, but reverse incrementals are especially hard on the target storage since they require a random read, random write, and sequential write for ever block that’s backed up during an incremental. I see a lot of issue with people attempting to write to older NAS devices or 3-4 drive RAID arrays which might have decent throughput, but poor random access. This is not as much of an issue with fulls and the new forward incrementals in Veeam 5, but still has some impact.

 

No doubt Veeam creates files a lot differently that most vendors. Veeam does not just create a sequential, compressed dump of the VMDK files. 

Veeam’s file format is effectively a custom database designed to store compressed blocks and their hashes for reasonably quick access. The hashes allow for dedupe (blocks with matching hashes are the same), and there’s some added overhead to provide additional transactional safety so that you VBK file is generally recoverable after a crash. That means Veeam files have a storage I/O pattern more like a busy database than a traditional backup file dump.

Pages: Prev 1 2 3 ...254 255 256 257 258 259 260 ...292 293 294 Next