You hit the nail on the head. We provided, and more specifically, I, directly did, estimates on when we launch certain features.
Unfortunately those deadlines have come and gone. That was because those estimates were rooted in timeframes around how we were able to write code in 2012 when we didn't hit the large growth spurt we did in 2013.
As a result the majority of 2013 was about meeting customer demand. Luckily we've finished out the year very well in scaling the various teams within the company and adding in the necessary layers of management so that we finally feel that we are getting back on track with engineering again.
With the launch of Singapore there are actually alot of updates under the hood that customers don't see but the hypverisors in Singapore are running on a completely new version of our cloud backend.
As we close out February we are reviewing our product roadmap and will start providing feedback again on estimates and hopefully be once again much more accurate in those estimates.
One of the other items we've considered is putting together a blog post about our 2013 in review and specifically focusing on what happened to our product roadmap and what delays we hit and why, and how we are looking to get past those challenges in 2014.
Forgive my ignorance, but who is doing the blocking? Is it American sites willingly censoring for legal reasons, or is the Cuban government blocking them for the country's own ISP?
For as much as AMD shows promise in their graphics line, if one thing is clear it is that the Bulldozer architecture has been a humiliating failure on the CPU side: extremely high TDPs and terrible performance vs. equivalent Intel *y Bridge/Haswell cores. It's been universally panned for most workloads since its release date made worse by AMD's marketing efforts leading up to its launch.
I wonder what has happened to the Bulldozer design team at AMD at this point and whether or not they even still work there at all.
I remember reading an article a while back re: changes from hand-drawn manual layout to automated layout methods for the chips. The assertion was that manual layout is often better for compute performance, while automated layout makes more efficient use of die area.
AMD, of course, spun off GlobalFoundries years ago and now pays a 3rd party to fab their processors. They also led the charge to incorporate graphics cores into the same die, and modern GPUs are very transistor-intensive.
Basically, I would not be surprised if this is as much about process as it is about design.
Nope. Unless it's something I need to keep around (taxes, insurance, usual "business of life" things,) I don't keep any of my email, messages, etc. for more than a few months at best. Nostalgia can prove to be an enemy of progress, and not having a lot of things to look back on keeps me focused on the future.
We'll use standard DHE if the user selects an RSA cert (2048, 3072, or 4096). And we'll use ECDHE if the user selects an Elliptic Curve cert. We'll also be displaying a disclaimer about the potential issues with ECC (certain experts believe TLS curves may be compromised/weakened) if the user selects that.
If this is going to become a pattern, it probably makes more sense to allow the browser chrome to be manipulated in a way so progress bars aren't redundant (i.e. 'pjax' style loading uses the same bar as if you did a real page load, just like pushState allows for history manipulation.)
It would be cooler to see some guys get together and make a de facto standard, and then implement this type of control into extensions for FF/Chrome.
> Maybe there are better ways of monetising than forcing multiple pages of ads down your users throats? :)
Kill the CPM model and your wish will come true. Unfortunately, advertisers often first ask "Well how many pageviews does your <site/app/whatever> have?" Most advertising metrics are still stuck 10 years behind where we are and where we're going.
> Intrusion prevention via fail2ban and rootkit detection via rkhunter.
Semantics, semantics, but rkhunter is intrusion detection, not prevention. I don't know what rkhunter would do to stop an intrusion, and fail2ban stopping a brute-force on your SSH login is hardly the likely intrusion vector for a server running this many services.
These tools still require a huge amount of systems administration work before it really counts as a "personal cloud". rkhunter looks for some basic rootkits but will not really protect you from emerging threats, other than to tell you you have a file integrity mismatch on a common file such as /usr/bin/login.
Since this is installing everything, it seems wise to add better host-based intrusion detection/file integrity checking across all services and configurations, via AIDE[1] or Samhain[2], which you could do with this type of automated setup. Both can then use the local MTA to alert you directly to your mail client if something is compromised, plus you gain the security of your configuration files for these services not having been tampered with.
What about running unattended-upgrades[3] for security patches to things like Apache et al? Given the adversaries expected here, I assume that we aren't worried about false packages, etc. as a risk.
