Even if it does happen that they cut it off from time to time the pipeline may still be valuable to russia. If russia has multiple export routes to/via different countries then the impact of any one route being cut (for example exports to europe could potentially be cut off by sanctions over the ukraine situation) is reduced.

We may see a model similar to openssh where the core code in openbsd is kept free of "portability goop" and then a seperate group maintains a "portable" version based on the openbsd version.

Given the cost of using the court system it simply isn't worth suing for small ammounts of money. Small claims court helps to an extent but for most people it still won't be worth if the value of the damage is less than a few hundred dollars (and if you value your time and are well paid quite possiblly not even then).

Sometimes a company can do a small ammount of damage to a lot of people. If a company with a million customers screws each of them out of $10 then they have dishonestly gained $10 million. That is clearly a sum where it is worth going to the expense of using proper court procedures to consider the case but only if all the damage can be considered at once in one court case. Hence the reason for class actions.

Having said that while I like the principle of class action lawsuits I don't agree with the practice of paying victims damages by using vouchers which will encourage them to go back to the company that screwed them rather than something that can easilly be spent anywhere.

It's possible with at least some ethernet BASE-T Phys to operate without transformers. Most ethernet transformers are 1:1 ratio anyway.

http://www.google.com/search?q...

There is also the question of how do you know for sure that the socket is BASE-T ethernet (and not ethernet with a propietary physical layer or something else entirely) until you connect to that.

Having said that I suspect that the chances of finding a socket in a car carrying an interface so fragile that base-t ethernet could blow it up are pretty low.

Your friend sounds like he has some serious anger management issues.

goto used sparingly can be a useful tool for breaking out of multiple layers of structures and going to an error handling block when an error happens in an inner loop and avoids adding loads of boilerplate to every layer of the nesting just to deal with error conditions. This is especially true in a language like C which does not have exceptions.

However care is needed to avoid jumping over things you didn't mean to jump over (like cleanup code) and over-use of goto can result in seriously unreadable spaghetti code. This makes some programmers anti-goto.

Not really for the general case.

In a normal C compiler when a pointer is passed from one function to another, stored in a field of a structure, stored in a global variable etc no information about the start and end of the memory block it points to is stored/passed along with it.

In theory you could have a C compiler that used extended pointers which stored start and end information along with the pointer itself. In practice however such a C compiler would have several issues that would prevent it being widely used. Firstly it would be ABI incompatible with the standard C compiler, so you'd either have to build your whole OS and every app with this compiler or keep two paralell libraries sets. Secondly it would break assumptions that a lot of code makes about the size of pointers and their convertibility to/from intergers. Thirdly it would massively increase memory use.

There have been partial solutions for special cases which provide special versions of system functions that are commonly used in an unsafe manner then modify calls to those functions for the cases where the compiler does know the buffer size (e.g. because the buffer is a local variable) but they are far from a perfect fix.
.

And while it has a "select" function it's not much use in practice because it can ONLY select on sockets, so you end up with windows specific event and/or thread handling as well.

Unfortunately all attempts at making remote manipulation devices both mechanical and electronic have resulted in things that are far more cumbersome than using your hands directly. The human arm and hand is an amazingly good maniupulator with extremely good feedback so it can grasp something firmly without damaging it.

There is usually a way to clamp the workpeice and keep your fingers out of harms way but it's slower and more cumbersome than just holding it and people have a nasty habit of getting overconfident in the own ability to not slip up.

There are boards that are faster than the Pi and boards that are cheaper but I haven't seen anyone come out with a board that is both faster and cheaper.

Looks like it's still arround.

The networks are a risk but they are a risk that can be mitigated to at least some extent by strong well-managed encryption (and yes this does mean avoiding the easy to use centralised systems where the system operator manages the encryption and going for something more decentralised and that requires more work and understanding but lets you manage the encryption yourself).

But if the end devices are compromised then the keys can be stolen or the data can simply be copied before it is encyrpted.

btrfs brings really useful features like data integrity protection through the combination of checksums with either multiple copies or error correction codes*, snapshotting** and the ability to create a logical copy of a file without creating a physical copy. These are features that most other linux fileystems don't have. You can find out more at https://btrfs.wiki.kernel.org/...

Unfortunately it's hard to take a filesystem, particularly a complex one like btrfs from "seems to work fine under our lab tests" to "proven stable in production" . devs need data from real world problems to improve the filesystem but to get data from real world problems requires people to run it on real world systems but people are reluctant to put an experimental filesystem on their production servers.

This is good news towards the goal of turning btrfs into a "proven stable in production" soloution.

* The trouble with conventional raid is it keeps multiple effective copies but it has no idea which of those copies is correct. So it relies on the underlying drives to return either correct data or an error code. Experiance has shown that the checksum systems built into drives are not strong enough to completely prevent bad data from being returned.
** Yes you can do snapshotting with a layer like lvm between the filesystem and the storage but there are distinct advantages to doing it as part of the filesystem.

AIUI many shorting contracts require you to cover your short once your losses reach a certain level. You can still lose even if you turn out to be ultimately right.

While governments can sometimes go after individual users doing so on any significant scale carries a very high political cost. It's much easier to paint a handful of people who form a competing central authority as "criminals" and shut them down than it is to go after everyone participating in making a decentralised system work.

Which is not to say it's impossible for governments to crush bitcoin just much harder for them to do it than to crush comparable centralised schemes.

What is novel about bitcoin is it does what it does without requiring a central authoritiy. People who have tried to make "alternative money" systems with a central authority have found themselves either crushed or subsumed into the regulated system where the government can tell you who you may or may not give money to or order transactions reversed long after the fact.

bitcoin is to e-gold as gnutella is to napster.