While the iron.io folks do manage to squeeze the size down, they do so through the use of Alpine Linux which uses musl libs rather than glibc and friends. There is a post on hackernews https://news.ycombinator.com/i... that has a discussion about the pros and cons of using an alpine based image.
There is also the deviation from upstream. The official images are a curated set of images and can be maintained by anyone willing to put in the time. For the official images that are not maintained by the upstream project (many of them are), they try to stay as close to upstream recommended build as possible. In fact, the official image gatekeepers recommend talking with upstream before trying to make your own submission to official images so that they can be as involved as they want to be. What this means is that if upstream maintains their own apt repo, that is how it is built into the image, but if upstream does not even release binaries (ie only the source tar) then building from source is they way it is packaged making sure to slim out build dependencies.
There is also some recent focus by Docker Inc to add Alpine based variants to the official images as an option for those that want a slimmer environment (see https://github.com/docker-libr... and other PRs by ncopa). There is even a description on the Docker Hub when an official image has an alpine variant (see https://hub.docker.com/_/ruby/ and https://github.com/docker-libr... which is the source of the Docker Hub version).
Note on the large size of most of the language images from the official images: "It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system." They are usually built from the "buildpack-deps" image: " It includes a large number of "development header" packages needed by various things like Ruby Gems, PyPI modules, etc." (https://hub.docker.com/_/buildpack-deps/).
(yes, I am one of the gatekeepers for official images, https://github.com/docker-libr...)
I own and use a (Sprint) Samsung Galaxy S2 Epic 4G Touch, and it was a series of broken promises on ever getting ICS.
Ever tried another Android device like Motorola, HTC, Sony, Acer, Asus, Amazon, Barnes & Noble, Toshiba, or ViewSonic? All of them add their own crap to Android to differentiate themselves instead of focusing on the hardware and updates. They all promise to do updates and then never deliver. It would be much easier if they did not spend all their time developing things to replace core features of Android (Samsung and their crappy SMS replacement with custom Applesque "notifications"). The fact that you can root it and "do what you want" is the best part of an Android device.
Before this, their name wasn't an issue. Now, maybe I consider some other brand.
There was an option to choose Samsung before this "incident"?
A bit more politer than the other person who commented:
I am quite a bit younger than 45 (as in over 20 years younger) and I use perl on a regular basis.
Dido. Perl is great for the startup I am in.
It is masked but always present. I don't know who built to it. It came before the first kernel.