If you're using VT-d/IOMMU to assign a particular piece of hardware to a particular VM then that is not actually paravirtualized...you're basically running the normal driver in the VM.
Paravirtualized hardware would require the host OS to have the driver for the hardware, then present a different (usually simplified) API to the guest to allow it to do things more efficiently than fully virtualizing the hardware.
As long as you've got proper redundancy (which is necessary anyway for five nines) then it's no problem to periodically reboot during a maintenance window to apply reboot-required patches.
In fact, this is a good thing since it ensures that you *can* come back from a cold boot, and it gives you a chance to run offline diagnostics.
Under deceleration the wheels keep the engine turning, which is why it can cut the fuel supply. Once you get slow enough or put in the clutch it will start feeding fuel to the engine again.
This is why you don't want to put in the clutch until you're almost stopped, in order to keep fuel shut off for as long as possible.
I get maybe 1-2 hrs of time in the evening, and I'm usually doing household chores during much of that time. Can't go to the gym because I need to be around if a kid wakes up.
I make do with an elliptical and doing body-weight exercises, but it's hard to find time.
While it may not be true in the letter of the law (IANAL, so I don't know) it's certainly true that *in spirit* you are amortizing the cost of the phone over a multi-year contract.
Thus, if you cancel the contract before the phone subsidy has been paid off, you are on the hook to pay an extra penalty to cover the cost of the phone subsidy.
Of course, the extra fees and requirements for data plans and such mean that the carrier generally makes *far* more than the equipment subsidy over the length of the contract.
but personally I think that anything being broadcast over a radio transmitter in the clear is fair game to receive, and shouldn't even count as "sniffing".
Next you're going to say I'm committing a crime by overhearing the conversation of the people sitting at the next table in a restaurant.
My university (I graduated long ago) gives a complementary email account to all allumni. Very useful for maintaining a constant address regardless of ISP.
I'm willing to stipulate that there are many many actual valid patents on things like cell phones, computers, electronics, etc. A new design for laying out microphones for noise cancellation--patent it! A new physical structure leading to better battery life--patent it! A synthetic material that is tough and scratch-resistant--patent it!
What I don't think should be valid are obvious extensions to existing technology. Like this one. It's an interesting idea...but not so original that it deserves a patent.
I also think that if someone files for a patent on something and someone else independently invents it before the patent is granted, then the patent should be void.
If you spend most of your time doing short trips, and occasionally do long trips, it makes perfect sense to rent a car for the longer trips.
I lived for multiple years owning no vehicle...I could bike to work (or bus in the winter) and on weekends I could rent a small car for $15/day. Hard to beat that.
They save the new doc needing to take the entire medical history of the patients, so it makes it more likely that the new doc buying the existing practice will keep the existing patients.
On the other hand, the new doc is actually doing the old doc a favour because by accepting responsibility for those records it means the old doc doesn't need to ensure that they are safely destroyed.
There is no reason to equate low force with being unable to type well, it's just a personal preference. You just need to get used to not pressing as hard on the keys. A cherry brown switch requires 45g of force to activate, peaking at 55g. Most people have no problems typing on keyboards using this switch, they're quite popular. The Fukka switches in your Matias keyboard are roughly 60g, so not that much more.
As for your disdain for ergonomic keyboards, you're welcome to your own opinions, but I view it as a kind of prophylaxis. Why bend my wrists awkwardly when there are keyboards out there that split and tent to keep my wrists in a neutral position? I can type perfectly fine (fast enough to keep up with my thoughts, certainly) and the problems you cite do not occur often enough to me for them to be problematic.
What metrics will tell you that someone is doing good work?
Suppose I mostly review other people's code and make suggestions for improvement, answer lots of random questions about obscure corners of various specifications, work on really tricky bugs that take a long time to track down, look at upcoming roadmaps and figure out how they're going to affect us, etc.. What objective metric do you use to measure my performance? Lines of code submitted doesn't work, bug closure rate doesn't work--there is no simple numerical statistic to measure.
Lines of code? My happiest work days are when I end up removing more code than I put in. Also, this is really easy to game.
Bugs fixed? I usually end up working on the really nasty bugs...intermittent, only occur in customer sites, and under no circumstances can you shut down the system to debug it. Some bugs take weeks or months to track down.
Hours worked? Pointless, doesn't track if you're actually being useful during those hours.
While it's easy to measure productivity if you're making widgets, its *really hard* to measure productivity if you're doing creative stuff.
I'm a full-time teleworker...I just leave the VPN software running all the time.
Email, IRC, instant message....sure, these are distractions but they are also ways for people to contact me quickly. If you have a reputation for being responsive, people are less likely to assume you're slacking off.
Also, in my case the build farm, much of the codebase (the part that isn't in git), the test labs, etc. are all only accessible via the VPN.
I've worked in teams where it was very important to get groups of people together somewhere and draw stuff on whiteboards with everyone else poking holes in the ideas or making suggestions for improvements. This is especially true when a project is just getting started and you're working out lots of details. Later on when something is mature you have a lot less scope for innovation (you're constrained by what is already there) so it's not as critical.
Yes, you can do this to some extent with technology, but it's not as good as getting a bunch of people together physically.
That said, I've been a full-time teleworker for 7 years. It works for me because I have a well-defined area of responsibility, I worked in person with almost everyone I deal with prior to moving away, and I can communicate effectively by voice/text (not everyone can do this effectively when not physically present).
KVM was introduced as a simpler solution based on leveraging the virtualization hardware in newer x86 hardware. Because it's hardware-only it doesn't have to do as much fixing-up of things behind the scenes, which meant that the code was a lot simpler.
Because it's open-source it's useful as an initial target for virtualization work within the kernel. The other virtualization solutions can build on a lot of the same kernel functionality but it's harder to see what they're doing because it tends to be more closed.
Including building entire distros from source for embedded stuff. In my experience when compiling stuff the bottleneck is the CPU, not the disk. On the other hand, when trying to dig around in hundreds of megs of git repository it's a pain to wait for a spinning disk.
If you're using VT-d/IOMMU to assign a particular piece of hardware to a particular VM then that is not actually paravirtualized...you're basically running the normal driver in the VM.
Paravirtualized hardware would require the host OS to have the driver for the hardware, then present a different (usually simplified) API to the guest to allow it to do things more efficiently than fully virtualizing the hardware.
After looking for some time I have yet to find an equivalent to garage band on Android.
As long as you've got proper redundancy (which is necessary anyway for five nines) then it's no problem to periodically reboot during a maintenance window to apply reboot-required patches.
In fact, this is a good thing since it ensures that you *can* come back from a cold boot, and it gives you a chance to run offline diagnostics.
Under deceleration the wheels keep the engine turning, which is why it can cut the fuel supply. Once you get slow enough or put in the clutch it will start feeding fuel to the engine again.
This is why you don't want to put in the clutch until you're almost stopped, in order to keep fuel shut off for as long as possible.
I get maybe 1-2 hrs of time in the evening, and I'm usually doing household chores during much of that time. Can't go to the gym because I need to be around if a kid wakes up.
I make do with an elliptical and doing body-weight exercises, but it's hard to find time.
While it may not be true in the letter of the law (IANAL, so I don't know) it's certainly true that *in spirit* you are amortizing the cost of the phone over a multi-year contract.
Thus, if you cancel the contract before the phone subsidy has been paid off, you are on the hook to pay an extra penalty to cover the cost of the phone subsidy.
Of course, the extra fees and requirements for data plans and such mean that the carrier generally makes *far* more than the equipment subsidy over the length of the contract.
but personally I think that anything being broadcast over a radio transmitter in the clear is fair game to receive, and shouldn't even count as "sniffing".
Next you're going to say I'm committing a crime by overhearing the conversation of the people sitting at the next table in a restaurant.
My university (I graduated long ago) gives a complementary email account to all allumni. Very useful for maintaining a constant address regardless of ISP.
I'm willing to stipulate that there are many many actual valid patents on things like cell phones, computers, electronics, etc. A new design for laying out microphones for noise cancellation--patent it! A new physical structure leading to better battery life--patent it! A synthetic material that is tough and scratch-resistant--patent it!
What I don't think should be valid are obvious extensions to existing technology. Like this one. It's an interesting idea...but not so original that it deserves a patent.
I also think that if someone files for a patent on something and someone else independently invents it before the patent is granted, then the patent should be void.
telling me about something that I don't realize exists, but could use.
If I don't know it exists, I can't research it.
If you spend most of your time doing short trips, and occasionally do long trips, it makes perfect sense to rent a car for the longer trips.
I lived for multiple years owning no vehicle...I could bike to work (or bus in the winter) and on weekends I could rent a small car for $15/day. Hard to beat that.
They save the new doc needing to take the entire medical history of the patients, so it makes it more likely that the new doc buying the existing practice will keep the existing patients.
On the other hand, the new doc is actually doing the old doc a favour because by accepting responsibility for those records it means the old doc doesn't need to ensure that they are safely destroyed.
the problem is funding pensions for people that haven't even been hired yet
There is no reason to equate low force with being unable to type well, it's just a personal preference. You just need to get used to not pressing as hard on the keys. A cherry brown switch requires 45g of force to activate, peaking at 55g. Most people have no problems typing on keyboards using this switch, they're quite popular. The Fukka switches in your Matias keyboard are roughly 60g, so not that much more.
As for your disdain for ergonomic keyboards, you're welcome to your own opinions, but I view it as a kind of prophylaxis. Why bend my wrists awkwardly when there are keyboards out there that split and tent to keep my wrists in a neutral position? I can type perfectly fine (fast enough to keep up with my thoughts, certainly) and the problems you cite do not occur often enough to me for them to be problematic.
What metrics will tell you that someone is doing good work?
Suppose I mostly review other people's code and make suggestions for improvement, answer lots of random questions about obscure corners of various specifications, work on really tricky bugs that take a long time to track down, look at upcoming roadmaps and figure out how they're going to affect us, etc.. What objective metric do you use to measure my performance? Lines of code submitted doesn't work, bug closure rate doesn't work--there is no simple numerical statistic to measure.
What do you use for measuring "productivity"?
Lines of code? My happiest work days are when I end up removing more code than I put in. Also, this is really easy to game.
Bugs fixed? I usually end up working on the really nasty bugs...intermittent, only occur in customer sites, and under no circumstances can you shut down the system to debug it. Some bugs take weeks or months to track down.
Hours worked? Pointless, doesn't track if you're actually being useful during those hours.
While it's easy to measure productivity if you're making widgets, its *really hard* to measure productivity if you're doing creative stuff.
Interesting that they're big on personal liberty when it comes to this, but yet they're so biased in favour of patent holders in the Eastern District
So since I wasn't part of the normal management structure they sent me all the complicated cases to make their closure rate look good...
In my case the build farm, much of the codebase (the part that isn't in git), the test labs, etc. are all only accessible via the VPN.
I can write code without the VPN, but I can't submit it or test it properly.
I'm a full-time teleworker...I just leave the VPN software running all the time.
Email, IRC, instant message....sure, these are distractions but they are also ways for people to contact me quickly. If you have a reputation for being responsive, people are less likely to assume you're slacking off.
Also, in my case the build farm, much of the codebase (the part that isn't in git), the test labs, etc. are all only accessible via the VPN.
I've worked in teams where it was very important to get groups of people together somewhere and draw stuff on whiteboards with everyone else poking holes in the ideas or making suggestions for improvements. This is especially true when a project is just getting started and you're working out lots of details. Later on when something is mature you have a lot less scope for innovation (you're constrained by what is already there) so it's not as critical.
Yes, you can do this to some extent with technology, but it's not as good as getting a bunch of people together physically.
That said, I've been a full-time teleworker for 7 years. It works for me because I have a well-defined area of responsibility, I worked in person with almost everyone I deal with prior to moving away, and I can communicate effectively by voice/text (not everyone can do this effectively when not physically present).
Running Android gets you a full-fledged OS that is also designed for low power consumption--but it's also open-source allowing for customization.
Currently she pays $12/month for a 128KB/s cable connection. Basically email, a little bit of web browsing, and audio-only skype.
KVM was introduced as a simpler solution based on leveraging the virtualization hardware in newer x86 hardware. Because it's hardware-only it doesn't have to do as much fixing-up of things behind the scenes, which meant that the code was a lot simpler.
Because it's open-source it's useful as an initial target for virtualization work within the kernel. The other virtualization solutions can build on a lot of the same kernel functionality but it's harder to see what they're doing because it tends to be more closed.
Including building entire distros from source for embedded stuff. In my experience when compiling stuff the bottleneck is the CPU, not the disk. On the other hand, when trying to dig around in hundreds of megs of git repository it's a pain to wait for a spinning disk.