ISO 8601 week numbering need correct date format to be specified

Since year 2015 starts on a Thursday, many of the programs which rely on epoch calculation returns the start of the year as monday of the week since the year starts on a thursday. So the start of the year 2015 is actually today, i.e, monday Dec 29th, 2014. You can use the below link for epoch conversion:-

epoch convertor

You can see the difference in format when you run the "date" command on linux machines:-

$ date
Mon Dec 29 20:14:41 EST 2014

$ date -u "+%Y"
2014

$ date -u "+%G"
2015

You can see the same behavior with the below

..
Format f = new SimpleDateFormat("yyyy");
System.out.println("year : " + f.format(new Date()));
..

returns "2014", whereas

...
Format f = new SimpleDateFormat("YYYY");
System.out.println("year : " + f.format(new Date()));
...

returns "2015", so we have to check our scripts and programs to see if we are using the correct format string for returning dates (i.e., not use YYYY or %G)

Elementary OS ppa repository for ubuntu 12.04 (precise)

Add the below links to your ubuntu 12.04 system's software repositories, i.e., /etc/apt/sources.list. Once you add you will have to run "apt-get update" and then proceed with "apt-get install elementary-desktop"

deb http://ppa.launchpad.net/elementary-os/stable/ubuntu precise main 
deb-src http://ppa.launchpad.net/elementary-os/stable/ubuntu precise main 

Amazon SES service interruptions in US-EAST at around 8:42PM PST

We started noticing some SMTP errors in some of the applications that use SES to send outbound messages with the stack below:-

javax.mail.AuthenticationFailedException: 454 Temporary authentication failure

        at com.sun.mail.smtp.SMTPTransport$Authenticator.authenticate(SMTPTransport.java:892)

        at com.sun.mail.smtp.SMTPTransport.authenticate(SMTPTransport.java:814)

        at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:728)

        at javax.mail.Service.connect(Service.java:386)

        at javax.mail.Service.connect(Service.java:245)

        at javax.mail.Service.connect(Service.java:194)

        at javax.mail.Transport.send0(Transport.java:253)

        at javax.mail.Transport.send(Transport.java:124)

the timestamps of this error correspond to service interruptions noted on amazon status dashboard page:-

Some implementations of TLS may be susceptible to POODLE vulnerability

There is a new advisory that some implementations are suspectible to poodle attack with TLS downgrade to SSL:-

https://www.us-cert.gov/ncas/alerts/TA14-290A

 If you have created load balancers created after 10/14/2014 5:00 PM PDT disable SSLv3 protocol by default (they will not allow TLS to fall back to SSLv3, and are therefore not vulnerable to POODLE). For load balancers created before this date, you can manually change the protocols in use: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/configure-ssl-ciphers.html

 You'll just need to make sure your load balancer only supports TLS protocols. The easiest way to do this is to use the predefined policy "ELBSecurityPolicy-2014-10".

New Reserved Instance Model from Amazon

ref: http://blog.cloudability.com