Today I learned:
I recently upgraded an ancient Linode virtual server from Ubuntu 9.04 to 9.10. When I attempted a reboot it would fail – which wasn’t totally unexpected:
mount: mount point /dev/pts does not exist mountall: mount /dev/pts [1070] terminated with status 32 mountall: Filesystem could not be mounted: /dev/pts mount: mount point /dev/pts does not exist mountall: mount /dev/pts [1074] terminated with status 32 mountall: Filesystem could not be mounted: /dev/pts init: mountall main process (1065) terminated with status 4 Mount of root filesystem failed.
Fortunately Linode has a good set of rescue documentation. After messing around with various suggestions on how to fix this problem I ended up with the following /etc/fstab:
proc /proc proc defaults 0 0 /dev/sda / ext3 noatime,errors=remount-ro 0 1 /dev/sdb none swap sw 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0
This, however, did not seem to help. After an hour of random trial and error I finally decided to toggle the following option on the Linode configuration edit page to “no”:
For reasons that are still unclear to me, this mounted /dev/pts properly and the rest of the boot sequence ran without a hitch.
When running Windows 7 as a guest OS on Virtualbox 5.0.16, Virtualbox would after a short while run on maximum CPU load. Looking at the Windows Task Manager it turned out that svchost.exe was running at full speed, eating up a lot of memory as well. The solution was to go to the Services tab and stop wuauserv (the Windows Update server). This would immediately bring the load down on both the guest and the host (OS X 10.11.4) operating system.
This is a review of “Django Essentials” from Packt Publishing, but first some background:
Around 2007 I used to be fairly fluent in Django, this after having built a substantial Django web application from scratch. These were the days before Django 1.0. While all the necessary documentation was there, the framework had some rough edges and peculiar design choices.
Still, Django made a lot of sense. I had previously dabbled with Ruby on Rails but it never really clicked with me. Once I grew comfortable with the Django mindset I never looked back.
Time passes and I move on to other projects. I tried to keep track of what was happening in the world of Django, but lost interest around version 1.2. Fast forward to 2014, and I suddenly get the chance to develop with Django again. By keeping an ear on the tech grapevine I have a rough idea of the major innovations to Django since it dropped off my radar. Nonetheless, the devil is in the details and I dive into the Django documentation.
You can say a lot of good things about the Django docs. For starters, it is very comprehensive and quite well organized. Still, it is not a good choice for a learner or for someone who just need a quick refresher. The wealth of information is a good thing when you need a solution to a particular problem. It is not a good thing when you just want to figure out how it all the pieces fit together. There is the Django Book as well but it is terribly outdated.
Luckily, the good folks at Packt Publishing were kind enough to offer me a review copy of the recently released “Django Essentials” by Samuel Dauzon at just about this time.
Is is a nice, short read, kicking in at about 150 pages. If you skip implementing the code examples, it should not take you many hours to get through it. That being said, by working your way through the examples you will get a clear sense of how Django will let you make your web application come to life.
What I particularly like about this book is that it puts Django in its proper context. Best-practice tools and techniques such as Nginx, jQuery, AJAX, PostgreSQL and virtualenv are introduced, meaning that you will have an idea of how to make them work with your Django application.
All the major Django concepts are covered in a pedagogic manner. As an example, classic views are introduced first. Later on, class-based views are introduced, showing you how they can save you a lot of time—while reminding you that classic views still are useful in certain situations. A nice touch is that South, the (soon to be deprecated) Django data migration tool, is introduced before you write your first Model class.
The book is well written and nicely laid out. One minor annoyance is that some of the code examples could have been better formatted. Another nitpick is the UserProfile model example in the models chapter. For the novice Django developer it should be pointed out right away that the secure choice is to always use the builtin User class rather than trying to roll your own. Fortunately this is explained later in the book.
Given that the book spends a bit of time on the recommended ecosystem around Django, it would have been nice to see mentions of other tools such as Bootstrap and the various third-party amendments to Django which makes it a lot more powerful. Still, the brevity of this book is one of its strengths.
All in all, “Django Essentials” is a great read and comes highly recommended if you know a little bit of Python and want to level up to web application development.
AWS just cut their outbound data transfer rates from $0.17 to $0.15 per GB/month up until 10TB. I have updated my previous comparison between Go Daddy and AWS with the latest numbers.
UPDATE 1: Corrected the bandwidth calculation in the formulas for AWS.
UPDATE 2: Added new data for the February 2010 AWS data transfer price reduction.
In a previous posting I did a cost comparison of a reserved Amazon Web Services EC2 instance and a comparable dedicated server from Go Daddy. Amazon recently announced a set of price cuts for reserved instances, so an updated comparison is in order.
The server configurations I’m comparing are the same as last time:
| Go Daddy | AWS | AWS (new) | |
|---|---|---|---|
| Processor | Core 2 Duo 2.66 GHz | 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each) [1 unit equals a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor] | 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each) [1 unit equals a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor] |
| Hard Drive(s) | Dual 300GB drives | 850GB of instance storage | 850GB of instance storage |
| Memory | 3.2GB | 7.5GB | 7.5GB |
| 1-year plan, w/o bandwidth | $2,483.46 | $2,351.20 | $1,962.40 |
| 3-year plan, w/o bandwidth | $6,622.56 | $5,153.60 | $4,557.20 |
I have added an extra column for the new EC2 reserved instance pricing scheme. Notably, the prices for the Go Daddy options haven’t changed in the last six months. For the 1- and 3-year AWS plans, the total costs have dropped by $390 (17%) and $600 (12%), bandwidth excluded.
(For the full discussion, refer to the previous posting.)
When including bandwidth use, the updated table looks as follows:
| 1GB/mth | 20GB/mth | 100GB/mth | 400GB/mth | 800GB/mth | |
|---|---|---|---|---|---|
| Go Daddy, 1-year plan | $2,483.46 | $2,483.46 | $2,483.46 | $2,483.46 | $2,723.34 |
| AWS, 1-year plan | $2,353.24 | $2,392.00 | $2,555.20 | $3,167.20 | $3,983.20 |
| AWS, 1-year plan (Aug 2009) | $1,963.24 | $2,002.00 | $2,165.20 | $2,777.20 | $3,593.20 |
| AWS, 1-year plan (Feb 2010) | $1,963.00 | $1,997.20 | $2,141.20 | $2,681.20 | $3,401.20 |
| Go Daddy, 3-year plan | $6,622.56 | $6,622.56 | $6,622.56 | $6,622.56 | $7,342.20 |
| AWS, 3-year plan | $5,159.72 | $5,276.00 | $5,765.60 | $7,601.60 | $10,049.60 |
| AWS, 3-year plan (Aug 2009) | $4,559.72 | $4,676.00 | $5,165.60 | $7,001.60 | $9,449.60 |
| AWS, 3-year plan (Feb 2010) | $4,559.00 | $4,661.60 | $5,093.60 | $6,713.60 | $8,873.60 |
With the old pricing, the AWS option was preferable unless bandwidth exceeded 100GB per month (for the 1-year plan) or 250GB per month (for the 3-year plan). After the August 2009 price cuts, AWS became an even more competitive option, although one that still falls behind for high bandwidth scenarios.
In February 2010, the price for outgoing data traffic dropped from $0.17 to $0.15. With the 3-year plan, AWS now matches Go Daddy up until almost 400GB per month.
Addendum: Some of the background data used in this posting:
SimpleParse is a fast Python single-pass parser generator that I use regularly. When I finally made the move onto Python 2.6 it turned out that there is no pre-compiled package for 2.6 on Windows. So, here is my procedure for compiling the source package on Windows Vista.
1. Install Cygwin if you don’t already have it on your system, and make sure that the version of Python you are installing SimpleParse for is on either the system or the Cygwin path.
2. Download and install Microsoft Visual C++ 2008 Express Edition. You should ensure that you have the latest Vista service packs installed before attempting this. If the installer quits on you then just reboot the computer and try again. Without this installed, you wil get an ‘Unable to find vcvarsall.bat’ error.
3. Download and unpack the SimpleParse 2.1.0a1 source. Using the Cygwin shell, place yourself in the root source directory.
4. If we try to run python setup.py install at this point, the Visual C++ compiler will complain:
stt/TextTools/mxTextTools/mxTextTools.c(149) : error C2133: 'mxTextSearch_Methods' : unknown size stt/TextTools/mxTextTools/mxTextTools.c(920) : error C2133: 'mxCharSet_Methods': unknown size stt/TextTools/mxTextTools/mxTextTools.c(2103) : error C2133: 'mxTagTable_Methods' : unknown size error: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe"' failed with exit status 2
We have to add the following lines to stt/TextTools/mxTextTools/mxTextTools.c, starting at line 148 (before staticforward is used for the first time):
#ifdef _MSC_VER #define staticforward extern #endif
5. with is a Python 2.6 keyword, meaning it can’t be used as a variable, as is the case in the SimpleParse source code. So, we have to replace it with something else:
$ sed -r 's/with/with_t/g' < stt/TextTools/TextTools.py > tmp.txt $ cp tmp.txt stt/TextTools/TextTools.py
6. Finally, run python setup.py install as usual.
“Writing, Jen thought, seemed like a very sad pursuit. Like painting, but worse. At least paintings had color. Writing, though, was just black marks on paper, standing in for people and objects and events that could never be seen or felt. It seemed pathetic in a way. Nouns were the saddest words of all, trying so hard to summon real objects to life.”
Jon Raymond, “Words and Things” (Livability)
The connection between EndNote X2 and Microsoft Word 2007 seems to get corrupted on a regular basis on my Vista setup. Based on hours of web searching and trial and error, here is a short summary of ways of getting it working again. Use these when you get error messages such as ‘server threw an exception’, ‘server execution failed’, and ‘invalid class string’.
In prioritized order:
There are other possible problems, especially when upgrading from older versions, but these actions usually work for me.
(For Norwegian readers: If you are using the Norwegian version of EndNote, the error messages will be ‘ugyldig klassestreng’ or ‘serverutføringen mislyktes’.)
UPDATE 1: There is now an updated version of this posting. The new version incorporates the August 2009 AWS reserved instance pricing changes.
UPDATE 2: Corrected the bandwidth calculation in the formulas for AWS.
Amazon Web Services just announced a new reserved instances pricing plan. In short, this plan allows you to reserve EC2 instances for a 1 to 3 year period by paying a one-time reservation fee. The hourly rate for reserved instances is considerably lower than for regular spot-market instances. For comparisons sake, a large standard on-demand instance will set you back $0.40 per hour, while the large standard reserved instance is only $0.12 per hour.
With the old pricing scheme, hosting a web service on AWS instead of on a dedicated server was not a very cost-competitive option, at least not for resource-intensive applications. For my web site, Eventseer, I require at least a large standard instance—at $0.40 per hour for 24/7 operation (bandwidth costs not included), this turned out way too expensive compared with offerings from traditional dedicated server providers.
To see if the new pricing scheme fares any better, I have compared the cost of an AWS EC2 reserved large instance with a similar dedicated server from Go Daddy:
| Go Daddy | AWS | |
|---|---|---|
| Processor | Core 2 Duo 2.66 GHz | 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each) [1 unit equals a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor] |
| Hard Drive(s) | Dual 300GB drives | 850GB of instance storage |
| Memory | 3.2GB | 7.5GB |
| 1-year plan, w/o bandwidth | $2,483.46 | $2,351.20 |
| 3-year plan, w/o bandwidth | $6,622.56 | $5,153.60 |
I’m not sure how the 4 EC2 compute units compete with a dedicated Core 2 Duo 2.66 GHz. This probably also depends on the nature of your application. Note that the AWS solution has twice the amount of memory. From what I can see, you can not get a Go Daddy dedicated server with more than 3.2GB of memory, while AWS offers up to 15GB on the extra large instances.
When disregarding bandwidth costs, AWS suddenly makes a lot of sense. As bandwidth use is highly application-dependent, let’s consider a few different bandwidth use scenarios:
| 1GB/mth | 20GB/mth | 100GB/mth | 400GB/mth | 800GB/mth | |
|---|---|---|---|---|---|
| Go Daddy, 1-year plan | $2,483.46 | $2,483.46 | $2,483.46 | $2,483.46 | $2,723.34 |
| AWS, 1-year plan | $2,353.24 | $2,392.00 | $2,555.20 | $3,167.20 | $3,983.20 |
| Go Daddy, 3-year plan | $6,622.56 | $6,622.56 | $6,622.56 | $6,622.56 | $7,342.20 |
| AWS, 3-year plan | $5,159.72 | $5,276.00 | $5,765.60 | $7,601.60 | $10,049.60 |
Conclusion: With a 1-year plan, AWS is the cheapest option until you reach about 100GB of external bandwidth per month. With the 3-year plan, the AWS bandwidth cost isn’t a problem until about 250GB per month. (Bandwidth is “free” with Go Daddy dedicated servers up until 500GB per month; after that it’s an extra $19.99 per month until you reach 1,000GB).
Considering that the AWS solution gets you twice the amount of RAM, AWS suddenly seems a very viable option even for web service hosting—as long as you’re not expecting extreme
amounts of traffic. However, once you get popular the outgoing data transfer pricing will take its toll.
Addendum: Some of the background data used in this posting: