01 September 2014

NetBSD on Banana Pi

The "Banana Pi" is a new(ish) ARM-based board, aimed at being "mostly-compatible" with the Raspberry Pi - which they have accomplished to a degree.  The Banana Pi has a newer, ARMv7-based core, though, so has the potential to be a lot faster.  I'm always looking for new hardware to test NetBSD on, so I thought I'd give it a shot.  At about $65, it's more expensive than the Raspberry Pi, but since it has more on board (SATA, Gigabit Ethernet, dual-core CPU, 1GB RAM), it's a pretty good deal. The one I ordered came yesterday, so I fiddled around with it bit trying to see how fast I could get a kernel booting.  I downloaded the "Bananian" Linux image, booted to make sure it worked, and investigated how the boot process worked.

17 October 2012

NetBSD 6 is out!

I pulled the trigger on the release of NetBSD 6.0 this morning, and a huge weight has lifted off my shoulders.    Here's a quick rundown on what I like about NetBSD 6:


  • Multiprocessor support for Xen DomU ("guests").  This one is huge!  It puts NetBSD in a great position on various Xen hosting platforms, such as Amazon EC2, Rackspace, Panix and others.
  • NPF, the new NetBSD Packet Filter.  It's still a little rough around the edges, but it's solid and it promises to have great performance, as it's written from scratch with multi-core CPUs in mind.
  • Great support on low-power embedded platforms, such as lots of new ARM platforms and PowerPC  MPC85xx.  I just built myself a router for home out of a DreamPlug running NetBSD 6.0, with NPF as a packet filter.  It's working great, and only draws between 9 and 10 watts of power!
  • NetBSD's phenomenal build infrastructure.  This isn't new, but it bears repeating:  if you're developing for NetBSD, you can build it on almost any POSIX platform!  I personally have built on NetBSD, FreeBSD, Ubuntu, Centos, and MacOS X (recently).  It's one feature I wish all other systems would adopt.
Now to catch my breath and prepare for 6.1, in which we hope to have full support for Raspberry PI and some other new platforms...

26 May 2012

NetBSD 6 is getting closer!

With the announcement of NetBSD 6.0_BETA2 availability, NetBSD 6 comes closer to reality.  There are still some outstanding issues, but we're getting closer!

We're hoping to have a release candidate out in a month, and perhaps the final release in 7 or 8 weeks!

09 May 2012

Supporting local business, and reliability.

I work out of my house, and so having reliable Internet service is important to me.  I don't make much money at the moment, so things being inexpensive is also a plus.  Additionally, being able to keep the dollars I spend local is a great thing - I *like* doing business with people nearby for a lot of reasons.  So, I was thrilled a while back (a year, maybe two) when I learned of a local wireless ISP who was lighting up my neighborhood - and their HQ in the Mission is about a mile from my house!

Photo by Adrian Black, on Flickr
So, I signed up.  I believe I was a relatively early customer, in that they didn't charge me a monthly fee (just an install fee for the wireless bridge on my roof) for a period of a couple of months, because their residential wireless service was in beta.  They eventually got me hooked up (they were busy at first announcement, no big shock there), and I was pleased with the speed I was getting - it was about the same, or slightly better than the speed I was getting with Astound, the number 2 local cable Internet provider, at approximately the same price per month (once billing began).  I was very happy during the beta period, getting decent service for free.  There were a few glitches, but I didn't mind - I kept my Astound service during this period, so when push came to shove, I could switch back if there were problems.   I wound up switching back two or three times during the months I was a beta customer.  No big deal.  Then, the beta came to an end and they started billing me, so I canceled my Astound Internet service after about a month, not wanting to get double-billed.  Because of Astound's bundle pricing, it winds up costing me slightly more to get my Internet service from another ISP, but when it's working well, the speed is higher.

Things were OK for a while.  I started noticing occasional glitches during the day, but I didn't think anything of it.  Then, I started paying attention to their Twitter feed (which one of the founders tweets on), and realized that they were fairly regularly doing network maintenance *during the day*.  Hm.  OK, small business, small staff - I guess I get it.  But as I paid fairly close attention during the next year, I noticed a *lot* of outages.  Most were small, but a few were 10-20 minutes.  One lasted multiple hours(!). Sometimes it was maintenance, sometimes genuine problems.  The practical upshot is that over the last year-plus, I've spent probably 15-20 hours troubleshooting (to rule out my local setup) or waiting for fixes for what eventually proved to be issues on my provider's network.  They're really nice, and very helpful, but I start to wonder:  at what point is it just not worth it to me?

