Microsoft, at least, creates a stable driver KBI for entire major OS versions. With Linux, you don't even get a guarantee of source compatibility across minor versions, so unless you upstream your driver it may be broken without warning (and if you do, the person 'fixing' it may not have access to the hardware, so will just compile test it). OS X also has stable KBIs for drivers, which are versioned to allow them to be incrementally deprecated and replaced. If you try to make life easy for vendors and they still don't produce drivers, then it ceases to be your fault.
The thing I miss on OS X is the Altera tools for FPGA programming. You can get them to work on FreeBSD via some hacks, and they natively support Linux and Windows, but there's no Mac version.
Oh, and Parallels is the company that takes your money, gives you something that causes host kernel panics, and then tries to charge you more money for the version that doesn't do that. I'll stick with VirtualBox thanks. Parallels is never getting more money from me, after their staggering incompetence with Core 2 IPIs.
The typical response would more likely be to point out that Apple keyboards have a built-in USB hub with two ports in the back, so if you want a conveniently accessible port for plugging things into temporarily, the keyboard is probably closer to your hands than the front of the computer.
I was going to contradict you, because Apple didn't bother certifying 10.7 as UNIX and don't use UNIX in their marketing anymore so I assumed they'd given up, but it appears that both 10.8 and 10.9 on Intel Macs are UNIX. Interestingly, it appears that nothing is certified UNIX08 yet...
The correct way of doing this sort of thing would have been to define standard formats for all of the information and produce a set of open source libraries for manipulating this data, then require every local medical authority to be able to produce and consume these formats. Each local authority could then take the open source reference implementation and add whatever ugly code they needed to interface with their legacy system. It doesn't matter whether they use the new formats internally, or just provide a mechanism for importing and exporting. Most likely, they'd initially do the latter, but when they started to replace existing systems they'd want to make native support for the standard formats a requirement.
How does this compare to existing (coarse grained) Linux capabilities?
Linux capabilities are not capabilities in the classical sense of unforgeable tokens of authority. They are just permissions. Linux capabilities allow a non-root process to do some things as if they were root. Capsicum implements a traditional capability model, where there is no ambient authority and a sandboxed process can not do anything unless it holds the relevant capability.
How does this compare to SELinux?
They address different goals and do so in different ways. The goal of SELinux (and the FreeBSD MAC framework's type enforcement mode) is to allow a system administrator to restrict access of a particular program or user (or program-user pair) to some subset of system resources. It is very bad for application compartmentalisation, because you can't fork() a process and have different permissions for the different children and it's difficult to update the permissions on the fly (although Apple does this with their port of the FreeBSD MAC framework, to implement sandboxing on OS X and iOS, allowing powerboxes to grant permission to specific files or directories).
Capsicum is intended for application sandboxing. It is assumed that the user trusts the binary to be non-malicious, but the program author does not trust his code to be free of exploitable bugs. A sandboxed process should call cap_enter() early on, at which point it can't create any new file descriptors. In some simple cases, that's enough. For example, a sandboxed version of man opens the file containing the mdoc sources and then calls cap_enter(). Even if it's run as root, and is reading a malicious source file that exploits the troff parser and allows arbitrary code execution, it can't do anything other than write text to the terminal. More complex applications will keep open a UNIX domain socket to a (more) privileged process that can pass in new file descriptors as they're needed, after doing some application-specific policy checking.
Does this complement things like Linux's seccomp?
Seccomp is far more restrictive than Capscium and prevents even harmless system calls (e.g. getpid(), gettimeofday() - although not on platforms where these use VDSO, I believe, but others of equal utility and harmlessness are blocked). Capsicum allows a whitelisted set of calls. Additionally, Capsicum adds finer-grained permissions on file handles (for example, you can be able to read, but not mmap, or append but not seek) and a set of at-suffixed system calls that work on directory descriptors, such as openat that allows a sandboxed process to open files in a directory that it holds the relevant capability for. This means that, for example, you can give a sandboxed browser tab process a directory descriptor to a cache directory and it can write cache data there without needing any interposition from a more privileged process. It talks directly to the kernel.
Seccomp-bpf extends seccomp by allowing system calls to be blocked or allowed based on the execution of a BPF filter. This is more expressive than Capsicum (Google's first port of Capsicum implemented it in terms of seccomp-bpf, although it was slow and not complete), but it doesn't allow the policies to easily associate permissions data with file descriptors and requires you to implement a complex BPF policy.
What's the overhead compared to the above?
There is basically no overhead for capsicum. It's one extra bitmask check on each system call that interacts with a file descriptor, which is in the noise for most workloads[1].
In terms of programmer overhead, there's a summary table for the number of lines of code changed to implement sandboxing with various mechanisms in Chrome in the original Capsicum paper. Here's the short version:
There are a few big differences. The first is that SELinux is really an extension of the ACL approach: you have a big matrix with things that can do stuff, and things that can have stuff done to them, and a bit in each position indicating whether that combination is allowed. SELinux (and most ACL implementations) compress this, because a matrix with one row for every process-user pair and one column for every filesystem or kernel object would be huge. The goal of things like SELinux is for system administrators to be able to restrict the rights of certain things.
The goal of Capsicum is different. It's not intended to protect against malicious code, it's intended to protect against exploitable code. This is why, for example, Chromium splits itself into separate processes and tries to isolate them from the rest of the system: if one renderer hits something that triggers an exploit, the attacker shouldn't be able to take control of anything other than that page. Unfortunately, with SELinux, there's no way of isolating two processes that are instances of the same program and running as the same user from each other. This is because SELinux was never designed for application compartmentalisation.
When a program that's been compartmentalised using Capsicum starts, it enters capability mode with the cap_enter() system call. At this point, it can't create any new file descriptors and can only issue a whitelisted set of system calls that don't touch the global namespace. File descriptors become capabilities, in the classical sense: they're unforgeable tokens of authority, and the only way that the sandboxed process can communicate with the world outside. If you compromise a process that's sandboxed in this way, you can only access the file descriptors that it can access, and for something that's expecting to deal with untrusted data, this is likely to only be a socket for talking to the more privileged process, maybe a network socket to the server, and possibly a directory handle to a cache directory.
Of course, it's not a panacea. Capsicum sandboxed processes can still be susceptible to the confused deputy problem. They can receive new file descriptors (capabilities) via UNIX domain sockets from a more privileged process, and if they can persuade such a process to open something on their behalf that they shouldn't have then they can still elevate privilege. As with other mitigation techniques, it's all about making life harder for the attacker.
In FreeBSD 10, we're shipping a number of base system utilities that run in sandboxed mode by default, and a few more are currently being tested and should appear in 10.1. We're also including a friendly daemon called Casper that will provide services (e.g. DNS lookups) to sandboxed processes, without giving them the rights to create sockets.
Indeed (I wrote a chunk of the FreeBSD locale code), but the grandparent specifically talked about OS X. My comment holds for almost any platform, outside of embedded systems or Solaris (where you can easily turn off locale support with a #define).
This is the much more important point. And the dark silicon problem emphasises it: the number of transistors you can fit on a chip is still increasing, but the number you can have powered at any given time is increasing a lot more slowly. Special-purpose silicon optimised for different categories of algorithm is likely the way forward.
You can still write software that efficient today. The down side is that you can only write software that efficient if you're willing to have it be about that complex too. Do you want your notes application to just store data directly on a single disk from a single manufacturer, or would you rather have an OS that abstracts the details of the device and provides a filesystem? Do you want the notes software to just dump the contents of memory, or do you want it to store things in a file format that is amenable to other programs reading it? Do you want it to just handle plain text for lyricst, or would you like it to handle formatting? What about unicode? Do you want it to be able to render the text in a nice clean antialiased way with proportional spacing, or are you happy with fixed-width bitmap fonts (which may or may not look terrible, depending on your display resolution)? The same applies to the notes themselves. Do you want it to be able to produce PostScript for high-quality printing, or are you happy for it to just dump the low-quality screen version as a bitmap? Do you want it to do wavetable-based MIDI synthesis or are you happy with just beeps?
The reason modern software is bigger is that it does a hell of a lot more. If you spent as much effort on every line of code in a program with all of the features that modern users expect as you did in something where you could put the printouts of the entire codebase on your office wall, you'd never be finished and you'd never find customers willing to pay the amount it would cost.
On OS X, printf is pretty huge. It is locale aware and so will call localeconv() to find out various things like currency separators. This, in turn, may load character set definitions and so on. For your example, you should use puts(), which will just write the string as-is, without trying to parse it and insert tokens.
Speaking as someone who works with FPGAs on a daily basis and has previously done GPGPU compiler work, that's complete nonsense. If you have an algorithm that:
Mostly uses floating point arithmetic
Is embarrassingly parallel
Has simple memory access patterns
Has non-branching flow control
Then a GPU will typically beat an FPGA solution. There's a pretty large problem space for which GPUs suck. If you have memory access that is predictable but doesn't fit the stride models that a GPU is designed for then an FPGA with a well-designed memory interface and a tenth of the arithmetic performance of the GPU will easily run faster. If you have something where you have a long sequence of operations that map well to a dataflow processor, then an FPGA-based implementation can also be faster, especially if you have a lot of branching.
Neither is a panacea, but saying a GPU is always faster and cheaper than an FPGA makes as much sense as saying that a GPU is always faster and cheaper than a general-purpose CPU.
I had some sympathy for Facebook users, because I've so far met one person (and I've asked a few dozen) who had both read and agreed to the Facebook terms and conditions, and he only read the first set, not each subsequent set. But now that there have been a great many stories in the mainstream press about what Facebook does and how it makes its money? If you're still on Facebook, you deserve everything you get.
Depends. If you manage to create the expectation that people in the booth should be knowledgeable about the products, then a booth with attractive but ignorant people will backfire - your company will look like it's full of clueless bimbos when everyone else is able to answer technical questions intelligently. That said, most companies of the size that typically attend these trade shows almost certainly employ at least a few attractive engineers of both genders and so could quite easily put them on the booth. I don't think anyone would object to that though. The problem is not attractive people on the booths, it's people who don't know anything on the booths, who are just there as decoration. Trade shows should be about comparing products and technical competence, not seeing who can hire the best prostitutes or give away the best shiny toys.
Yes and no. AT&T, as with most telcos (and most businesses in general), almost certainly gives better deals to people who buy in bulk. I imagine that Netflix would buy a lot more bandwidth in aggregate than any of their customers, so would get a much better per-GB deal. If you actually use the data, then it's probably cheaper.
How about anyone on your booth must have been employed by your company in a product-development role for at least a year before attending? That would filter out both the eye-candy-but-no-knowledge and most of the sales people, so the people wandering around would actually get to talk to people who knew stuff.
How many Javascript exploits have you see that infect the browser or the host ?
Last time I did a CVE search, I found about 20 within the six months prior to when I did the search, across a small handful of browsers. I haven't looked for a few months though, so maybe there's been a miraculous improvement recently.
ActiveX made no attempt at sandboxing. Java does, but the problem is a monoculture. There are four JavaScript implementations in widespread use, and so if you want to exploit a vulnerability in JavaScript you won't get more than one browser. Exploitable JavaScript bugs tend to be partly due to the DOM and other components of the browser. In Java, there is one widely deployed JVM, including all of the supporting libraries. If you find a bug in it, then you can exploit anyone who still has the Java plugin installed. The same is true of Flash.
You might want to try living somewhere where organised crime has a foothold before you start making claims like that. The Mafia, the Triad, the Yakuza all seem to be doing quite good business, although not as good as they were when various governments were less able to interfere with them. They didn't get any power from a government certificate of incorporation, they got power from being willing to kill the families of anyone who disagreed with them. They have a lot of involuntary customers, and if their activities were legal they'd have a lot more.
It's not just an open spec, it's a BSD-licensed implementation with a royalty-free patent grant. You can take Google's implementation, adapt it for your product (if you want software decoding, that just means recompile it), and use it without having to ask permission from Google or pay Google any money. Hardware and video library developers are free to implement it without paying Google anything.
It wasn't too many years ago people were saying the same about HD. Most of the video I watch is still DVDs on a projector that can only handle 1024x768, but when I replace the projector I don't imagine HD will be any more expensive. My mother now has an HD TV because there weren't any SD ones that were any cheaper. Once the economies of scale kick in, the prices will come down.
The difference with VP9 is that there isn't already an entrenched standard that's better. When work on Theora started, MPEG-1 was still pretty common for web video, but by the time it was released everyone had moved to MPEG-4. Theora was definitely a big step up from MPEG-1 (and MPEG-2), but not as good as MPEG-4. When VP8 was open sourced, it was better than MPEG-4 (ASP), but most of the rest of the world had moved on to H.264. Now VP9 and H.265 are appearing at the same time. No one is considering switching from H.265 to VP9, they're considering switching from H.264 to either VP9 or H.265. If VP9 is royalty free and comparable quality, then that's a big incentive to move in that direction, particularly as they already have the H.264 infrastructure set up to support the devices that can't do VP9.
The current generation of MacBook Pro has an internal resolution only 2880 pixels wide, but the HDMI port can drive a 4K display at either 30 or 24Hz, depending on your definition of 4K, and each of the two Thunderbolt 2 ports can function as DisplayPort 1.2 ports, each driving an external 4K display at 60Hz. So current generation Mac laptops support up to 3 4K displays (although I'd imagine the GPU might struggle a bit if you wanted to do 3D on all of them)...
How do you fire Google? You'd have to stop visiting any web page that uses Google Analytics or adverts from Google, and stop corresponding via email with anyone who uses GMail, via IM with anyone who uses GTalk / Google Hangouts, at the very least.
Slashdot Mirror
Microsoft, at least, creates a stable driver KBI for entire major OS versions. With Linux, you don't even get a guarantee of source compatibility across minor versions, so unless you upstream your driver it may be broken without warning (and if you do, the person 'fixing' it may not have access to the hardware, so will just compile test it). OS X also has stable KBIs for drivers, which are versioned to allow them to be incrementally deprecated and replaced. If you try to make life easy for vendors and they still don't produce drivers, then it ceases to be your fault.
The thing I miss on OS X is the Altera tools for FPGA programming. You can get them to work on FreeBSD via some hacks, and they natively support Linux and Windows, but there's no Mac version.
Oh, and Parallels is the company that takes your money, gives you something that causes host kernel panics, and then tries to charge you more money for the version that doesn't do that. I'll stick with VirtualBox thanks. Parallels is never getting more money from me, after their staggering incompetence with Core 2 IPIs.
The typical response would more likely be to point out that Apple keyboards have a built-in USB hub with two ports in the back, so if you want a conveniently accessible port for plugging things into temporarily, the keyboard is probably closer to your hands than the front of the computer.
I was going to contradict you, because Apple didn't bother certifying 10.7 as UNIX and don't use UNIX in their marketing anymore so I assumed they'd given up, but it appears that both 10.8 and 10.9 on Intel Macs are UNIX. Interestingly, it appears that nothing is certified UNIX08 yet...
The correct way of doing this sort of thing would have been to define standard formats for all of the information and produce a set of open source libraries for manipulating this data, then require every local medical authority to be able to produce and consume these formats. Each local authority could then take the open source reference implementation and add whatever ugly code they needed to interface with their legacy system. It doesn't matter whether they use the new formats internally, or just provide a mechanism for importing and exporting. Most likely, they'd initially do the latter, but when they started to replace existing systems they'd want to make native support for the standard formats a requirement.
How does this compare to existing (coarse grained) Linux capabilities?
Linux capabilities are not capabilities in the classical sense of unforgeable tokens of authority. They are just permissions. Linux capabilities allow a non-root process to do some things as if they were root. Capsicum implements a traditional capability model, where there is no ambient authority and a sandboxed process can not do anything unless it holds the relevant capability.
How does this compare to SELinux?
They address different goals and do so in different ways. The goal of SELinux (and the FreeBSD MAC framework's type enforcement mode) is to allow a system administrator to restrict access of a particular program or user (or program-user pair) to some subset of system resources. It is very bad for application compartmentalisation, because you can't fork() a process and have different permissions for the different children and it's difficult to update the permissions on the fly (although Apple does this with their port of the FreeBSD MAC framework, to implement sandboxing on OS X and iOS, allowing powerboxes to grant permission to specific files or directories).
Capsicum is intended for application sandboxing. It is assumed that the user trusts the binary to be non-malicious, but the program author does not trust his code to be free of exploitable bugs. A sandboxed process should call cap_enter() early on, at which point it can't create any new file descriptors. In some simple cases, that's enough. For example, a sandboxed version of man opens the file containing the mdoc sources and then calls cap_enter(). Even if it's run as root, and is reading a malicious source file that exploits the troff parser and allows arbitrary code execution, it can't do anything other than write text to the terminal. More complex applications will keep open a UNIX domain socket to a (more) privileged process that can pass in new file descriptors as they're needed, after doing some application-specific policy checking.
Does this complement things like Linux's seccomp?
Seccomp is far more restrictive than Capscium and prevents even harmless system calls (e.g. getpid(), gettimeofday() - although not on platforms where these use VDSO, I believe, but others of equal utility and harmlessness are blocked). Capsicum allows a whitelisted set of calls. Additionally, Capsicum adds finer-grained permissions on file handles (for example, you can be able to read, but not mmap, or append but not seek) and a set of at-suffixed system calls that work on directory descriptors, such as openat that allows a sandboxed process to open files in a directory that it holds the relevant capability for. This means that, for example, you can give a sandboxed browser tab process a directory descriptor to a cache directory and it can write cache data there without needing any interposition from a more privileged process. It talks directly to the kernel.
Seccomp-bpf extends seccomp by allowing system calls to be blocked or allowed based on the execution of a BPF filter. This is more expressive than Capsicum (Google's first port of Capsicum implemented it in terms of seccomp-bpf, although it was slow and not complete), but it doesn't allow the policies to easily associate permissions data with file descriptors and requires you to implement a complex BPF policy.
What's the overhead compared to the above?
There is basically no overhead for capsicum. It's one extra bitmask check on each system call that interacts with a file descriptor, which is in the noise for most workloads[1].
In terms of programmer overhead, there's a summary table for the number of lines of code changed to implement sandboxing with various mechanisms in Chrome in the original Capsicum paper. Here's the short version:
There are a few big differences. The first is that SELinux is really an extension of the ACL approach: you have a big matrix with things that can do stuff, and things that can have stuff done to them, and a bit in each position indicating whether that combination is allowed. SELinux (and most ACL implementations) compress this, because a matrix with one row for every process-user pair and one column for every filesystem or kernel object would be huge. The goal of things like SELinux is for system administrators to be able to restrict the rights of certain things.
The goal of Capsicum is different. It's not intended to protect against malicious code, it's intended to protect against exploitable code. This is why, for example, Chromium splits itself into separate processes and tries to isolate them from the rest of the system: if one renderer hits something that triggers an exploit, the attacker shouldn't be able to take control of anything other than that page. Unfortunately, with SELinux, there's no way of isolating two processes that are instances of the same program and running as the same user from each other. This is because SELinux was never designed for application compartmentalisation.
When a program that's been compartmentalised using Capsicum starts, it enters capability mode with the cap_enter() system call. At this point, it can't create any new file descriptors and can only issue a whitelisted set of system calls that don't touch the global namespace. File descriptors become capabilities, in the classical sense: they're unforgeable tokens of authority, and the only way that the sandboxed process can communicate with the world outside. If you compromise a process that's sandboxed in this way, you can only access the file descriptors that it can access, and for something that's expecting to deal with untrusted data, this is likely to only be a socket for talking to the more privileged process, maybe a network socket to the server, and possibly a directory handle to a cache directory.
Of course, it's not a panacea. Capsicum sandboxed processes can still be susceptible to the confused deputy problem. They can receive new file descriptors (capabilities) via UNIX domain sockets from a more privileged process, and if they can persuade such a process to open something on their behalf that they shouldn't have then they can still elevate privilege. As with other mitigation techniques, it's all about making life harder for the attacker.
In FreeBSD 10, we're shipping a number of base system utilities that run in sandboxed mode by default, and a few more are currently being tested and should appear in 10.1. We're also including a friendly daemon called Casper that will provide services (e.g. DNS lookups) to sandboxed processes, without giving them the rights to create sockets.
Indeed (I wrote a chunk of the FreeBSD locale code), but the grandparent specifically talked about OS X. My comment holds for almost any platform, outside of embedded systems or Solaris (where you can easily turn off locale support with a #define).
This is the much more important point. And the dark silicon problem emphasises it: the number of transistors you can fit on a chip is still increasing, but the number you can have powered at any given time is increasing a lot more slowly. Special-purpose silicon optimised for different categories of algorithm is likely the way forward.
You can still write software that efficient today. The down side is that you can only write software that efficient if you're willing to have it be about that complex too. Do you want your notes application to just store data directly on a single disk from a single manufacturer, or would you rather have an OS that abstracts the details of the device and provides a filesystem? Do you want the notes software to just dump the contents of memory, or do you want it to store things in a file format that is amenable to other programs reading it? Do you want it to just handle plain text for lyricst, or would you like it to handle formatting? What about unicode? Do you want it to be able to render the text in a nice clean antialiased way with proportional spacing, or are you happy with fixed-width bitmap fonts (which may or may not look terrible, depending on your display resolution)? The same applies to the notes themselves. Do you want it to be able to produce PostScript for high-quality printing, or are you happy for it to just dump the low-quality screen version as a bitmap? Do you want it to do wavetable-based MIDI synthesis or are you happy with just beeps?
The reason modern software is bigger is that it does a hell of a lot more. If you spent as much effort on every line of code in a program with all of the features that modern users expect as you did in something where you could put the printouts of the entire codebase on your office wall, you'd never be finished and you'd never find customers willing to pay the amount it would cost.
On OS X, printf is pretty huge. It is locale aware and so will call localeconv() to find out various things like currency separators. This, in turn, may load character set definitions and so on. For your example, you should use puts(), which will just write the string as-is, without trying to parse it and insert tokens.
Then a GPU will typically beat an FPGA solution. There's a pretty large problem space for which GPUs suck. If you have memory access that is predictable but doesn't fit the stride models that a GPU is designed for then an FPGA with a well-designed memory interface and a tenth of the arithmetic performance of the GPU will easily run faster. If you have something where you have a long sequence of operations that map well to a dataflow processor, then an FPGA-based implementation can also be faster, especially if you have a lot of branching.
Neither is a panacea, but saying a GPU is always faster and cheaper than an FPGA makes as much sense as saying that a GPU is always faster and cheaper than a general-purpose CPU.
I had some sympathy for Facebook users, because I've so far met one person (and I've asked a few dozen) who had both read and agreed to the Facebook terms and conditions, and he only read the first set, not each subsequent set. But now that there have been a great many stories in the mainstream press about what Facebook does and how it makes its money? If you're still on Facebook, you deserve everything you get.
Depends. If you manage to create the expectation that people in the booth should be knowledgeable about the products, then a booth with attractive but ignorant people will backfire - your company will look like it's full of clueless bimbos when everyone else is able to answer technical questions intelligently. That said, most companies of the size that typically attend these trade shows almost certainly employ at least a few attractive engineers of both genders and so could quite easily put them on the booth. I don't think anyone would object to that though. The problem is not attractive people on the booths, it's people who don't know anything on the booths, who are just there as decoration. Trade shows should be about comparing products and technical competence, not seeing who can hire the best prostitutes or give away the best shiny toys.
Yes and no. AT&T, as with most telcos (and most businesses in general), almost certainly gives better deals to people who buy in bulk. I imagine that Netflix would buy a lot more bandwidth in aggregate than any of their customers, so would get a much better per-GB deal. If you actually use the data, then it's probably cheaper.
How about anyone on your booth must have been employed by your company in a product-development role for at least a year before attending? That would filter out both the eye-candy-but-no-knowledge and most of the sales people, so the people wandering around would actually get to talk to people who knew stuff.
How many Javascript exploits have you see that infect the browser or the host ?
Last time I did a CVE search, I found about 20 within the six months prior to when I did the search, across a small handful of browsers. I haven't looked for a few months though, so maybe there's been a miraculous improvement recently.
ActiveX made no attempt at sandboxing. Java does, but the problem is a monoculture. There are four JavaScript implementations in widespread use, and so if you want to exploit a vulnerability in JavaScript you won't get more than one browser. Exploitable JavaScript bugs tend to be partly due to the DOM and other components of the browser. In Java, there is one widely deployed JVM, including all of the supporting libraries. If you find a bug in it, then you can exploit anyone who still has the Java plugin installed. The same is true of Flash.
You might want to try living somewhere where organised crime has a foothold before you start making claims like that. The Mafia, the Triad, the Yakuza all seem to be doing quite good business, although not as good as they were when various governments were less able to interfere with them. They didn't get any power from a government certificate of incorporation, they got power from being willing to kill the families of anyone who disagreed with them. They have a lot of involuntary customers, and if their activities were legal they'd have a lot more.
It's not just an open spec, it's a BSD-licensed implementation with a royalty-free patent grant. You can take Google's implementation, adapt it for your product (if you want software decoding, that just means recompile it), and use it without having to ask permission from Google or pay Google any money. Hardware and video library developers are free to implement it without paying Google anything.
It wasn't too many years ago people were saying the same about HD. Most of the video I watch is still DVDs on a projector that can only handle 1024x768, but when I replace the projector I don't imagine HD will be any more expensive. My mother now has an HD TV because there weren't any SD ones that were any cheaper. Once the economies of scale kick in, the prices will come down.
The difference with VP9 is that there isn't already an entrenched standard that's better. When work on Theora started, MPEG-1 was still pretty common for web video, but by the time it was released everyone had moved to MPEG-4. Theora was definitely a big step up from MPEG-1 (and MPEG-2), but not as good as MPEG-4. When VP8 was open sourced, it was better than MPEG-4 (ASP), but most of the rest of the world had moved on to H.264. Now VP9 and H.265 are appearing at the same time. No one is considering switching from H.265 to VP9, they're considering switching from H.264 to either VP9 or H.265. If VP9 is royalty free and comparable quality, then that's a big incentive to move in that direction, particularly as they already have the H.264 infrastructure set up to support the devices that can't do VP9.
The current generation of MacBook Pro has an internal resolution only 2880 pixels wide, but the HDMI port can drive a 4K display at either 30 or 24Hz, depending on your definition of 4K, and each of the two Thunderbolt 2 ports can function as DisplayPort 1.2 ports, each driving an external 4K display at 60Hz. So current generation Mac laptops support up to 3 4K displays (although I'd imagine the GPU might struggle a bit if you wanted to do 3D on all of them)...
Governments can send men with guns to kick in my front door
You miss the corollary of this, which is that governments are the reason why corporations can't send men with guns to kick in your front door...
How do you fire Google? You'd have to stop visiting any web page that uses Google Analytics or adverts from Google, and stop corresponding via email with anyone who uses GMail, via IM with anyone who uses GTalk / Google Hangouts, at the very least.