Being able to put feet down requires a more upright and open riding position.

Removing that requirement enables a recumbant seating position (for better aerodynamics) and a fully-enclosed cabin. Making the cabin fully-enclosed allows for better protection from weather, better soundproofing, air conditioning, etc.

The key to this one is that you don't need to put feet down when stopped, so it can be recumbant and fully-enclosed.

Some really intricate parts are cheaper to 3D-print than to try and cast/forge/machine traditionally. Think hollow structures with stiffening ribs or cooling channels inside, or other similarly complicated shapes. The SuperDraco rocket engine falls into this category (though of course also is a small production run).

With managed hosting, the provider handles support, backup/restore, etc. Typically with "the cloud" the resources are unmanaged. The end-user is responsible for all of that stuff.

I don't believe Amazon themselves offer managed services, but there are lots of other companies that will sell you managed services built on AWS.

Nobody is saying they were legally responsible to prevent crime.

People *are* saying that they were poor businessmen who didn't plan for disasters. (What if the cloud provider failed catastrophically, or they lost all the passwords, or any number of other catastrophic events?)

Even for VoLTE, why should your voice get priority over my data? What if my "data" is actually voice via a different app?

Arguably, all packets should be shaped initially based on the subscription plans of the subscribers without regard for data type. Then *within the packet stream of an individual subscriber* they could prioritize based on traffic type, but it should be up to the subscriber to indicate whether they want this to be done, what should be prioritized, etc.

KVM and VMWare Player can run VMs simultaneously without any problem.

and found that they got better mileage with the "unnecessarily complex dual drive train" than they did with the charging-only engine.

1) It's not about how much you eat, but how much your body converts to fat. I went on Atkins and lost quite a bit of weight while still eating lots of calories.

2) If you severely cut down on calories, your body can become more efficient at using the calories it does eat.

So the trick is to convince your body that it's not hungry, doesn't need to be efficient, and doesn't need to store fat against future needs.

They're mostly empty calories.

The Mellanox driver code I saw was pretty messy, especially the SR-IOV support. And their device model is sort of weird for anyone used to "traditional" ethernet hardware. But they're really the only game in town for 40gig.

In contrast, the Intel 10gig drivers are reasonably clean, follow the same device model as their other ethernet hardware, and their datasheets are available for anyone to download.

For exactly the reason that you describe, a kernel driver that is intended to be built on many different kernel versions really shouldn't be making assumptions based on the version number, it should test for the actual desired functionality.

The simplest solution is:

1) ISPs apply traffic shaping to each subscriber separately, without looking at packet type, source, destination, etc. The only criteria are which subscriber the packet belongs to, and what level of subscription they've paid for.

2) As an optional step (opt-in or opt-out) the ISP can do QoS within the packets belonging to a particular subscriber. This would only affect that subscriber, nobody else. Ideally this would be under the control of the end-user in some way, via ToS packets, classification rules, etc.

To me, Net Neutrality means that all traffic (regardless of far end *or* type) should be treated equally.

The only fair way to allocate resources on a subscriber network is by doing traffic shaping based on the subscriber plan, *without looking at traffic type*.

Suppose we've both paid for an identical subscription. I use my entire bandwidth for streaming video and torrenting, you use your entire bandwidth for videoconferencing. Traditional QoS would give your packets priority over mine. Since we're paying the same, that makes no sense!

The ISP should shape both our streams based on our subscriber plans. As an optional step they could apply QoS to the traffic belonging to each individual subscriber, but that would only affect the traffic for that specific subscriber.

Why should your videoconferencing packets get priority over my netflix stream?

If we've both paid for equivalent plans, then we should have equal use of the network.

The only truly fair option is for ISPs to weight traffic between subscribers based on their plans, without looking at traffic type. Then within the traffic belonging to a single subscriber they could (if approved by the subscriber) do QoS based on traffic type.