anderiv

It absolutely does make sense for servers. One frequent pain point with virtualized systems is that (at least in a VMware vCenter DRS-enabled cluster), you never know what physical host a specific VM will be on at any moment. This is a problem for software that requires a USB license dongle (many FlexLM-managed software have this requirement).

Anyway, in this situation, you would have one physical, bare-metal linux "usb dongle server", which then shares out its USB devices to one or more other linux VMs. After doing this, VMs can migrate between physical hosts without losing access to their license dongle.

There are purpose-built physical USB->IP devices out out there now, but they're quite expensive. This new functionality would allow admins to emulate this functionality for a fraction of the cost of a purpose-built device.

In setting up (and verifying) several VoIP E-911 systems and other PSTN phone systems, I've made dozens of "test" calls without issue. When the dispatcher answers, just tell them that you are testing 911 service and that you would like to verify that you got connected to the correct dispatching center.

I've never had one of the dispatchers become upset at this - they want your 911 calls to succeed just as much as you do.

That, and the ~6 watt current draw at full tilt (at least that's what it was when I was load testing a couple of 2d3 boards) is very nice on the utility bill. Their newly-released APU boards are very nice, with GigE interfaces, increased RAM, and much faster CPUs.

I think you're ignoring (or are maybe just innocently ignorant of) one key topic: state.

Stateful firewalls are exactly that - when an internal client initiates a TCP socket, for instance, the firewall knows to expect a series of replies back from whatever system the client contacted and is able to allow that traffic through.

In netfilter (iptables) land, this is handled by the "RELATED" qualifier, so you instruct the firewall to allow any related packets back through to the client.

See my comment on the parent...having a public IP address does not mean that it's accessible from the internet.

This doesn't change with the vast majority of residential IPv6 deployments. Many people conflate having a public IP address with not having a firewall. This is not the case at all. Yes, internal clients will get public, routable IPv6 addresses. They are still behind a firewall, though, and you have just as much control over ingress and egress traffic as you did before.

The only part of this robot I'm skeptical of is the "grind-on-demand" portion. As someone who regularly grinds my own chuck to make hamburgers, I've learned that in order to get a consistent, even mix between fat and meat, it's absolutely critical to grind the entire roast (actually it's ground twice), and then mix to evenly distribute things.

If this were truly grind-on-demand, it would be quite hard to guarantee a consistent product (which is a hallmark of most fast food restaurants).

It's worth calling and talking to your sales rep about this. I've found AWS to be surprisingly accommodating with pricing.

Yep, it's possible, but to get them to sign a BAA with you, you need to agree to only use a very small subset of the AWS products (basically just EC2 and S3. No RDS, no ELB, etc.). Additionally, any EC2 instance you provision need to have the "single tenancy" bit set on your instances. Which, when set, you start getting hit with a very high flat per-day "single tenancy" fee in addition to higher hourly costs for your instances.

That's what I thought as well, but recently found out otherwise. While it is true that, for buckets in the US Standard region, requests are routed to the closest endpoint, the data still only lives in one location.

To clarify by way of an example, say you're putting data into S3 from an EC2 instance in us-east-1. Those requests will end up being handled by the NVA US Standard S3 endpoint, and the data will only be stored in NVA. If try and retrieve that key from an EC2 instance in us-west-2, that request will indeed be routed to the PNW S3 endpoint, which will see that it doesn't have a local copy of the object and will need to retrieve it from NVA before serving it to you. That object will be cached locally in the PNW endpoint for an unknown amount of time, after which it will need to be retrieved from NVA again.

All of this information was from a recent support ticket I had open with AWS while trying to troubleshoot poor S3 performance.

The verbage they use to describe the US Standard region is quite confusing, leading a lot of people to assume that it provides geographic redundancy when it actually does not provide this at all.

What is what so expensive?

Yes, that is a possibility. SNI will also become a more realistic option as older devices get retired. I've implemented several sites with SNI, and as long as you're aware of what devices/browsers/OSes will be connecting to your site (and their SNI support), things work great.

It's not an issue with multiple IP addresses, but rather with being able to host multiple SSL-enabled domains on a single IP (which is what CDNs need to do). That is where SNI[1] comes in, along with all of its compatibility issues with older network stacks.

[1] http://en.wikipedia.org/wiki/Server_Name_Indication

It's the Magical Animal!

http://www.youtube.com/watch?v=3EHsbIcV-6I

No, that is the release you need to use to remove the PS from the chassis. You can see the two latches it moves on the right side of the case, a cm or two from the back.

I just checked with Linode support, and their backup pricing will be adjusted to match with the old rates as well. So if you’ve been paying $5/month for backup service, your price will stay the same post-migration.

That is why fail2ban allows you to configure a whitelisted IP (your office, VPN, etc.) that will never get banned.

I like the KISS aspect of this, though for accountability purposes, I prefer each user to have their own account.

One correction for you: the sshd_config lines should have no "=" symbol.