I have used Linux under one form or another since Slackware around 1994. Not sure when exactly, but the kernel was definitely pre-1.0 and ELF was not yet a thing. Since as long as I can remember, people have said "xxxx is the year of Linux on the deskop". I haven't found any good citations for this, but there is a reddit thread on the subject.
Linux is all around us, most predominately in servers, but also in IoT devices, our infomatics systems in our cars, our watches, our streaming devices (Roku, Chromecast, Fire sticks and the like), Amazon Echos, light switches, printers, etc.
I've been doing some experimentation with creating bare bones systems. These come with a minimal of operational issues - fewer moving parts requires less upkeep, have less code for security issues, etc.
Golang is a fantastic language for this, as it is easy in Go to produce a statically linked binary (outside of Windows). Due to the nature of Windows some dynamic linking is necessary. A static binary (admittedly lacking C support) can be generated with a command similar to this:
I've read the Rust book a year ago but never actually programmed Rust in anger until this past week. I intend to do more with Rust, but wanted to document my initial thoughts on the language as a consumer, partly for posterity, partly to avoid stockholm syndrome, and partly I think it might be useful to anyone on the Rust team interested in the out of box experience with the language.
Recently I picked up a new Rasberry Pi Zero W and was excited but also lamenting the fact that I'd have to dig out a keyboard and mouse. Being lazy, and being willing to work really hard to remain lazy, I was determined to find a way around this.
I grabbed a MicroSD card and put Raspian Jessie Lite on it. I then extended the root partition which I found easier to do before first boot since a) it was a virgin distro install and b) since I wasn't doing it from the running system there were no reboots involved - I could simply eject the card and plug it back in to refresh the block device listing.
Recently there have been discussions about the advantages and disadvantegs of using Hashicorp's Terraform vs AWS CloudFormation for infrastructure as code on AWS. While these products change continuously, here's a snapshot summarization of the advantages of each system.
AWS Cloudformation Tighter integration with AWS Services: In my opinion, this is the biggest draw to using CloudFormation. You simply can't use Terraform for things like AWS Service Catalog. Service Catalog in particular is a huge benefit to acheiving agility with control, and to avoid using it simply because your processes are Terraform-based would be a shame.
If you have worked with AWS GovCloud, you know it is a very different region from most other AWS regions. It requires a seperate account, linked to a standard AWS account, and uses IAM users only - root users are not allowed at all. This has always been a best practice, but in GovCloud, you have no choice.
GovCloud also has fewer services than other regions. At the time of this writing, AWS Marketplace is one of the services that is missing.
I tend to move around machines quite a bit, especially when traveling. As such, I thought it would be useful to have a portable environment on a USB stick. Since I don't know what type of machine I would be walking up to, this needed to support UEFI and BIOS. I wanted an actual install on a USB stick, not simply a live environment.
I chose Arch linux because I like the lightweight do-it-yourself philosophy and had heard good things about the pacman package manager.
Getting Windows 10 on EC2 isn't difficult, but perusing the documentation can lead to confusion.
You can't mount an ISO to an empty VM the way you might do in VirtualBox, so this process requires a local copy of the VM to be created, then using the aws ec2 import-image command to create the AMI. When done, not only will the image be ready for EC2, but it will be detected as Windows by AWS and be configured such that it has many of the same AWS-specific features as other Windows AMIs provided by Amazon.
Containers are a great unit of deployment. They're a great way to isolate code, reduce attack areas, and, well, contain a service. When it comes to deployment in production, operational attributes of containers must be considered.
Container technology can enable significant density (described in terms of containers per vm) while retaining isolation between services. However, is this something we want to take advantage of operationally? Two significant issues with pushing for >1 container per vm come to mind.
Since I'm working for AWS, I want to understand fundamentally the workings of the open source Xen Hypervisor. I also want to dig more deeply into the emerging Unikernel ecosystem. Of course, I want to do this on Amazon EC2, because generally I prefer to assume my laptop is ephemeral and could be lost, stolen, dropped, etc. However, Xen doesn't nest well, so putting Xen in a virtual machine on top of Xen is a little bit crazy-talk.
index.html is an interesting beast in S3. S3 is an object store. It is often mistaken for a filesystem, but it is not. It is also not a web server, though it can pretend to be.
CloudFront is a CDN, and as such, it is also not a web server, though it does serve web content to users. All this makes for a strange situation for our friend, index.html.
index.html is generally used as a default document in web servers.
The process I've put together for publishing this blog allows for automatic publish to the web as soon as I git commit/git push. This post describes how this is done.
As background, this blog is hosted on Amazon Web Services' S3 service with CDN capabilities and SSL termination provided by CloudFront and Amazon Certificate Manager. This last service is extremely new, to the point that I obtained and assigned the certificate to CloudFront the very day CloudFront integration was available.
I've decided to add Disqus comments to the site. Having a blog without comments is just...not a blog. That said, I'm not particularly happy with the amount of overhead it adds to the page. My base configuration (no images, no comments) involves a total of two requests to the site for full rendering (three if you count favicon business, which I don't). The blog is delivered via AWS S3 and CloudFront, which gives me CDN capabilities.
I've been meaning to document my home backup strategy for quite some time. In the process of evolving the design, I've tried to address the following concerns:
Rapid restoration of data in the event of an outage (RTO) Minimal data loss from an incident (RPO) Recovery from accidental deletes Recovery from malicious deletes, such as ransomware Recovery from cosmic ray damage on hard drive platters Recovery from total destruction of the house Recovery from a failed hard drive Nice, but not too expensive.
I am transitioning to a new blog host and new, well, everything regarding my blog. I had the following goals when creating this new blog site:
Remove dependence on blogger.com Change the url. It's now more common to not have "blog" in the url Reduce the page size/number of requests Improve the speed of the site (see above, plus CDN) SSL everywhere This is still a work in progress and the styling will be updated moving forward, but I'm a fan of dark themes, so this is roughly where I'm going.