Unfortunately, I think I'm reaching that point.  Luckily for me, being in San Francisco, there is at least one more local-ish provider I can choose from.  I don't like the idea of spending more cash on setup fees, but I'm also kind of fed up with problems.  I understand that I'm not paying for business service - but I also feel like network issues should be the exception, and not the norm.  It feels like hardly a week goes by without something...  What do others think?  How much should I be willing to put up with?

22 April 2012

Amazon EBS Volume Failure Notice

 Ever wonder what happens when Amazon loses your data?  I got this in email the other day:

Dear Jeffrey C Rizzo,

Your volume experienced a failure due to multiple failures of the underlying hardware components and we were unable to recover it.
Although EBS volumes are designed for reliability, backed by multiple physical drives, we are still exposed to durability risks caused by concurrent hardware failures of multiple components, before our systems are able to restore the redundancy. We publish our durability expectations on the EBS detail page here (http://aws.amazon.com/ebs).


Sincerely,
EBS Support

Fortunately, there was nothing of importance on that volume, and I had a snapshot which was unaffected by the failure but it's a reminder that just because something is in "the cloud" doesn't mean that it's necessarily safe.

On their EBS detail page, Amazon says that a single volume with less than 20GB of data changed since the last snapshot should expect an annual failure rate of between 0.1% and 0.5% - or between 1 and 5 out of every 1000 volumes should fail annually, where failure is defined as complete loss of the volume.  This is better than commodity hard drive failure rates, but still in the range where they can and do happen to ordinary users.

A simple way to improve your failure rate is to snapshot often;  EBS snapshots are stored on Amazon's S3 service, which guarantees 99.999999999% durability and 99.99% availability.  If you get a volume failure, you have only to roll back to the most recent snapshot, and you've only lost the data which has changed in the interim.   A more robust and high-availability solution would be to mirror writes to volumes in different availability zones, but that's another project for another day.

Keep your data safe!





20 April 2012

NetBSD on Amazon EC2

As some of you know, I've been maintaining Amazon EC2 AMIs running NetBSD for a little while now, and after a few requests, I'm happy to say I've finally cleaned them up to a point where I'm comfortable sharing them with others.

The original scripts these are based on were written by Jean-Yves Migeon, another NetBSD developer.  I've cleaned them up and modified them quite a bit.

To get started rolling your own NetBSD AMIs, you'll need an Amazon EC2 account, and a NetBSD system with the misc/ec2-api-tools package installed.  (Note that as of this writing, you may need to install the required openjdk7 package from source, rather than using a binary package from ftp.netbsd.org;  hopefully this will be fixed soon)  Once the package is installed, you should follow the Amazon documentation on Getting Started with the Command Line Tools for more infomation on the commands that the ec2-api-tools package provides.

The actual scripts can be downloaded here, or you can check them out with CVS from anoncvs.netbsd.org, in the othersrc module, in share/examples/ec2.  Be sure to read the README!

26 January 2011

Microsoft, NetBSD, and extensible computing

Antti Kantee, a member of the NetBSD core group (as well as the author of the really cool rump subsystem - which, among other things, has helped fuel the explosion of automated testing which has been occurring recently) has just imported a new port to the NetBSD source tree:  eMIPS (Extensible MIPS), a dynamically extensible processor architecture from Microsoft Research.  The actual port of NetBSD to the platform was done by Alessandro Forin and Neil Pittman of Microsoft, and Microsoft has generously donated the code to The NetBSD Foundation.

I'm still just starting to look into the capabilities, but eMIPS appears to support application-specific hardware optimizations and even machine instructions.  The overview on Microsoft Research's project page for eMIPS says: "Have you ever thought of building your own processor or maybe just defining your own machine instructions? With eMIPS now you can."  Sounds like a really interesting avenue for research, and I eagerly await cool applications based on it.