Even without direct enumeration, it's still relatively easy to find. The object / embed tags can be nested for fallback and the resource is only requested if you have that plugin installed. You can provide a load of 1px objects with different nesting and just check in the server which cookies show up in the requests.
It's easy to prevent. The browser should only expose a whitelisted set of system fonts to the web, which would then tell you nothing that wasn't in the user agent string to start with. With the widespread support for Web Open Font Format, it's easy for designers to provide additional fonts if they want to use them. I don't want something random on the web to be rendered in, for example, the Quake font, just because I happen to have it installed - it's almost certainly not what the developers intended, and if it is then they should use a.woff file.
Add to that, it's relatively easy to wrap your images in a noscript tag referencing a JPG version, so for the cost of storing two versions of the image on the server, you get to save money on bandwidth for anyone whose client can support it and not degrade the user experience for people who can't.
These prototyping boards are fairly expensive (around $40), but the system is amazing - web-based IDE and the device appears as a USB mass storage device that you can just drop the code onto. They're easy to drop into a breadboard and connect other stuff to. ARM's pushing them for the kinds of people who wouldn't normally do embedded development, but I'd love to see them in schools. They have similar I/O capabilities to the BBC Micros that we used in the '80s and '90s, but are small enough that you can put the controller in the computer. I don't know how much the microcontroller itself is in bulk, but I'm really impressed with the prototyping system and I'd love to see them in schools.
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.
Re:Very relevent for small target embedded stuff.
on
How Relevant is C in 2014?
·
· Score: 4, Insightful
The clever people use C when C is the right tool for the job and use something else when it isn't. The rest use C, Python, or whatever else their favourite language is, irrespective of whether it's the right tool.
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.
The mbed development environment for the ARM Cortex M series uses C++, but you need to stick to a fairly limited subset of C++ to fit within the requirements, at which point you're basically using C with an annoying type system and some nice syntactic sugar for constructing vtables.
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.
You seem to be conflating open source with non-profit community-developed. I can't speak for Linux, but in the FreeBSD world a significant fraction of the developers are working on bits of the project in exchange for money, because it's cheaper for their employers to improve FreeBSD than it is for them to develop something bespoke.
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).
There are good reasons and bad reasons why C is still popular.
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 French would probably have done a lot better if they'd had a thousand miles or so where they could burn all of the crops and retreat across during winter, stretching the Germans supply lines and making a lot of their equipment stop working due to the temperature.
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.
The important bit of the story is that the chickens are defrosted first. The engines will not survive if a chicken-sized lump of ice is thrown into them.
It's a matter of perception. People are much more forgiving of a company that can't secure its networks against the intelligence services of a foreign power than a company that can't secure its networks against a couple of kids.
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).
IQ is largely discredited as a culturally agnostic test of intelligence.
The studies in question did not control for social and economic factors.
Even if you accept the studies' methodology as flawless, they showed such a small variation in intelligence that the vast majority (95%) of all three populations that they studied was in the same overlapping region.
Drawing any meaningful conclusion from that evidence is pretty hard.
In fact, most of the "science" in racism was disproven long ago, and it was only "science", much because it was paid for by special intrest groups to become science
I don't think that's entirely fair. A lot of racist ideas follow quite logically from hypotheses that make sense from Gregor Mendel's work. The fact that they were falsified by the mid 1900s doesn't mean that they were any less science any more than the luminiferous aether and other discredited hypotheses.
All science is about ideas that are wrong. The way that you can tell that it's science is that, over time, ideas are replaced with less-wrong ideas, until eventually they're sufficiently close an approximation to reality that people lose interest in studying the difference.
In the last article, there was a quote from him saying that he planned to use the money from the sale of the medal to buy art to donate to various organisations, apparently thinking that this was a way to buy back some respectability. I don't know if this will work...
And the bidding shouldn't just be about the money. Make the bids include open access and plans to make it available for the lowest cost to the greatest number of end users. Give the spectrum to the companies that offer the most in these categories and fine them very large amounts if they fail to meet their targets.
The problem with baring convicted criminals from voting is that it sets up a strong incentive for the current government (whichever team they happen to be at the time) to pass laws that disproportionately criminalise people who vote for the other team. Let that happen for a few iterations and... well, there's a reason that the USA has a higher percentage of its population in prison than any other western country.
Basically, I was wearing a bulletproof vest, but got shot in the leg. Not the vest's fault
Given the number of flu strains in the wild vs the number that a vaccine protects you against, a better analogy is that you're wearing bullet-proof shoes, and you got shot in the leg.
The problem is evolution. The rate of evolution is related to lifespan and mutation rate. It's possible that a species could evolve with 1,000 year lifespans, but would likely do so in an environment where mutations are more common. There's likely to be an upper bound though, because if mutations are too common then there's a good chance that, even if intelligence does arise, it won't be passed on to the next generation.
Extrapolating from one data point is always problematic, but it seems plausible that social stability is linked to lifespan. If you live 100 years naturally, then a 10-year journey using suspended animation, 10 years there, and 10 years back, would be quite plausible. Society would have changed a lot in the 30 years that you were away, but it wouldn't be completely unrecognisable. If you live 100 years naturally but then spend 2000 years in suspended animation and 10 years at the remote end, then it's likely that you'd find it very hard to adapt on your return. It would also be very hard to maintain a cohesive interstellar society if a message takes 10 lifetimes to go between colonies - cultures would diverge too fast. This was a problem for European colonies when messages took a couple of months - less than 1% of a human lifetime - to go between them.
What you are saying is FreeBSD goes for the cream of the crap
Not at all, I'm saying that you can get very competent people for a price that is good relative to their cost of living. People in Silicon Valley have some of the highest cost of living in the world. That means that they're the most expensive.
Really bright people are very likely to be snatched up by Silicon Valley,
Some do. A lot don't want to move to the US at all for various reasons.
None the less, you make it seem as though FreeBSD is hiring people based on economy rather than qualification, which just isn't true. FreeBSD hands contracts to those who are willing, able, and more importantly, proven regardless of geographic location or caste. Price is secondary. FF has also contracted people inside Silicon Valley just the same.
Value for money always factors into it. The Foundation always has to consider whether it's spending its money in the best way. Sometimes, the only people with both the skill and availability are in the Valley. When the expertise is also available elsewhere, it's a no brainer for the Foundation to fund two projects with people who have lower consulting rates than one with someone more expensive. In some cases, it's not a good use of the limited financial resources to fund a project if the only people who can do it are more expensive than the perceived value of the project. If you're paying San Francisco rent, then you're going to price yourself out of the market a lot of the time.
Honestly, this sounds like you resent those who make six figures. Reconsider your disposition, if not your career if you are not succeeding like some of the rest of us. I'll buy you a few brews come June.
I'm happy to charge Silicon Valley rates when I'm consulting for Silicon Valley companies! At other times, I'm also happy to charge an amount that leaves me with a comparable (or larger) disposable income than someone in Silicon Valley - it means I can undercut people who did move there, but still take home the same (or more) after food, accommodation and so on. Most of the companies I've consulted for have the majority of their technical workforce outside of California (and, in many cases, outside of the USA) for precisely this reason - there's no shortage of skills, and it's easy to attract people with a salary that is a large multiple of the cost of living, but still a lot lower than a comparable job in Silicon Valley.
I think you're reading a lot of your own biases into what I wrote. To repeat:
they're competent, but not too expensive
There are people in the Ukraine (ray and kib, for example) who are extremely competent, but have a cost of living that is a fraction of what you'd need for an equivalent standard of living in California. There are some very competent people in Poland (lots of the people who work or consult for SemiHalf, along with pawel, and others) for whom the same is true. They won't become more competent if they move to the Valley, but they will become more expensive - I doubt that the Foundation could afford to have kib as a full-time employee if he were to move to the Valley, but there are very few people who understand the VM subsystem and several other parts of the kernel better.
IBM, Google, Intel, and a number of other big companies have research and product development groups in these places because trying to move all of the competent people to Silicon Valley wouldn't make sense (for the people or the company). Red Hat has some very competent people working from home all across the world. They're snapped up by Silicon Valley companies, but they've no incentive to move to Silicon Valley - they get paid something a bit less than a Valley salary, but with a cost of living that's 10-20% of living there. Moving to the Valley and a Valley salary would leave them worse off financially.
From the End-User standpoint, really the only thing that they care about is that there is a "full featured" product that is free (as in beer) and they won't have to deal with marked-up license fees.
Which isn't necessarily a given. To give a concrete example, at the 24th International Conference on Field Programmable Logic and Applications, there was an award given to Jason Anderson for his 'contributions to open source high-level synthesis', in particular the LegUp project. Now, given this award and the fact that the front page of the web site starts with the phrase 'LegUp is an open source high-level synthesis tool', you might be forgiven for thinking that LegUp is open source. If you go and read their license, you will discover that it doesn't meet the open source definition. The license contains the phrase 'Only non-commercial, not-for-profit use of this software is permitted'. Given previous legal issues surrounding the definition of 'non-commercial', this license basically means 'don't use it if you care about legal liability at all' and is worse than no-warranty proprietary freeware from a legal perspective.
Slashdot Mirror
Even without direct enumeration, it's still relatively easy to find. The object / embed tags can be nested for fallback and the resource is only requested if you have that plugin installed. You can provide a load of 1px objects with different nesting and just check in the server which cookies show up in the requests.
It's easy to prevent. The browser should only expose a whitelisted set of system fonts to the web, which would then tell you nothing that wasn't in the user agent string to start with. With the widespread support for Web Open Font Format, it's easy for designers to provide additional fonts if they want to use them. I don't want something random on the web to be rendered in, for example, the Quake font, just because I happen to have it installed - it's almost certainly not what the developers intended, and if it is then they should use a .woff file.
Add to that, it's relatively easy to wrap your images in a noscript tag referencing a JPG version, so for the cost of storing two versions of the image on the server, you get to save money on bandwidth for anyone whose client can support it and not degrade the user experience for people who can't.
These prototyping boards are fairly expensive (around $40), but the system is amazing - web-based IDE and the device appears as a USB mass storage device that you can just drop the code onto. They're easy to drop into a breadboard and connect other stuff to. ARM's pushing them for the kinds of people who wouldn't normally do embedded development, but I'd love to see them in schools. They have similar I/O capabilities to the BBC Micros that we used in the '80s and '90s, but are small enough that you can put the controller in the computer. I don't know how much the microcontroller itself is in bulk, but I'm really impressed with the prototyping system and I'd love to see them in schools.
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 clever people use C when C is the right tool for the job and use something else when it isn't. The rest use C, Python, or whatever else their favourite language is, irrespective of whether it's the right tool.
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.
The mbed development environment for the ARM Cortex M series uses C++, but you need to stick to a fairly limited subset of C++ to fit within the requirements, at which point you're basically using C with an annoying type system and some nice syntactic sugar for constructing vtables.
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 French would probably have done a lot better if they'd had a thousand miles or so where they could burn all of the crops and retreat across during winter, stretching the Germans supply lines and making a lot of their equipment stop working due to the temperature.
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.
The important bit of the story is that the chickens are defrosted first. The engines will not survive if a chicken-sized lump of ice is thrown into them.
It's a matter of perception. People are much more forgiving of a company that can't secure its networks against the intelligence services of a foreign power than a company that can't secure its networks against a couple of kids.
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.
In fact, most of the "science" in racism was disproven long ago, and it was only "science", much because it was paid for by special intrest groups to become science
I don't think that's entirely fair. A lot of racist ideas follow quite logically from hypotheses that make sense from Gregor Mendel's work. The fact that they were falsified by the mid 1900s doesn't mean that they were any less science any more than the luminiferous aether and other discredited hypotheses.
All science is about ideas that are wrong. The way that you can tell that it's science is that, over time, ideas are replaced with less-wrong ideas, until eventually they're sufficiently close an approximation to reality that people lose interest in studying the difference.
In the last article, there was a quote from him saying that he planned to use the money from the sale of the medal to buy art to donate to various organisations, apparently thinking that this was a way to buy back some respectability. I don't know if this will work...
And the bidding shouldn't just be about the money. Make the bids include open access and plans to make it available for the lowest cost to the greatest number of end users. Give the spectrum to the companies that offer the most in these categories and fine them very large amounts if they fail to meet their targets.
The problem with baring convicted criminals from voting is that it sets up a strong incentive for the current government (whichever team they happen to be at the time) to pass laws that disproportionately criminalise people who vote for the other team. Let that happen for a few iterations and... well, there's a reason that the USA has a higher percentage of its population in prison than any other western country.
Basically, I was wearing a bulletproof vest, but got shot in the leg. Not the vest's fault
Given the number of flu strains in the wild vs the number that a vaccine protects you against, a better analogy is that you're wearing bullet-proof shoes, and you got shot in the leg.
The problem is evolution. The rate of evolution is related to lifespan and mutation rate. It's possible that a species could evolve with 1,000 year lifespans, but would likely do so in an environment where mutations are more common. There's likely to be an upper bound though, because if mutations are too common then there's a good chance that, even if intelligence does arise, it won't be passed on to the next generation.
Extrapolating from one data point is always problematic, but it seems plausible that social stability is linked to lifespan. If you live 100 years naturally, then a 10-year journey using suspended animation, 10 years there, and 10 years back, would be quite plausible. Society would have changed a lot in the 30 years that you were away, but it wouldn't be completely unrecognisable. If you live 100 years naturally but then spend 2000 years in suspended animation and 10 years at the remote end, then it's likely that you'd find it very hard to adapt on your return. It would also be very hard to maintain a cohesive interstellar society if a message takes 10 lifetimes to go between colonies - cultures would diverge too fast. This was a problem for European colonies when messages took a couple of months - less than 1% of a human lifetime - to go between them.
What you are saying is FreeBSD goes for the cream of the crap
Not at all, I'm saying that you can get very competent people for a price that is good relative to their cost of living. People in Silicon Valley have some of the highest cost of living in the world. That means that they're the most expensive.
Really bright people are very likely to be snatched up by Silicon Valley,
Some do. A lot don't want to move to the US at all for various reasons.
None the less, you make it seem as though FreeBSD is hiring people based on economy rather than qualification, which just isn't true. FreeBSD hands contracts to those who are willing, able, and more importantly, proven regardless of geographic location or caste. Price is secondary. FF has also contracted people inside Silicon Valley just the same.
Value for money always factors into it. The Foundation always has to consider whether it's spending its money in the best way. Sometimes, the only people with both the skill and availability are in the Valley. When the expertise is also available elsewhere, it's a no brainer for the Foundation to fund two projects with people who have lower consulting rates than one with someone more expensive. In some cases, it's not a good use of the limited financial resources to fund a project if the only people who can do it are more expensive than the perceived value of the project. If you're paying San Francisco rent, then you're going to price yourself out of the market a lot of the time.
Honestly, this sounds like you resent those who make six figures. Reconsider your disposition, if not your career if you are not succeeding like some of the rest of us. I'll buy you a few brews come June.
I'm happy to charge Silicon Valley rates when I'm consulting for Silicon Valley companies! At other times, I'm also happy to charge an amount that leaves me with a comparable (or larger) disposable income than someone in Silicon Valley - it means I can undercut people who did move there, but still take home the same (or more) after food, accommodation and so on. Most of the companies I've consulted for have the majority of their technical workforce outside of California (and, in many cases, outside of the USA) for precisely this reason - there's no shortage of skills, and it's easy to attract people with a salary that is a large multiple of the cost of living, but still a lot lower than a comparable job in Silicon Valley.
I think you're reading a lot of your own biases into what I wrote. To repeat:
they're competent, but not too expensive
There are people in the Ukraine (ray and kib, for example) who are extremely competent, but have a cost of living that is a fraction of what you'd need for an equivalent standard of living in California. There are some very competent people in Poland (lots of the people who work or consult for SemiHalf, along with pawel, and others) for whom the same is true. They won't become more competent if they move to the Valley, but they will become more expensive - I doubt that the Foundation could afford to have kib as a full-time employee if he were to move to the Valley, but there are very few people who understand the VM subsystem and several other parts of the kernel better.
IBM, Google, Intel, and a number of other big companies have research and product development groups in these places because trying to move all of the competent people to Silicon Valley wouldn't make sense (for the people or the company). Red Hat has some very competent people working from home all across the world. They're snapped up by Silicon Valley companies, but they've no incentive to move to Silicon Valley - they get paid something a bit less than a Valley salary, but with a cost of living that's 10-20% of living there. Moving to the Valley and a Valley salary would leave them worse off financially.
A
From the End-User standpoint, really the only thing that they care about is that there is a "full featured" product that is free (as in beer) and they won't have to deal with marked-up license fees.
Which isn't necessarily a given. To give a concrete example, at the 24th International Conference on Field Programmable Logic and Applications, there was an award given to Jason Anderson for his 'contributions to open source high-level synthesis', in particular the LegUp project. Now, given this award and the fact that the front page of the web site starts with the phrase 'LegUp is an open source high-level synthesis tool', you might be forgiven for thinking that LegUp is open source. If you go and read their license, you will discover that it doesn't meet the open source definition. The license contains the phrase 'Only non-commercial, not-for-profit use of this software is permitted'. Given previous legal issues surrounding the definition of 'non-commercial', this license basically means 'don't use it if you care about legal liability at all' and is worse than no-warranty proprietary freeware from a legal perspective.