I have a lot of respect for most of the OpenBSD team, but Theo is definitely trolling here.
Let's start with the premise of TFA, which cites the article on Ars that was covered here a few days ago and was complete nonsense about the new random number infrastructure in FreeBSD. We are not moving away from using the hardware random number generator directly, we have never used the hardware random number generator. The new code that the Ars article was talking about is to allow the PRNG to be easily switched. In 10 we're shipping both Fortuna and Yarrow and the infrastructure allows more to be added. The code has been reviewed by two cryptographers that I know of and possibly others. Neither the old nor the new implementation is vulnerable to the attack against random number generators that was published a couple of months ago (Linux was the subject of the paper, not sure if OpenBSD was vulnerable).
If Theo is going to make such remarks as this, he should think more carefully first:
"Basically, it is 10 years of FreeBSD stupidity. They don't know a thing about security. They even ignore relevant research in all fields, not just from us, but from everyone."
He'd be advised to take a look at the transactions for the IEEE Symposium on Security and Privacy over the last 10 years and see how many papers are describing techniques that were both originally implemented on FreeBSD and are now part of the default install. Let's take a look at the two systems, from a security perspective. Both FreeBSD use SSP and non-excutable stack by default, so I'll skip those. To begin with, OpenBSD features missing on FreeBSD:
W^X enforcement. Definitely a nice idea, but it breaks some things (JITs mostly). The default memory map in FreeBSD is W^X, but it is possible to explicitly mmap() memory both writeable and executable. It's generally considered a bad idea though, and we don't ship any code that allows it. We permit third-party code to shoot itself in the foot if it really wants to and provide mitigation techniques to reduce the risk.
Then there's ASLR. This is a pretty nice technique, which is currently not implemented on FreeBSD. We do support PIE, so it would not be a horrendously difficult thing to add, but current implementations (including OpenBSD) use a surprisingly small amount of entropy in the address layout and so don't provide as much mitigation as you'd hope (which, of course, Theo knows, because he's very familiar with 'relevant research'). This is especially true on 32-bit systems.
And that's it for OpenBSD. Well, unless you want to count , but since that's vulnerable to a timing attack (still not fixed), which was published in the USENIX Workshop on Offensive Technologies, and Theo is aware of all 'relevant research' in security then it can't really still be there.
Now let's look at FreeBSD security mechanisms:
First up, jails. Jails are somewhere between a chroot and a VM: a shared kernel, but all of the global namespaces (filesystems, IP addresses, users) are separated and so you can completely isolate a service, such as a web browser, from the rest of the system. Scripts like ez-jail in the ports tree make it easy to set up lightweight service jails.
Then there's the MAC framework, which allows modular access control policies. This is used by a couple of FreeBSD derivatives: JunOS uses it to implement code signing, OS X and iOS use it for application sandboxing. You can also use it for traditional type enforcement policies, as in SELinux and a variety of other things.
And then there's Capsicum, which adds a capability model on top
Netflix is a nice example, but if you use the Internet the first thing you probably do is use DNS. Verisign's root servers and the TLD servers that they run all use a 50:50 mix of FreeBSD and Linux (diversity is important, because if there's an exploit for one then they can just turn that one off until it's fixed. They also run different resolvers and so on).
I'd take issue with your second point. All binary updates using freebsd-update are signed and that mechanism is used to distribute the signing keys for packages. When you do 'pkg install' on a recent FreeBSD system, it will bail if the packages don't match the signature. We also have a revocation system in place that allows us to easily revoke keys if the package building system is compromised. We just received a large grant from Google to work on package transparency, a mechanism akin to certificate transparency that allows you to validate not just that your packages are signed, but that they're the same packages everyone else is getting. We do have deterministic builds for the base system (they're needed for the binary update mechanism to work), but not currently for ports - that's something we're working on though, as it's a prerequisite for package transparency.
The authoritative repository is svn, but there are numerous git mirrors, and we did use them to validate svn after the compromise last year. svn is actually not that hard to audit, but cvs (which OpenBSD uses) is a nightmare - we gave up trying to audit it and just re-exported the cvs mirror from svn.
Not necessarily. A lot of email virus scanners will pre-fetch images and follow links in emails, for example. They'll do it even if they're just forwarding the mail to another server, and sometimes before the mail even gets to the delivery agent.
Did you know that with some kind of explosive (preferably one that you can remotely detonate) and some coins (easily available) you probably can kill or severely injure a lot more people than you can with a firearm? The ensuring explosion is like a frag grenade, except you can make it a lot bigger and lethal. Bonus points for triggering it in a cafeteria o some other kind of eating place with lots of people.
As another poster said, this requires a lot more premeditation. A nail bomb is pretty easy to assemble with ingredients that are readily available in most industrialised nations, but doing so requires (at the very least) a few hours of work. If you want timed detonation, that's more thought and planning, and you need to be quite calm while building the bomb or you're likely to just blow your hands off. Most people, by the time they've even got as far as thinking through how they'd go about blowing up their school will have calmed down enough to realise that it's a bad idea.
In contrast, if a gun is readily available then you just need to pick it up and, while still angry, got back to the school and start shooting. You don't need to think hard about what you're doing. That's one of the rationales behind laws that require a 24 hour or 7 day period between ordering a gun and getting it - if you want to kill someone in cold blood, you'll find a way of doing it with or without a gun, but if you're thinking of doing it because you're stressed or angry, then there's a good chance you'll have changed your mind by the end of the cooling off period. Of course, if you go ahead and buy the gun, there's nothing to stop you the next time you get stressed...
It depends on the implementation. As I recall, the Intel ones are basically just a pair of flipflops in an unstable configuration for each bit. They're intended to be something that toggles between 0 and 1 at some frequency that you can't easily determine (and which isn't the same for each bit). However, as they're digital circuits, they do respond to heat. Hopefully, they don't respond in a way that makes the readings more predictable, but it would take a lot of analysis to be sure of that.
In the UK, this is referred to as Local Loop Unbundling (LLU), and it was promised to bring in more competition. It does, to a degree, but installing the equipment at the exchanges is very expensive. They're also BT was forced to separate its wholesale and retail businesses into separate business units, and provide the lines at the same price to competitors as they provide to their retail business unit. There are several problems with this though. If you buy broadband via this latter option, you need to pay line rental to BT Retail, which is stupidly expensive (around £15/month, and then calls on weekdays cost more than I pay from my prepay [no line rental] mobile phone) and bumps up the profits of BT Retail. There's then no requirement for BT Retail to make any profit on broadband, and so they can afford to undercut competitors who actually need to make a profit.
If they'd done it in the '80s, that would have been a good idea, however even if they did get the North Sea reserves, they're almost gone now, so it's not a good long-term strategy.
A good paper is not necessarily a paper that will win a Nobel prize. If you're just sitting there and thinking really hard, hoping for inspiration to strike, then you'll have difficulty doing this. For everyone else, you always have intermediate results that give you something useful and it's incredibly valuable to share these with the wider community so you don't end up with everyone doing the same work in secret. If you can't manage to publish at even this rate, then you are being far too secretive about your work to justify an academic position.
Oh, and it's not once a year, it's once a year on average, over four years. So if you work on a big project for 2-3 years and then get a flurry of papers out at the end, then that's fine too.
Given the northward flow of tax money in the UK currently, Scottish Independence would mean that the government of the rest of the UK could immediately end all of the austerity cuts. Meanwhile, the Scottish government would be trying to get comparable handouts from the EU (likely vetoed by Spain so that Catalan independence doesn't get any inspiration), or watching the economy tank. All of the benefits that Scotland gains from large proportions of the military being stationed there in peacetime would evaporate, as would the public sector contracts that have been helping to bootstrap the Scottish IT industry over the last few years.
The new FreeBSD randomness framework allows whitening algorithms (Yarrow, Fortuna, whatever) to be plugged in easily, along with multiple sources.
Linux initially trusted RDRNG unconditionally to provide streams of random numbers, then backtracked to only using it as an input to whitening. FreeBSD only ever used it as an input to the PRNG and now has a more generic framework for doing so.
Neither the new, or the old, FreeBSD random number generation framework is vulnerable to the attack published in October (and covered on Slashdot) on the Linux random number generator.
Trust in a random number generator is not a binary thing. All of the current hardware RNG implementations produce some entropy. The question is how much entropy you trust them to produce. If it gives 256 bits of entropy, then you can just use it as your random number source and be done with it. One that produces 16 bits of entropy is very useful as one (but not the sole) source to an algorithm like Yarrow of Fortuna, but would be a disaster if you used it as the random number generator without such an algorithm in the middle.
It is quite unlikely that the hardware RNG is compromised. It is, however, quite likely (and there have been experiments to show this for some RNG implementations) that it doesn't give as much entropy as advertised.
The big problem is that it's very hard to get good entropy early on in the boot process (when things like TCP sequence numbers and sometimes when SSH server keys are initially generated). You can use a hash of the kernel, but that's shared between other machines with the same kernel. You can use the time, but that's likely known to the attacker (and in some embedded systems will always be the same on every boot, until it queries an external source and corrects it). You can use interrupt times, but the ones from the disk / flash are likely to be similar, if not the same, across boots of the same kernel and the early network ones are susceptible to attack by people on the local network.
The hardware RNG definitely gives you some entropy, and so using it to stir the pool for Yarrow helps a lot here. Later on, there is a lot more entropy. As you start to get disk access patterns based on system use and network connections from a variety of sources, interrupt times give quite a lot of entropy. It still helps to mix in the hardware RNG, however.
As I said in another post, it's quite unlikely that the hardware is intentionally compromised (although it's a nice attack, so I wouldn't guarantee that future versions won't be), but it's very likely that it provides less entropy than advertised. This makes it fine for input into a PRNG like Yarrow of Fortuna (I think Fortuna made it into FreeBSD 10, if not it should be in 10.1), but not adequate for general use. The point of a PRNG algorithm like Yarrow is to generate an unpredictable sequence of numbers from some source entropy seed, which can change over time. As long as you have enough entropy, you will get a cryptographically secure sequence of pseudo-random numbers. All this work is doing is saying 'we trust the hardware to give us some entropy, but we don't trust it to give us all of the entropy that we need'.
This work has been ongoing for about a year, since long before the NSA stuff came out. The consensus has been for a while that some hardware random number generators give very good entropy, but some are very poor and it's difficult to tell without querying them a few million times and plotting the distribution which one you have. Add to that, some of them appear to be influenced by the temperature, and as Stephen Murdoch's attack on Tor showed influencing the temperature of someone else's server is not always as difficult as you'd think.
It seems quite unlikely that the hardware RNGs are tampered with, although it would be a very neat hypothetical attack if you could influence a specific RNG in such a way that you could reduce the entropy to, say, 16 bits within a larger space and only you be able to determine what the real space was, but it's very likely that some of them are quite bad. Adding Yarrow[1] makes you a bit safer, because there will be other entropy sources mixed in and so even a relatively poor RNG helps stir the pool.
[1] Or some other whitening algorithm - Yarrow is the default, but there are some newer ones that are better, at the cost of a footprint that is not desirable for embedded devices, and FreeBSD 10 now includes a framework to make it easy to plug in the one you want.
Which is a weird thing for someone to say about the UK university system. The RAE / REF count an average one paper per year. That is what counts towards the department's ranking (which determines its funding), and so that's what departments care about when hiring people for tenured positions. Will they have the four top-tier publications required for the top rank in the REF? (or fewer for universities that aren't aiming for the top rank). Someone who published 20 crappy papers will be far less attractive than someone who published four good papers, because they'll both have to nominate their four best papers for the assessment, and so the first person will look really bad in the next assessment.
The Research Excellence Framework (REF) is the ranking of UK universities. The REF replaces the older Research Assessment Exercise (RAE), which happened every four years. The last RAE was 4 years ago, and the current REF is just finishing. Established academics have to submit 4 research outputs since the last RAE / REF. These are usually papers, but can be other things (systems you've built and so on).
The REF is a really big deal in UK universities, because it directly impacts the availability of research grants. The CVs of individual researchers are taken into account, but the REF / RAE score of the department is the biggest factor. If you have 4 papers in top-tier publications (conferences or journals, depending on your field), then it's very easy to get hired in the run up to the REF, because a lot of second tier universities are looking to find people who will bump them up the rankings.
Conversely, if you don't have the 4 publications (or other impressive things), then it's very hard to get a tenured position, but if you're not averaging one good paper a year then there's probably something wrong with you as a researcher: part of the point of publicly funded research is that the results are communicated to the public, and if you're not doing this then you're not keeping up your end of the deal.
C++ was never a superset of C. The following code has always been valid C and never been invalid C++:
int class = 42;
There are numerous other examples. The interesting behaviour of sizeof() when you have a class and a variable of the same name is one of my favourites.
On the other hand, crowdfunding things like kickstarter make patronage a lot easier. You don't need to be able to afford to hire an orchestra to play, you just need to find enough other people who are willing to do so. There was an article a few months ago about an effort to do this and produce high-quality public domain recordings of a large set of classical pieces.
We're in a world now where a band can produce an okay recording of a few songs in their living room, distribute it for free, and ask for funding for doing a studio recording of the whole album. They can then distribute the album for free and ask for funding for the next one (and bookings for gigs and so on). They're free to set the threshold cost for the next album to whatever they want, and if they have enough fans that think it's worth chipping in for, then it gets made and they get paid.
VMS managed to get the idea of the platform ABI specifying procedure call conventions right very early on. It had quite an easy job though. C, BASIC and Fortran are all structured programming languages with basically the same set of primitive types. None of them have (or, in the VMS days, had) classes, late binding, or real garbage collection. BASIC is kind-of GC'd, but it doesn't have pointers and so everything passed across the language barrier from BASIC was by value, so the GC didn't have to do anything clever.
It's worth remembering that when VMS was introduced, other platforms were still having problems getting C and Pascal to play nicely together (Pascal pushing arguments onto the stack in the opposite order to C), so that's not to belittle the achievement of VMS, but it's a very different world now that we have Simula and Smalltalk families of object orientation, various branches of functional languages, languages like Go and Erlang with (very different) first-class parallelism, and so on.
I talk a bit about.NET in TFA. It does some things right, but it still struggles with things like mutability. If you use F#, you get a language that is a lot like OCaml, and if you use it like OCaml, then it's fine. When you start trying to integrate with C#, then you find that they have different concepts of mutability. And you have to do it because the F# collection classes are much slower than their C# counterparts because the CLR lacks most of the optimisations that a typical OCaml implementation has to elide copies of immutable structures when your operation is implicitly destructive.
A lot of people do, and that's part of the problem. They're made from a kind of plastic that is designed to break down in exposure to ultraviolet. Store one in direct sunlight and it will turn to dust in a few months. Unfortunately, when they're stuck in the ground, they stay there for ages. The real solution would be developing a kind of plastic that doesn't break down in ultraviolet, but does in the presence of something in landfill. Presumably bin bags are made of something intended to be like that?
This is the big one. It's quite common to pop into a shop on the way home, and unless you're driving you won't have a bag with you. I'd love it if shops would give you a bag for a deposit and return the deposit when you returned the bag.
Slashdot Mirror
Let's start with the premise of TFA, which cites the article on Ars that was covered here a few days ago and was complete nonsense about the new random number infrastructure in FreeBSD. We are not moving away from using the hardware random number generator directly, we have never used the hardware random number generator. The new code that the Ars article was talking about is to allow the PRNG to be easily switched. In 10 we're shipping both Fortuna and Yarrow and the infrastructure allows more to be added. The code has been reviewed by two cryptographers that I know of and possibly others. Neither the old nor the new implementation is vulnerable to the attack against random number generators that was published a couple of months ago (Linux was the subject of the paper, not sure if OpenBSD was vulnerable).
If Theo is going to make such remarks as this, he should think more carefully first:
"Basically, it is 10 years of FreeBSD stupidity. They don't know a thing about security. They even ignore relevant research in all fields, not just from us, but from everyone."
He'd be advised to take a look at the transactions for the IEEE Symposium on Security and Privacy over the last 10 years and see how many papers are describing techniques that were both originally implemented on FreeBSD and are now part of the default install. Let's take a look at the two systems, from a security perspective. Both FreeBSD use SSP and non-excutable stack by default, so I'll skip those. To begin with, OpenBSD features missing on FreeBSD:
W^X enforcement. Definitely a nice idea, but it breaks some things (JITs mostly). The default memory map in FreeBSD is W^X, but it is possible to explicitly mmap() memory both writeable and executable. It's generally considered a bad idea though, and we don't ship any code that allows it. We permit third-party code to shoot itself in the foot if it really wants to and provide mitigation techniques to reduce the risk.
Then there's ASLR. This is a pretty nice technique, which is currently not implemented on FreeBSD. We do support PIE, so it would not be a horrendously difficult thing to add, but current implementations (including OpenBSD) use a surprisingly small amount of entropy in the address layout and so don't provide as much mitigation as you'd hope (which, of course, Theo knows, because he's very familiar with 'relevant research'). This is especially true on 32-bit systems.
And that's it for OpenBSD. Well, unless you want to count , but since that's vulnerable to a timing attack (still not fixed), which was published in the USENIX Workshop on Offensive Technologies, and Theo is aware of all 'relevant research' in security then it can't really still be there.
Now let's look at FreeBSD security mechanisms:
First up, jails. Jails are somewhere between a chroot and a VM: a shared kernel, but all of the global namespaces (filesystems, IP addresses, users) are separated and so you can completely isolate a service, such as a web browser, from the rest of the system. Scripts like ez-jail in the ports tree make it easy to set up lightweight service jails.
Then there's the MAC framework, which allows modular access control policies. This is used by a couple of FreeBSD derivatives: JunOS uses it to implement code signing, OS X and iOS use it for application sandboxing. You can also use it for traditional type enforcement policies, as in SELinux and a variety of other things.
And then there's Capsicum, which adds a capability model on top
Netflix is a nice example, but if you use the Internet the first thing you probably do is use DNS. Verisign's root servers and the TLD servers that they run all use a 50:50 mix of FreeBSD and Linux (diversity is important, because if there's an exploit for one then they can just turn that one off until it's fixed. They also run different resolvers and so on).
I'd take issue with your second point. All binary updates using freebsd-update are signed and that mechanism is used to distribute the signing keys for packages. When you do 'pkg install' on a recent FreeBSD system, it will bail if the packages don't match the signature. We also have a revocation system in place that allows us to easily revoke keys if the package building system is compromised. We just received a large grant from Google to work on package transparency, a mechanism akin to certificate transparency that allows you to validate not just that your packages are signed, but that they're the same packages everyone else is getting. We do have deterministic builds for the base system (they're needed for the binary update mechanism to work), but not currently for ports - that's something we're working on though, as it's a prerequisite for package transparency.
The authoritative repository is svn, but there are numerous git mirrors, and we did use them to validate svn after the compromise last year. svn is actually not that hard to audit, but cvs (which OpenBSD uses) is a nightmare - we gave up trying to audit it and just re-exported the cvs mirror from svn.
Not necessarily. A lot of email virus scanners will pre-fetch images and follow links in emails, for example. They'll do it even if they're just forwarding the mail to another server, and sometimes before the mail even gets to the delivery agent.
Did you know that with some kind of explosive (preferably one that you can remotely detonate) and some coins (easily available) you probably can kill or severely injure a lot more people than you can with a firearm? The ensuring explosion is like a frag grenade, except you can make it a lot bigger and lethal. Bonus points for triggering it in a cafeteria o some other kind of eating place with lots of people.
As another poster said, this requires a lot more premeditation. A nail bomb is pretty easy to assemble with ingredients that are readily available in most industrialised nations, but doing so requires (at the very least) a few hours of work. If you want timed detonation, that's more thought and planning, and you need to be quite calm while building the bomb or you're likely to just blow your hands off. Most people, by the time they've even got as far as thinking through how they'd go about blowing up their school will have calmed down enough to realise that it's a bad idea.
In contrast, if a gun is readily available then you just need to pick it up and, while still angry, got back to the school and start shooting. You don't need to think hard about what you're doing. That's one of the rationales behind laws that require a 24 hour or 7 day period between ordering a gun and getting it - if you want to kill someone in cold blood, you'll find a way of doing it with or without a gun, but if you're thinking of doing it because you're stressed or angry, then there's a good chance you'll have changed your mind by the end of the cooling off period. Of course, if you go ahead and buy the gun, there's nothing to stop you the next time you get stressed...
It depends on the implementation. As I recall, the Intel ones are basically just a pair of flipflops in an unstable configuration for each bit. They're intended to be something that toggles between 0 and 1 at some frequency that you can't easily determine (and which isn't the same for each bit). However, as they're digital circuits, they do respond to heat. Hopefully, they don't respond in a way that makes the readings more predictable, but it would take a lot of analysis to be sure of that.
In the UK, this is referred to as Local Loop Unbundling (LLU), and it was promised to bring in more competition. It does, to a degree, but installing the equipment at the exchanges is very expensive. They're also BT was forced to separate its wholesale and retail businesses into separate business units, and provide the lines at the same price to competitors as they provide to their retail business unit. There are several problems with this though. If you buy broadband via this latter option, you need to pay line rental to BT Retail, which is stupidly expensive (around £15/month, and then calls on weekdays cost more than I pay from my prepay [no line rental] mobile phone) and bumps up the profits of BT Retail. There's then no requirement for BT Retail to make any profit on broadband, and so they can afford to undercut competitors who actually need to make a profit.
If they'd done it in the '80s, that would have been a good idea, however even if they did get the North Sea reserves, they're almost gone now, so it's not a good long-term strategy.
Oh, and it's not once a year, it's once a year on average, over four years. So if you work on a big project for 2-3 years and then get a flurry of papers out at the end, then that's fine too.
Given the northward flow of tax money in the UK currently, Scottish Independence would mean that the government of the rest of the UK could immediately end all of the austerity cuts. Meanwhile, the Scottish government would be trying to get comparable handouts from the EU (likely vetoed by Spain so that Catalan independence doesn't get any inspiration), or watching the economy tank. All of the benefits that Scotland gains from large proportions of the military being stationed there in peacetime would evaporate, as would the public sector contracts that have been helping to bootstrap the Scottish IT industry over the last few years.
Now you cost us a good book !
Wait, I thought TFA was about Charles Stross?
Trust in a random number generator is not a binary thing. All of the current hardware RNG implementations produce some entropy. The question is how much entropy you trust them to produce. If it gives 256 bits of entropy, then you can just use it as your random number source and be done with it. One that produces 16 bits of entropy is very useful as one (but not the sole) source to an algorithm like Yarrow of Fortuna, but would be a disaster if you used it as the random number generator without such an algorithm in the middle.
The big problem is that it's very hard to get good entropy early on in the boot process (when things like TCP sequence numbers and sometimes when SSH server keys are initially generated). You can use a hash of the kernel, but that's shared between other machines with the same kernel. You can use the time, but that's likely known to the attacker (and in some embedded systems will always be the same on every boot, until it queries an external source and corrects it). You can use interrupt times, but the ones from the disk / flash are likely to be similar, if not the same, across boots of the same kernel and the early network ones are susceptible to attack by people on the local network.
The hardware RNG definitely gives you some entropy, and so using it to stir the pool for Yarrow helps a lot here. Later on, there is a lot more entropy. As you start to get disk access patterns based on system use and network connections from a variety of sources, interrupt times give quite a lot of entropy. It still helps to mix in the hardware RNG, however.
As I said in another post, it's quite unlikely that the hardware is intentionally compromised (although it's a nice attack, so I wouldn't guarantee that future versions won't be), but it's very likely that it provides less entropy than advertised. This makes it fine for input into a PRNG like Yarrow of Fortuna (I think Fortuna made it into FreeBSD 10, if not it should be in 10.1), but not adequate for general use. The point of a PRNG algorithm like Yarrow is to generate an unpredictable sequence of numbers from some source entropy seed, which can change over time. As long as you have enough entropy, you will get a cryptographically secure sequence of pseudo-random numbers. All this work is doing is saying 'we trust the hardware to give us some entropy, but we don't trust it to give us all of the entropy that we need'.
This work has been ongoing for about a year, since long before the NSA stuff came out. The consensus has been for a while that some hardware random number generators give very good entropy, but some are very poor and it's difficult to tell without querying them a few million times and plotting the distribution which one you have. Add to that, some of them appear to be influenced by the temperature, and as Stephen Murdoch's attack on Tor showed influencing the temperature of someone else's server is not always as difficult as you'd think.
It seems quite unlikely that the hardware RNGs are tampered with, although it would be a very neat hypothetical attack if you could influence a specific RNG in such a way that you could reduce the entropy to, say, 16 bits within a larger space and only you be able to determine what the real space was, but it's very likely that some of them are quite bad. Adding Yarrow[1] makes you a bit safer, because there will be other entropy sources mixed in and so even a relatively poor RNG helps stir the pool.
[1] Or some other whitening algorithm - Yarrow is the default, but there are some newer ones that are better, at the cost of a footprint that is not desirable for embedded devices, and FreeBSD 10 now includes a framework to make it easy to plug in the one you want.
Which is a weird thing for someone to say about the UK university system. The RAE / REF count an average one paper per year. That is what counts towards the department's ranking (which determines its funding), and so that's what departments care about when hiring people for tenured positions. Will they have the four top-tier publications required for the top rank in the REF? (or fewer for universities that aren't aiming for the top rank). Someone who published 20 crappy papers will be far less attractive than someone who published four good papers, because they'll both have to nominate their four best papers for the assessment, and so the first person will look really bad in the next assessment.
The Research Excellence Framework (REF) is the ranking of UK universities. The REF replaces the older Research Assessment Exercise (RAE), which happened every four years. The last RAE was 4 years ago, and the current REF is just finishing. Established academics have to submit 4 research outputs since the last RAE / REF. These are usually papers, but can be other things (systems you've built and so on).
The REF is a really big deal in UK universities, because it directly impacts the availability of research grants. The CVs of individual researchers are taken into account, but the REF / RAE score of the department is the biggest factor. If you have 4 papers in top-tier publications (conferences or journals, depending on your field), then it's very easy to get hired in the run up to the REF, because a lot of second tier universities are looking to find people who will bump them up the rankings.
Conversely, if you don't have the 4 publications (or other impressive things), then it's very hard to get a tenured position, but if you're not averaging one good paper a year then there's probably something wrong with you as a researcher: part of the point of publicly funded research is that the results are communicated to the public, and if you're not doing this then you're not keeping up your end of the deal.
There are numerous other examples. The interesting behaviour of sizeof() when you have a class and a variable of the same name is one of my favourites.
On the other hand, crowdfunding things like kickstarter make patronage a lot easier. You don't need to be able to afford to hire an orchestra to play, you just need to find enough other people who are willing to do so. There was an article a few months ago about an effort to do this and produce high-quality public domain recordings of a large set of classical pieces.
We're in a world now where a band can produce an okay recording of a few songs in their living room, distribute it for free, and ask for funding for doing a studio recording of the whole album. They can then distribute the album for free and ask for funding for the next one (and bookings for gigs and so on). They're free to set the threshold cost for the next album to whatever they want, and if they have enough fans that think it's worth chipping in for, then it gets made and they get paid.
VMS managed to get the idea of the platform ABI specifying procedure call conventions right very early on. It had quite an easy job though. C, BASIC and Fortran are all structured programming languages with basically the same set of primitive types. None of them have (or, in the VMS days, had) classes, late binding, or real garbage collection. BASIC is kind-of GC'd, but it doesn't have pointers and so everything passed across the language barrier from BASIC was by value, so the GC didn't have to do anything clever.
It's worth remembering that when VMS was introduced, other platforms were still having problems getting C and Pascal to play nicely together (Pascal pushing arguments onto the stack in the opposite order to C), so that's not to belittle the achievement of VMS, but it's a very different world now that we have Simula and Smalltalk families of object orientation, various branches of functional languages, languages like Go and Erlang with (very different) first-class parallelism, and so on.
I talk a bit about .NET in TFA. It does some things right, but it still struggles with things like mutability. If you use F#, you get a language that is a lot like OCaml, and if you use it like OCaml, then it's fine. When you start trying to integrate with C#, then you find that they have different concepts of mutability. And you have to do it because the F# collection classes are much slower than their C# counterparts because the CLR lacks most of the optimisations that a typical OCaml implementation has to elide copies of immutable structures when your operation is implicitly destructive.
Chocolate is like beer in the USA. You can find excellent examples, but it's far, far easier to find something absolutely terrible.
They're available for most commodity operating systems.
A lot of people do, and that's part of the problem. They're made from a kind of plastic that is designed to break down in exposure to ultraviolet. Store one in direct sunlight and it will turn to dust in a few months. Unfortunately, when they're stuck in the ground, they stay there for ages. The real solution would be developing a kind of plastic that doesn't break down in ultraviolet, but does in the presence of something in landfill. Presumably bin bags are made of something intended to be like that?
remember to bring to the store
This is the big one. It's quite common to pop into a shop on the way home, and unless you're driving you won't have a bag with you. I'd love it if shops would give you a bag for a deposit and return the deposit when you returned the bag.