Wednesday, April 23, 2014

No difference: Apple Support is a blackhole.

Oh my ... guys. I am losing my battle with Apple. It makes no to me but it is happening. The past couple of days ... have been pure-shit. Grrr!

If you think your super expensive laptop made in the USA is better than a super cheap model  made in China/Korea/Spain, then think again! Apple, as company, works hard to maintain its  image as being perfect (including the support they provide).... but as I recently learned, they are no different than any other company. It is only an image for your brain, it is marketing.

In the 20 years that I have been using laptops, I have NEVER EEEEEEEVER had as many  problems as I am having with my Apple laptop. I repeat NEVER has a battery exploded. Yes, you heard me! Exploded like a BOMB! I have had a number of laptops – including laptops from HP, IBM, Lenovo, and Acer - and have never had this happen to me. The batteries in those laptops generally last for five to six years. While that isn’t great, it’s standard for the market.

This time, after just four years, the battery in my macbook exploded. Oh man! This is not normal. You could tell me the battery would end its life without charge … but my macbook went from holding a charge for 3 hours (about 500 cycles) to exploding. Apple is telling me it is normal. WTF! That is not normal. It must be investigated. Either Apple didn’t listen to me or they don't want to listen to me. I expected the battery in my macbook to last for at leaste another 2-3 years. After all, that is the norm … and it is what I expected having paid such a hefty price for it. Grrrr!

So, now I ask myself - Why did I pay double the price for a macbook, if it will only last half the  time? It makes no sense. All I can say is … Lesson learned!

My incident ID: 597671455. Apples response: "Normal end. We don't have a procedure to solve it"

Here are pictures of my laptop – post explosion:

In this thread (Mavericks - power use / service battery) there are right now: 65658 Views and 342 Replies. Nothing more to say.


(thanks for the translation Ken)

Update1: 10.9.3 does not solve the issue (at the moment)
Update2: I lost my battle. I have bought this battery:
Update3: At the moment: two weeks with this new battery and i think the temperature is higher than the original battery when it is charging but it is ok. About 4.30h of battery autonomy.

Tuesday, April 22, 2014

Compiling Boost 1.55 in CentOS 6

  1. EPEL repository
  2. Updated system
  3. yum groupinstall "Development tools"
  4. yum install boost*
  5. yum remove boost* (last two steps to get initial dependencies)
  6. yum install libicu libicu-devel zlib-devel zlib python-devel bzip2-devel texinfo
  7. Download tarball of boost_1_55 and extract
  8. / --with-icu
  9. ./b2 -d0 -a

Thursday, April 10, 2014

MyDumper 0.6.1 RPM for CentOS 6.5

I made the last 0.6.0 mydumper RPM package a few days ago but there is a new release/version.

From MySQL Performance Blog:

mydumper 0.6.0

  • #1250269 ensure statement is not bigger than statement_size
  • #827328 myloader to set UNIQUE_CHECKS = 0 when importing
  • #993714 Reducing the time spent with a global read lock
  • #1250271 make it more obvious when mydumper is not successful
  • #1250274 table doesnt exist should not be an error
  • #987344 Primary key name not quoted in showed_nulls test
  • #1075611 error when restoring tables with dashes in name
  • #1124106 Mydumper/myloader does not care for 0-s in AUTO_INCREMENT fields
  • #1125997 Timestamp data not portable between servers on differnt timezones

mydumper 0.6.1

  • #1273441 less-locking breaks consistent snapshot
  • #1267501 mydumper erroneously always attempts a dummy read
  • #1272310 main_connection keep an useless transaction opened and permit infinite metadata table lock
  • #1269376 mydumper 0.6.0 fails to compile “cast from pointer to integer of different size”
  • #1265155 create_main_connection use detected_server before setting it
  • #1267483 Build with MariaDB 10.x
  • #1272443 The dumping threads will hold metadata locks progressively while are dumping data.
So we have a new RPM package (centos 6) for 0.6.1 in the repo:

Monday, April 7, 2014

libfdk_aac for CentOS 6.5

From ffmpeg webpage:

Fraunhofer FDK AAC codec library. This is currently the highest-quality AAC encoder available with ffmpeg. Requires ffmpeg to be configured with --enable-libfdk_aac (and additionally --enable-nonfree if you're also using --enable-gpl). But beware, it defaults to a low-pass filter of around 14kHz. If you want to preserve higher frequencies, use -cutoff 18000. Adjust the number to the upper frequency limit you prefer.

Ok. Here my own RPM of that library for CentOS 6.5:

Sorry. No time friend. It is not tested. :(