As far as I'm aware, Europe (or, at least, the EU) has never had carrier locked phones. It's still common to buy them on contracts with a carrier, but if you cancelled the contract, you could immediately switch carrier with the device and continue using it. This isn't to say that carriers don't like bundling bloatware with their devices though.

That being said, it also helps that we don't have an odd mix of GSM and CDMA to contend with.

If you weren't already +5 informative, I would have up-voted you. pf has syntax so logical it's almost like speaking English. Then, in comparison, you have to memorize a variety of command flags to get anything done with iptables.

Mind you, personally i'm a FreeBSD user and (I think?) you can't actually get iptables for *BSD, and I don't have much use for a complicated firewall setup,

Actually, the reason that FreeBSD doesn't continue to receive upstream updates for PF is that the underlying code base to link it into the kernel has diverged too much from FreeBSD compatibility. This is compounded by the fact that the FreeBSD project has applied SMP patches to PF, which interferes with kernel interaction.

Whilst this is only partly relevant to the story, I thought it might be interesting to some non Europeans.

A popular trend in the UK at the moment for young drivers is to have their car fitted with a "black box" by the insurance company. The idea behind this box is that it monitors the "g-forces" it is exposed to, to gather an idea of how safely the owner is driving the vehicle. Throughout the year, the owner is graded on various aspects of their driving based on this telemetry. Also, I believe that the insurance companies can penalise the owner for driving at certain times, e.g. after 10pm on a friday night. The idea behind this is that the insurance company can charge the owner less, and if they do well after one year, the price drops dramatically.

Additionally, if the black box experience a very high braking force, it will automatically trigger the insurance company to ring your mobile to ask if you're okay, and if you need any help exchanging insurance details with any other drivers involved.

Anyway, back on point, I imagine it wouldn't be too difficult to add GPS facilities to these devices, and receive speed limit information based on location similarly to have satnav's currently do so. Obviously, for various reasons already mentioned by other posters, you would not want any restrictions to be physically enforced, but it could serve as a guide, or notice, to the driver.

Wasn't the whole reason one of the NSAs main schemes was called PRISM because it described the process they used to capture data. They would have optical fibre cables run through a junction box which would "split" the signal towards both the intended destination, and NSA hardware, therefore acting like a "prism". This therefore would both not affect latency, and not lower throughput.

I think it's fairly clear to see that autonomous cars are advancing to the point where they're starting to look feasible in mass deployment. However, one area I still think they're severely lacking is parking. Good luck telling a car to go to the town centre, drive into a multi-storey car park, pay at the machine, and find a space. I'm not saying it's not possible, but I've never actually seen an autonomous vehicle dynamically search for and select a parking space.

I suppose you could still have a system where the "driver" pays at parking barriers etc. until a more autonomous system was produced.

Sorry in advance if I missed some crucial piece of information relating to this in the last few weeks.

At what point exactly did we determine that Google was giving ANY information to the NSA of their own accord? (ignoring DMCAs and the like, as I don't think that's the NSAs job).

The whole point of PRISM is that it splits the light signal from fibre optic cables on the internet backbone, which is NOT under Google's control.

As far as we know, when Google announced it had never heard of PRISM before, when it first went public, they could have been telling the truth, as Google would theoretically have no way if telling if something like this was happening outside of their jurisdiction.

As an addition to my previous comment. Upon further investigation (by which I mean I discovered bash --version), I found that the version of Bash in the ports tree is indeed a GPL V3 version of Bash. I assume this means that whilst the FreeBSD project can not use any GPL V3 code in the operating system itself (I believe by FreeBSD 10 they want to have removed all GPL code full stop), there is no restriction on the licencing used by software in the ports tree (within reason).

Also, I quickly checked my Debian Wheezy box and that runs Bash 4.2.37, and Arch is using the same version as FreeBSD. I guess it shows that depending on the package, the ports tree can be rather bleeding edge at times.

The ports tree has Bash 4.2.45, i'm not sure how up-to-date this is compared to linux.

As for a list of shells, the Ports tree reports 49 different shells, although some of them are just tools: http://www.freebsd.org/ports/shells.html

As for your question, FreeBSD does has KSH and ZSH.

Whilst I'm not a very active WoW player, I can tell you that there is an increasingly large number of servers, or "Realms" as they're called, that are very empty (200 players online at peak time). This doesn't just have a negative effect on the social side of the game, it also causes a whole host of issues for the in-game economy, and the ability to party up for dungeons and raids.

I think from a player point a view, downscaling their number of actual game servers would be a welcome move (albeit tricky to carry out due to potential player name / guild name conflicts when multiple realms are merged).

Wikipedia has a rather well written article on FreeBSD's ports system (and being that FreeBSD has the largest user base of the *BSDs, it is often thought of as "the BSD system"). http://en.wikipedia.org/wiki/FreeBSD_Ports

Additionally, it may be worth noting that FreeBSD is transitioning over to a new binary package system called "pkgng", (to replace pkg_add, not ports). I don't personally know much about it, but the trusty old FreeBSD handbook has a section on it: http://www.freebsd.org/doc/en/books/handbook/pkgng-intro.html

It really depends on what the usernames are like, at my university the username is [initials][year started][three random letters], so for instance, john doe starting in 2012 would be jd12ges@uni.ac.uk, however, if your usernames are just a random sequence of letters or numbers this wouldn't be a very good solution.

Unfortunately, this move has ended the matchmaking capability of Microsoft Flight Simulator X, the last title of the series before Microsoft fired ACES Studio, this seems a great shame, as the game still had well over 100 people using the service at any given moment, and Microsoft is unlikely to foot the bill for a premium service considering their abandoned support of the title. Thankfully there is also a direct connect system whereby a user enters an IP address, but this just isn't as effective for the community at large. I'll be the first to admit that from the get-go there were many bugs with the system, with GameSpy and ACES passing the blame between each other, and eventually getting nowhere, but it allowed thousands of like-minded enthusiasts to meet and form lasting relationships, and feel it will be sorely missed.

This looks like a seriously interesting release. My only gripe with PC-BSD before now was the PBI system whereby you would end up with a large number of redundant packages and libraries as everything was duplicated. Now it's probably got to the point where I can start recommending this over Linux Mint (although I do still need to test it for hardware support).

The MSFS series has unfortunately never been procedure approved. However, I'm pretty sure that X-plane has a special version which is procedure approved (I don't know what the difference between this and the standard version is though). I don't think flightgear is, but i've not followed them in a while.