As far as computer architectures go, ARM doesn’t have anything to be ashamed of. Since nearly every mobile device on the planet is powered by some member of the reduced instruction set computer (RISC) family, there’s an excellent chance these words are currently making their way to your eyes courtesy of an ARM chip. A userbase of several billion is certainly nothing to sneeze at, and that’s before we even take into account the myriad of other devices which ARM processors find their way into: from kid’s toys to smart TVs.
ARM is also the de facto architecture for the single-board computers which have dominated the hacking and making scene for the last several years. Raspberry Pi, BeagleBone, ODROID, Tinker Board, etc. If it’s a small computer that runs Linux or Android, it will almost certainly be powered by some ARM variant; another market all but completely dominated.
It would be a fair to say that small devices, from set top boxes down to smartwatches, are today the domain of ARM processors. But if we’re talking about what one might consider “traditional” computers, such as desktops, laptops, or servers, ARM is essentially a non-starter. There are a handful of ARM Chromebooks on the market, but effectively everything else is running on x86 processors built by Intel or AMD. You can’t walk into a store and purchase an ARM desktop, and beyond the hackers who are using Raspberry Pis to host their personal sites, ARM servers are an exceptional rarity.
Or at least, they were until very recently. At the re:Invent 2018 conference, Amazon announced the immediate availability of their own internally developed ARM servers for their Amazon Web Services (AWS) customers. For many developers this will be the first time they’ve written code for a non-x86 processor, and while some growing pains are to be expected, the lower cost of the ARM instances compared to the standard x86 options seems likely to drive adoption. Will this be the push ARM needs to finally break into the server and potentially even desktop markets? Let’s take a look at what ARM is up against.
Continue reading “Amazon Thinks ARM is Bigger than your Phone”
Probably the best example is to simply go to the site and click on “About itty bitty.” That page is itself encoded in its own URL. If you then click on the App link, you’ll see a calculator, showing that this isn’t just for snippets of text. While this does depend on the itty.bitty.site web host to provide the decoding framework, the decoding is done totally in your browser and the code is open source. What that means is you could host it on your own server, if you wanted to.
At first, this seems like a novelty until you start thinking about it. A small computer with an Internet connection could easily formulate these URLs to create web pages. A bigger computer could even host the itty.bitty server. Then there’s the privacy issue. At first, we were thinking that a page like this would be hard to censor since there is no centralized server with the content. But you still need the decoding framework. However, that wouldn’t stop a sophisticated user from “redirecting” to another — maybe private — decoding website and reading the page regardless of anyone’s disapproval of the content.
Continue reading “Tiny Websites have no Server”
Last month we posted a tutorial from Hub City Labs on making your own PCBs at home. At the time, Hub City was hosting their hackerspace web site on a tiny vps graciously provided by a member. As you might expect, the throngs of Hackaday readers turned Hub City Labs’ server into a pile of molten slag and made their admin’s hair a little more gray. Their web site is up again, and Hub City provided a tutorial on protecting your server from the ravages of being Slashdotted, Farked, Reddited, and even Hackaday’d.
The solution for the first few hours was to transfer Hub City Labs’ site to an Amazon EC2 instance. Since then, they’ve moved over to a Debian EC2 instance that is able to handle half a million pageviews an hour for a WordPress site.
This amazing capability required a good bit of optimizations. A WordPress installation is set to run cron tasks on every page load; not good if you’re going to see thousands of hits every minute. The guys added define(‘DISABLE_WP_CRON’, true) to their wp-config.php file and set all the background tasks – checking to see if a page should be updated – to a fixed schedule every minute or so. Along with an increase in the WordPress cache, these optimizations increased the number of pageviews an hour from 1500 to 60000.
To get up to half a million pageviews an hour, the EC2 instance was loaded up with Varnish, a front-end cache that really speeds things up.
The result – 375 million pageviews for $15 a month – is more than Hub City Labs will probably ever need. The nature of hackerspace web sites, though – light load until Hackaday, Slashdot, or Reddit figure out you did something cool – means hosting on an expandable EC2 instance is probably the way to go.