Uhhhh...you DID notice I singled out Linux and NOT BSD, right? I did this because as you pointed out BSD works differently, but so little is paid to BSD on the desktop its simply not worth mentioning in that space.
No, you made general statements about open source. You said Linux, but you then mentioned a bunch of projects that are part of the wider open source ecosystem. With regard to FreeBSD on the desktop, the FreeBSD Foundation funded much of the work to bring GPU support up to parity with Linux and iX Systems sells machines preinstalled with PC-BSD (FreeBSD plus some other stuff aimed at desktops) and pays most of their developers.
Getting a person to create something NEW for free? Easy. getting them to spend their time fixing somebody else's bugs? Not happening.
And that's where you go right back to your original false equivalence. The devs who are doing that are not doing it for free. They are paid. This is true for Linux, FreeBSD, or any other moderately large open source project. And they're paid because the people paying them benefit from the project being taken from hobbyist quality to professional quality.
That's not even a new phenomenon. The original NFS is a good example: Sun hired ex-UCB people to work on BSD because they needed a decent OS to sell workstations. They released NFS as open source because they could sell more servers if everyone's clients used their protocol. No one was working for free.
The thing is, if you use structures with bit fields, C will not optimize the manipulations with them correctly
You're conflating the language and the implementation. LLVM does lots of optimisations for bitfield manipulation and has various patterns in the back ends for using them and intrinsics so that you can help the compiler out. If you're seeing some missed optimisation opportunities, then please file bug reports.
One of the big reasons C will probably not be going away any time soon is there is no replacement and not much work being done on one.
Rust is a reasonable replacement for a lot of the things that C is good at. Go is a good replacement for a lot of the things that C is bad at but is used for anyway.
The guys at Netflix, for example, have a workload that involves sending 1MB chunks of data as fast as they can over the network. When they started, I think they could saturate a 10Gb/s ethernet link, but not two. Now, I don't know the exact numbers, but I think they're saturating one 40GB/s link and starting to look at how much of a bottleneck their storage is.
The folks at Juniper have been working on turning some of the data types that the kernel exposes for network stack internals into opaque types so that they can have drivers for their stuff that are stable over lots of kernel revisions.
A few people, including some people from iX Systems, have been improving the QA infrastructure so that soon on each commit we'll be able to automatically build the system, boot it in a VM and run regression tests. After that, it will step up to net booting some real machines and running performance regression tests (and booting some platforms like ARM and MIPS and running regression tests there).
Lots of core infrastructure projects like this are done because the people who make money from the software existing need them to exist. Sure, they wouldn't be done for a toy project run by hobbyists that no one is using in production, but no big open source project fits that description (it's very hard to become big if you do).
The main good reasons is the small footprint. I was recently given an ARM Cortex M3 prototyping board to play with. This is a pretty high-end part by IoT standards, but has 128KB of RAM and 512KB of flash for code and data storage. It's programmed using C++, but unless you stick to a very restrictive subset of C++ that's almost C, then you'll end up generating too much code (C++ templates are not just a good way of blowing away your i-cache on high-end systems, they're also a good way of blowing away your total code storage on embedded chips).
The other good reason is that it makes it relatively easy to have fine control. Not quite as easy as you'd want. To give one example, the JavaScriptCore interpreter and baseline JIT were rewritten from C++ into macro assembler a couple of years back because C and C++ don't give you fine-grained control over stack layout. To give another example, some game devs were recently complaining on the LLVM list that their hand-optimised memcpy implementations were being turned into memcpy library calls, because they assume that they're using a macro assembler when they write C, and not a language with a complex optimising compiler behind it. It does, however, give you flow control primitives that make it easy to reason about performance and fine-grained control over memory layout. These are particularly valuable in certain contexts, for example when implementing higher-level languages.
The biggest bad reason for C being popular is that we've standardised on C as the way of defining library APIs in UNIX-land. There's no IDL that describes higher-level concepts, there are just C headers, and the language that makes it easiest to use C libraries wins. There has been some improvement in C-calling FFIs recently, and a big part of the popularity of Python is the ease with which you can use C/C++ libraries from it. Even simple things are hard when interoperating with C. It's hard for an FFI generator to know whether that char * parameter is a null-terminated string or a pointer to an arbitrary block of memory that's going to be read by the callee, a pointer to a single char that's going to be written back, or whether the callee returns a pointer to within the block and needs the original memory to persist. Lots of libraries take function pointers that have a void* context pointer, so can be mapped to closures in the caller's language, but they all put the context object in different places so you need a custom trampoline for each one.
With over 8 billion lines of open source C code (source: OpenHub.net), there's a good chance that the library that you want to use is written in C.
The problem is defining the prevailing wage. The categories are overly broad. The average salary for a programmer includes all of the kids writing terrible PHP after reading a book about it for a couple of weeks and then getting a job in their parents' company. Getting someone who can write decent kernel or embedded C for the price of an average programmer is difficult. Getting any kind of programmer in Silicon Valley for the average salary nationwide is impossible.
And why would you make it a tax? If you can identify the rate that other, similarly qualified people are making, then you can just require that H1Bs get paid 10% more than that. The point of systems like the H1B scheme is (meant to be) to expand the labour pool when there are more jobs for competent people than there are competent people, not to drive down local wages by displacing people who want to work with people who are willing to work for less than the prevailing wage.
Modern TVs use exactly the same panels as low-end monitors. If you get a 1080p TV that can do 60Hz, then you've got something that's pretty much the same as a monitor. If you get a 4K TV, then you've got something that's a lot nicer than many monitors.
The big problems with using TVs as monitors before flat panels became popular were the low resolution and refresh (PAL and NTSC interlaced, so you got a flickery picture with around 500 lines, but only half that per update) and the fact that they were optimised for brightness at the expense of sharpness (the beam would overspill into surrounding pixels slightly, which would soften lines). The only time it's a problem to use a TV now is if it's so big that it's hard to fit into your field of view (although this can be solved by sitting further back) or if it's a really cheap set that can't do progressive scan at its native resolution (some panels can only do upscaled 720p or 1080i, neither of which is good for text).
Drawing any meaningful conclusion from that evidence is pretty hard.
All power corrupts, but we need electricity.
