For a long time, laptop components were vastly more expensive than their desktop counterparts. Part of this was due to their stricter requirements (smaller, lower power, and so on), but a big factor was the economies of scale. For every laptop part you sold, you'd sell 20 or more of the desktop equivalent. This changed significantly once laptop sales passed desktop. Now, for example, the cost of DDR3 SO-DIMMs and full-sized DIMMs is the same (up to 8GB modules, at least). When everyone is buying SSDs for their laptops and servers, it becomes increasingly expensive to keep producing hard drives for a shrinking niche.
Part of the problem is that politics is now a career. I wouldn't mind doing the job for a year, maybe two if I could do it part time - say two days a week so I could keep doing stuff that's actually interesting as well. There's no way I'd want to spend even five years, let alone the 20-30 that most politicians seem to have to put in.
It was easy to criticise Itanium at the time, in comparison to Alpha, or PowerPC too. If we'd somehow all been forced to rewrite all of our legacy x86 code, either of these would have been a better choice. In fact, emulating x86 on PowerPC is a lot easier than on Itanium, so it would have been a more natural path if Intel had managed to kill x86. Lucky for them, they failed...
OpenVMS and NonStop effectively only run on Alpha and a surprising number of companies have mission-critical software that works on one of these two platforms.
It keeps being repeated because it's almost true. Manufacturing hasn't gone down in the USA, but manufacturing employment has. Just like in the first industrial revolution, the number of people required to manufacture goods has dropped considerably. China had a small short-term advantage because, for certain things, it was cheaper to use poorly-paid workers than machines, but even that's changing. Lots of people are talking as if Chinese factory workers are competing against American factory workers and winning because they're paid a fraction of the amount, but that's not really the case. 10-100 Chinese factory workers are competing against one American factory worker and a large automated assembly line. They were winning because they have lower capital costs, but higher operational costs. Now that companies like Foxconn have large amounts of capital to play with, they're starting to lose again.
People keep talking as if bringing manufacturing back to the USA will make a difference for the local economy, but it won't. The mindset that a new factory will employ thousands of people and provide employment either directly or indirectly for an entire town is obsolete. This doesn't, of course, stop local governments giving companies millions of dollars in tax breaks to build a factory, and then acting surprised when it only creates a hundred or so new jobs.
The first industrial revolution had a lot of social unrest because of the wealth-redistribution that the automation caused, concentrating it in the hands of the factory owners. This one is likely to have many of the same problems. Unfortunately, we didn't find a good solution last time.
I'm not sure about the one in TFA, but one of the big differences in the prototype that I saw was that it used eInk instead of a traditional LCD for the display. This means that the battery life is a whole lot better. That, combined with improvements in battery technology means that it's possible to create one that will last for longer than the lifetime of a credit card and be able to create cryptographic tokens for this entire time. Oh, and I think you're misremembering the thickness of the 'credit card sized' calculators in the '80s. They were at least 2-3 times the thickness of a normal card. This is exactly the same size, and so works with magnetic strip and chip-and-pin readers as well.
Why would I want to carry one of these gadgets around when I already have a smartphone which can do the same job?
You answered this question in your first paragraph. A mobile phone application runs on a general purpose OS (which, unless its an iPhone or a Google-branded Android phone, probably has a load of old and buggy libraries and kernel because your carrier doesn't push out updates sufficiently competently). Even if the app itself is perfectly written, the TCB contains a whole load of other stuff that really shouldn't be trusted - you install one malicious app by mistake (or visit one malicious web page with a browser that has a known exploit that is fixed upstream but the fix never pushed to you) and your bank account is compromised.
In contrast, the device on the card is running a simple OS, has no network communication, and is basically impossible to trojan without physical access and disassembly.
By the way, we have the Singapore banking regulator to thank for a number of things, including two-factor authentication for online banking. They were the ones that insisted that it had to be provided by all banks doing business in Singapore, and the big banks decided that it was cheaper to roll it out worldwide than have a single system for Singapore. They also have very strict rules (and impose fines for violations) regarding security and disclosure.
It's not that simple. 64bit instructions can handle more data per cycle than 32bit ones, so there is an increase in performance whenever you handle large amounts of data and/or large numbers
The first is that the size of the address space corresponds to data size. NEON, the ARM vector instruction set, can already perform operations on 64-bit integer or floating point values[1]. This is even true on x86, where you have 64-bit operations that work on a pair of registers. The advantage is that you have 64-bit registers, so you don't need to use two for each 64-bit operation (6 of your 14 GPRs on ARMv7 if you want two source and one destination, compared to 3 of your 31 GPRs on ARMv8). On x86, there's a much bigger advantage, because x86 only really has two pairs of registers that can be used as 64-bit GPRs, so pretty much any 64-bit operation results in a stack spill. Going up to 16 64-bit GPRs on x86-64 makes a huge difference, but that's an x86-specific issue, not a general issue with 64-bit instruction sets in general.
I don't know how much of an overhead LPAE adds to execution, but no matter how small the overhead is no overhead at all is still better
LPAE adds one extra layer to the page tables. 64-bit mode adds at least one and typically three extra layers to the page tables (depending on page size). This means that there is less overhead (TLB misses require fewer cache lines / memory accesses to fill) in LPAE mode than in 64-bit mode.
Also, I am not sure if I have misunderstood something or not, but I've gotten the impression that even with LPAE the OS can access up to 1TB of memory, but the 32bit applications are still confined to 4GB.
That is true, more or less, however it's unlikely to be an issue. I am currently typing this from a laptop running a 64-bit OS on a 64-bit CPU. The largest process (counting virtual address space used) I have running is a VirtualBox VM, which has 2.18GB mapped. The next largest has 1.09GB. All of the rest are under 1GB. On a mobile phone, applications tend to be even smaller.
[1] Note, however, that the calling convention specifies that 64-bit integer values are passed in pairs of integer registers, so it's often cheaper to do a short sequence of operations on the main pipeline than copy the value to a NEON register.
For example, we wouldn't have an Objective C compiler if NeXT hadn't been forced to release it in order to comply with the GPL.
Speaking as the person who wrote and maintains the GNUstep libobjc and the clang support for it: Bullshit. The GPL forced NeXT to open source half of the implementation (the compiler support, not the runtime), and their implementation was such a pile of crap that it set back GCC's support for a long time. Open source support for Objective-C in clang is so much better than in GCC that it's not even worth comparing the two.
The best way to combat this is to use representative democracy, but allow different candidates on different types of issue. It does, however, need careful implementation or you get the problem found in California where people can vote to require the government to do something and vote against allowing them to raise enough taxes to be able to afford it.
Of course it wasn't found prior to the last 100 years. HIV is difficult to detect with current medical technology, and the most obvious effect is AIDS. But no one dies of AIDS, they die of whatever their weakened immune system was unable to fight off, such as a common cold.
Oh, and which government do you think had the ability to engineer a lentivirus 100 years ago? Because I'd like them to provide my healthcare...
Most typical user applications are not even remotely CPU-bound anyway, even on a 1GHz ARM CPU. Most of the ones that are can be parallelised relatively easily, and often are. The vast majority of software these days falls into one of two categories: stuff that was fast enough some time ago, and stuff that can always consume as much CPU power as you throw at it. The former doesn't need parallelising, and the latter is usually already parallel.
The problem is, most people who fly frequently don't have the option. For example, my travel is paid by the US government and so I have to follow their rules, which includes the Fly America Act (a ludicrous piece of protectionist legislation that meant that I had to fly from London to Ottawa via the USA instead of directly, and at a higher cost), I can only fly economy class, and I must take the cheapest quote. Most companies have similar rules on the cost, except for management. This is why business class exists at all: a lot of companies had a rule saying that people weren't allowed to fly first class, so the airlines introduced a tier that was almost exactly the same but with a different name (since then, they've eroded what you get in first class quite considerably).
I disagree. There is a solution, and it's the same one that I've previously proposed for similar inequalities in environmental and employee regulations. You define a set of minimum rules for all of these things. Any goods from countries that meet those minimum standards may be imported without any fees at the border. Any goods from elsewhere have an import duty in proportion to the amount that was saved by producing them there. If a company hides most of its profits in a foreign jurisdiction then that's fine, unless they sell anything locally at which point it's hit with a massive levy. You bring it in over a period of about a decade, gradually increasing the rates so that it doesn't provide too much of a shock to the market.
Okay, so if I'm looking for an app, how do I search Google Play saying I want to find one that doesn't require the permission to access my address book or the contents of my SD card? You get shown the permissions right before you download an app, but you don't ever get told why an application needs these permissions.
No you aren't. You only need to provide an offer, good for 3 years, to provide the source code for a nominal fee. If you are distributing the source code unmodified, then you can provide a copy of the offer that you received from upstream[1]. Any Linux ISO that you download will also contain this offer, so by passing it on unmodified you are not violating the GPL.
[1] This actually provides a fairly simple loophole if you're willing to wait three years: take some GPL code, modify it, and give it to a third party. They then sit on it for three years and then sell it as a binary-only product. They pass on your (now expired) offer, and no one has the right to demand the source code from you.
They tried the migrations because management has heard about this Linux thing and thinks it's cool. They failed, because they have invested a lot in customising FreeBSD (including a lot of stuff they upstream, and some that they don't) and unless management is willing to spend at least as much on Linux the switch is going to fail. The only sources I have are conversations with Yahoo employees.
This isn't the first time that this has happened. Cisco owned the trademarks on both iPhone and IOS when Apple launched the device. Apple now licenses these both from Cisco. The other high-profile example is Rendezvous, Apple's name for ZeroConf, which just so happened to be the name of someone else's product that did something similar. They had to rebrand all of their Rendezvous stuff as Bonjour. Apple and Google both have a tendency to skip trademark searches and just launch products, then deal with the fallout if anyone complains.
The trick is that most other companies who use this technology helped to create it. They each charge each other 2.25% or thereabouts, but because they are all charging each other this much, they end up just paying each other the difference. So if, for example, Samsung, Nokia, and Motorola are all paying each other somewhere between 1 and 2.5%, the end result may be that each one ends up paying 1% or less to just one of the others (or just receiving money).
This mostly works, because defining a standard like UMTS or LTE requires a huge amount of expensive R&D and it's better if multiple companies can share the cost. The problem comes when someone else wants to enter the market. They then end up paying all of these license fees, which may be 10-20% of the total device cost if they're paying around 2% to everyone who contributed to the standard. If it gets too high, this makes it impossible for new players to enter the market. If it's too low, then it means that the best strategy is to spend no money at all on R&D, wait for everyone else to do the expensive bit, and then just use their results.
The problem in this case is that Apple is a new entrant into the market and so needs to license these patents from everyone else. They are claiming that patents like touch gestures (which they copied from someone else) and the shape of a tablet are of equal value to patents on radio transmission and encoding techniques that took expensive R&D over a period of years to produce. The other players are seeing this as an opportunity to use their large patent portfolio to keep a new player out of the market.
The best solution would probably be for the standards bodies to buy all of the relevant patents outright at something like R&D cost + n% and then charge licenses at a rate that would diminish until the cost was completely paid for and then allow the patents to lapse. This would give an incentive to do the R&D (you get the money back, plus a profit) and an incentive to license the patents early (you get first-mover advantage), but not penalise late entrants too much (the cost of entering the market becomes progressively lower over time).
Re:WTF is this about Theo or OpenBSD?
on
OpenBSD 5.2 Released
·
· Score: 4, Interesting
The problem is that Theo treats developers badly. We've had a few ex-OpenBSD developers join FreeBSD, and NetBSD has been more successful (their kernel is more similar, so it's probably an easier migration path) because Theo's rudeness has been the last straw for them. He's also prevented new developers, such as the author of mult (something like recursive jails) from joining the project. This doesn't affect users directly, but if the developers start going elsewhere then it means that the platform evolves more slowly and does affect users.
Steve Jobs was undoubtedly also an asshole to his employees, but typically only those that interacted with him directly (and were therefore the fairly senior people, not the ones doing most of the implementation work) and Apple had one advantage that OpenBSD doesn't: it was paying those developers directly.
Yes, including some contributed by vendors. For example, we approved a commit bit a few months ago for another person on Intel's network driver team. That said, being polite to companies doesn't really get drivers written. They don't care about us, they care about their customers. When Yahoo says to Intel 'we're buying 10,000 new machines this month and they're all going to be running FreeBSD, what network interface would you suggest?' then they suddenly start thinking that getting good FreeBSD drivers is worthwhile.
Re:OBSD firewalls vs others - what's the diff?
on
OpenBSD 5.2 Released
·
· Score: 5, Interesting
Aren't Juniper's OS BSD based?
Juniper was a fork of an old FreeBSD. They've recently realised quite how expensive maintaining a fork is and have started pushing most of their stuff upstream and minimising their divergence. We just granted commit access to another Juniper person (sjg@), who is going to work on bringing their improvements to the build system back into the mainline.
All BSDs, from what I understand, use PF
Yes, although OpenBSD is the only one to remove the other firewalling mechanisms. I think we now have 3 firewalls in the FreeBSD kernel and there was some talk of importing npf from NetBSD, making it 4. On of my projects for the next few years is to look at some of the packet filtering infrastructure and make ipf, pf, and friends all simple compiler front ends to the same generic packet filtering infrastructure.
how is OpenBSD better than other FreeBSD based distros
I'm on the FreeBSD Core Team, so I have some fairly obvious biases, but there are a few reasons to prefer OpenBSD. Historically, they've been a bit more proactive at enabling things like stack canaries, no execute, and address space randomisation by default. On the other hand, they don't yet have anything like capsicum, so by FreeBSD 10 you'll see a lot more privilege-separated code on FreeBSD than on OpenBSD. Performance for OpenBSD was a bit better for firewall applications than FreeBSD's import of pf, because we had an older version. I'm not sure if that's still true: Netflix has contributed a lot of performance improvements to our network stack recently (it turns out that they shift quite a lot of packets using FreeBSD) and so this may no longer be true.
I ran OpenBSD on a router for a little while because it was easy to admin via ssh. pfSense uses PHP for the web interface, which consumes 20-30MB of RAM for every action. On a router with 64MB of RAM, this is basically a deal breaker.
Slashdot Mirror
For a long time, laptop components were vastly more expensive than their desktop counterparts. Part of this was due to their stricter requirements (smaller, lower power, and so on), but a big factor was the economies of scale. For every laptop part you sold, you'd sell 20 or more of the desktop equivalent. This changed significantly once laptop sales passed desktop. Now, for example, the cost of DDR3 SO-DIMMs and full-sized DIMMs is the same (up to 8GB modules, at least). When everyone is buying SSDs for their laptops and servers, it becomes increasingly expensive to keep producing hard drives for a shrinking niche.
No, he's talking about a representative democracy. You elect someone who represent your interests, not necessarily your opinions.
Part of the problem is that politics is now a career. I wouldn't mind doing the job for a year, maybe two if I could do it part time - say two days a week so I could keep doing stuff that's actually interesting as well. There's no way I'd want to spend even five years, let alone the 20-30 that most politicians seem to have to put in.
It was easy to criticise Itanium at the time, in comparison to Alpha, or PowerPC too. If we'd somehow all been forced to rewrite all of our legacy x86 code, either of these would have been a better choice. In fact, emulating x86 on PowerPC is a lot easier than on Itanium, so it would have been a more natural path if Intel had managed to kill x86. Lucky for them, they failed...
OpenVMS and NonStop effectively only run on Alpha and a surprising number of companies have mission-critical software that works on one of these two platforms.
It keeps being repeated because it's almost true. Manufacturing hasn't gone down in the USA, but manufacturing employment has. Just like in the first industrial revolution, the number of people required to manufacture goods has dropped considerably. China had a small short-term advantage because, for certain things, it was cheaper to use poorly-paid workers than machines, but even that's changing. Lots of people are talking as if Chinese factory workers are competing against American factory workers and winning because they're paid a fraction of the amount, but that's not really the case. 10-100 Chinese factory workers are competing against one American factory worker and a large automated assembly line. They were winning because they have lower capital costs, but higher operational costs. Now that companies like Foxconn have large amounts of capital to play with, they're starting to lose again.
People keep talking as if bringing manufacturing back to the USA will make a difference for the local economy, but it won't. The mindset that a new factory will employ thousands of people and provide employment either directly or indirectly for an entire town is obsolete. This doesn't, of course, stop local governments giving companies millions of dollars in tax breaks to build a factory, and then acting surprised when it only creates a hundred or so new jobs.
The first industrial revolution had a lot of social unrest because of the wealth-redistribution that the automation caused, concentrating it in the hands of the factory owners. This one is likely to have many of the same problems. Unfortunately, we didn't find a good solution last time.
I'm not sure about the one in TFA, but one of the big differences in the prototype that I saw was that it used eInk instead of a traditional LCD for the display. This means that the battery life is a whole lot better. That, combined with improvements in battery technology means that it's possible to create one that will last for longer than the lifetime of a credit card and be able to create cryptographic tokens for this entire time. Oh, and I think you're misremembering the thickness of the 'credit card sized' calculators in the '80s. They were at least 2-3 times the thickness of a normal card. This is exactly the same size, and so works with magnetic strip and chip-and-pin readers as well.
Why would I want to carry one of these gadgets around when I already have a smartphone which can do the same job?
You answered this question in your first paragraph. A mobile phone application runs on a general purpose OS (which, unless its an iPhone or a Google-branded Android phone, probably has a load of old and buggy libraries and kernel because your carrier doesn't push out updates sufficiently competently). Even if the app itself is perfectly written, the TCB contains a whole load of other stuff that really shouldn't be trusted - you install one malicious app by mistake (or visit one malicious web page with a browser that has a known exploit that is fixed upstream but the fix never pushed to you) and your bank account is compromised.
In contrast, the device on the card is running a simple OS, has no network communication, and is basically impossible to trojan without physical access and disassembly.
By the way, we have the Singapore banking regulator to thank for a number of things, including two-factor authentication for online banking. They were the ones that insisted that it had to be provided by all banks doing business in Singapore, and the big banks decided that it was cheaper to roll it out worldwide than have a single system for Singapore. They also have very strict rules (and impose fines for violations) regarding security and disclosure.
It's not that simple. 64bit instructions can handle more data per cycle than 32bit ones, so there is an increase in performance whenever you handle large amounts of data and/or large numbers
The first is that the size of the address space corresponds to data size. NEON, the ARM vector instruction set, can already perform operations on 64-bit integer or floating point values[1]. This is even true on x86, where you have 64-bit operations that work on a pair of registers. The advantage is that you have 64-bit registers, so you don't need to use two for each 64-bit operation (6 of your 14 GPRs on ARMv7 if you want two source and one destination, compared to 3 of your 31 GPRs on ARMv8). On x86, there's a much bigger advantage, because x86 only really has two pairs of registers that can be used as 64-bit GPRs, so pretty much any 64-bit operation results in a stack spill. Going up to 16 64-bit GPRs on x86-64 makes a huge difference, but that's an x86-specific issue, not a general issue with 64-bit instruction sets in general.
I don't know how much of an overhead LPAE adds to execution, but no matter how small the overhead is no overhead at all is still better
LPAE adds one extra layer to the page tables. 64-bit mode adds at least one and typically three extra layers to the page tables (depending on page size). This means that there is less overhead (TLB misses require fewer cache lines / memory accesses to fill) in LPAE mode than in 64-bit mode.
Also, I am not sure if I have misunderstood something or not, but I've gotten the impression that even with LPAE the OS can access up to 1TB of memory, but the 32bit applications are still confined to 4GB.
That is true, more or less, however it's unlikely to be an issue. I am currently typing this from a laptop running a 64-bit OS on a 64-bit CPU. The largest process (counting virtual address space used) I have running is a VirtualBox VM, which has 2.18GB mapped. The next largest has 1.09GB. All of the rest are under 1GB. On a mobile phone, applications tend to be even smaller.
[1] Note, however, that the calling convention specifies that 64-bit integer values are passed in pairs of integer registers, so it's often cheaper to do a short sequence of operations on the main pipeline than copy the value to a NEON register.
For example, we wouldn't have an Objective C compiler if NeXT hadn't been forced to release it in order to comply with the GPL.
Speaking as the person who wrote and maintains the GNUstep libobjc and the clang support for it: Bullshit. The GPL forced NeXT to open source half of the implementation (the compiler support, not the runtime), and their implementation was such a pile of crap that it set back GCC's support for a long time. Open source support for Objective-C in clang is so much better than in GCC that it's not even worth comparing the two.
The best way to combat this is to use representative democracy, but allow different candidates on different types of issue. It does, however, need careful implementation or you get the problem found in California where people can vote to require the government to do something and vote against allowing them to raise enough taxes to be able to afford it.
Oh, and which government do you think had the ability to engineer a lentivirus 100 years ago? Because I'd like them to provide my healthcare...
Yes, but the down side is that it also comes with a strong attraction towards other people who also have fashion sense and a higher mean income.
Most typical user applications are not even remotely CPU-bound anyway, even on a 1GHz ARM CPU. Most of the ones that are can be parallelised relatively easily, and often are. The vast majority of software these days falls into one of two categories: stuff that was fast enough some time ago, and stuff that can always consume as much CPU power as you throw at it. The former doesn't need parallelising, and the latter is usually already parallel.
The problem is, most people who fly frequently don't have the option. For example, my travel is paid by the US government and so I have to follow their rules, which includes the Fly America Act (a ludicrous piece of protectionist legislation that meant that I had to fly from London to Ottawa via the USA instead of directly, and at a higher cost), I can only fly economy class, and I must take the cheapest quote. Most companies have similar rules on the cost, except for management. This is why business class exists at all: a lot of companies had a rule saying that people weren't allowed to fly first class, so the airlines introduced a tier that was almost exactly the same but with a different name (since then, they've eroded what you get in first class quite considerably).
I disagree. There is a solution, and it's the same one that I've previously proposed for similar inequalities in environmental and employee regulations. You define a set of minimum rules for all of these things. Any goods from countries that meet those minimum standards may be imported without any fees at the border. Any goods from elsewhere have an import duty in proportion to the amount that was saved by producing them there. If a company hides most of its profits in a foreign jurisdiction then that's fine, unless they sell anything locally at which point it's hit with a massive levy. You bring it in over a period of about a decade, gradually increasing the rates so that it doesn't provide too much of a shock to the market.
Okay, so if I'm looking for an app, how do I search Google Play saying I want to find one that doesn't require the permission to access my address book or the contents of my SD card? You get shown the permissions right before you download an app, but you don't ever get told why an application needs these permissions.
No you aren't. You only need to provide an offer, good for 3 years, to provide the source code for a nominal fee. If you are distributing the source code unmodified, then you can provide a copy of the offer that you received from upstream[1]. Any Linux ISO that you download will also contain this offer, so by passing it on unmodified you are not violating the GPL.
[1] This actually provides a fairly simple loophole if you're willing to wait three years: take some GPL code, modify it, and give it to a third party. They then sit on it for three years and then sell it as a binary-only product. They pass on your (now expired) offer, and no one has the right to demand the source code from you.
They tried the migrations because management has heard about this Linux thing and thinks it's cool. They failed, because they have invested a lot in customising FreeBSD (including a lot of stuff they upstream, and some that they don't) and unless management is willing to spend at least as much on Linux the switch is going to fail. The only sources I have are conversations with Yahoo employees.
This isn't the first time that this has happened. Cisco owned the trademarks on both iPhone and IOS when Apple launched the device. Apple now licenses these both from Cisco. The other high-profile example is Rendezvous, Apple's name for ZeroConf, which just so happened to be the name of someone else's product that did something similar. They had to rebrand all of their Rendezvous stuff as Bonjour. Apple and Google both have a tendency to skip trademark searches and just launch products, then deal with the fallout if anyone complains.
Yes. And they still employ quite a few FreeBSD developers. Apparently they just finished another failed attempt to migrate to Linux.
The trick is that most other companies who use this technology helped to create it. They each charge each other 2.25% or thereabouts, but because they are all charging each other this much, they end up just paying each other the difference. So if, for example, Samsung, Nokia, and Motorola are all paying each other somewhere between 1 and 2.5%, the end result may be that each one ends up paying 1% or less to just one of the others (or just receiving money).
This mostly works, because defining a standard like UMTS or LTE requires a huge amount of expensive R&D and it's better if multiple companies can share the cost. The problem comes when someone else wants to enter the market. They then end up paying all of these license fees, which may be 10-20% of the total device cost if they're paying around 2% to everyone who contributed to the standard. If it gets too high, this makes it impossible for new players to enter the market. If it's too low, then it means that the best strategy is to spend no money at all on R&D, wait for everyone else to do the expensive bit, and then just use their results.
The problem in this case is that Apple is a new entrant into the market and so needs to license these patents from everyone else. They are claiming that patents like touch gestures (which they copied from someone else) and the shape of a tablet are of equal value to patents on radio transmission and encoding techniques that took expensive R&D over a period of years to produce. The other players are seeing this as an opportunity to use their large patent portfolio to keep a new player out of the market.
The best solution would probably be for the standards bodies to buy all of the relevant patents outright at something like R&D cost + n% and then charge licenses at a rate that would diminish until the cost was completely paid for and then allow the patents to lapse. This would give an incentive to do the R&D (you get the money back, plus a profit) and an incentive to license the patents early (you get first-mover advantage), but not penalise late entrants too much (the cost of entering the market becomes progressively lower over time).
The problem is that Theo treats developers badly. We've had a few ex-OpenBSD developers join FreeBSD, and NetBSD has been more successful (their kernel is more similar, so it's probably an easier migration path) because Theo's rudeness has been the last straw for them. He's also prevented new developers, such as the author of mult (something like recursive jails) from joining the project. This doesn't affect users directly, but if the developers start going elsewhere then it means that the platform evolves more slowly and does affect users.
Steve Jobs was undoubtedly also an asshole to his employees, but typically only those that interacted with him directly (and were therefore the fairly senior people, not the ones doing most of the implementation work) and Apple had one advantage that OpenBSD doesn't: it was paying those developers directly.
Yes, including some contributed by vendors. For example, we approved a commit bit a few months ago for another person on Intel's network driver team. That said, being polite to companies doesn't really get drivers written. They don't care about us, they care about their customers. When Yahoo says to Intel 'we're buying 10,000 new machines this month and they're all going to be running FreeBSD, what network interface would you suggest?' then they suddenly start thinking that getting good FreeBSD drivers is worthwhile.
Aren't Juniper's OS BSD based?
Juniper was a fork of an old FreeBSD. They've recently realised quite how expensive maintaining a fork is and have started pushing most of their stuff upstream and minimising their divergence. We just granted commit access to another Juniper person (sjg@), who is going to work on bringing their improvements to the build system back into the mainline.
All BSDs, from what I understand, use PF
Yes, although OpenBSD is the only one to remove the other firewalling mechanisms. I think we now have 3 firewalls in the FreeBSD kernel and there was some talk of importing npf from NetBSD, making it 4. On of my projects for the next few years is to look at some of the packet filtering infrastructure and make ipf, pf, and friends all simple compiler front ends to the same generic packet filtering infrastructure.
how is OpenBSD better than other FreeBSD based distros
I'm on the FreeBSD Core Team, so I have some fairly obvious biases, but there are a few reasons to prefer OpenBSD. Historically, they've been a bit more proactive at enabling things like stack canaries, no execute, and address space randomisation by default. On the other hand, they don't yet have anything like capsicum, so by FreeBSD 10 you'll see a lot more privilege-separated code on FreeBSD than on OpenBSD. Performance for OpenBSD was a bit better for firewall applications than FreeBSD's import of pf, because we had an older version. I'm not sure if that's still true: Netflix has contributed a lot of performance improvements to our network stack recently (it turns out that they shift quite a lot of packets using FreeBSD) and so this may no longer be true.
I ran OpenBSD on a router for a little while because it was easy to admin via ssh. pfSense uses PHP for the web interface, which consumes 20-30MB of RAM for every action. On a router with 64MB of RAM, this is basically a deal breaker.