That's actually not a big problem. It just means you push the panels far enough away from the earth that they can interface with a series of geo-synchronous satellites that are used to transmit the power from the collector to the ground station such that all of them take turns in transmitting the signal to the ground relay satellite (collector -> geo-sync array -> relay -> ground station). Now, power is loss with each transmission, but space being space it's probably still quite efficient.

Problem then becomes weight. They're not light (no pun intended); and either you have to tether it or you're back to microwave/laser transmission with less control over placement due to winds than there is in space.

(c) both.

More like, it's the only framework said developers understands or cares to learn, so it's what they use; or it is an easy framework to get past their manager that doesn't want to invest more in training for proper tools like Qt (PyQt, Qt), Gtk, etc that are actually 100% open source and freely available.

Search area is a big issue; but the fact that they've ignored a sizeable chunk of it is another part of the issue. As noted, someone with access to the data (who publically wrote up the issue a few weeks ago) gave credence to the fact that it was more likely to have taken the northernly route - which has been completely ignored - and whether it made it to a destination controlled by a terrorist group or otherwise or crashed in the mountains along the way is another things that has yet to be ruled out.

It's actually bigger than that.

And no, I'm not discounting the size of the search area. The issue with looking in the ocean is the fact that no debris of any kind has turned up any where. The likelihood of a crash happening in the ocean with zero debris (no debris, no oil slicks, etc - nothing) is smaller than that of the plane being hijacked for neferious purposes by an organization like Al Qaida.

As to why...well, a country like Russia might just want to remind certain powers that be of their influence; or for an organization like Al Qaida - it's easier to hijack a plane in that part of the world this way than it is to do it in someplace like the US or Europe. All they have to do then is figure out how to turn it into a bomb and get a flight plan scheduled that takes them close enough to the targets they want in a legit way that they can then carry out a mission.

Just saying, there's numerous methods to the madness. An outright crash is making less and less sense by the day.

They also have access to weapons on the plane, provided to them for the sole purpose of protection. Whether an axe or a pistol locked in a safe, either is sufficiently useful.

Then again, as a friend said - your car keys are enough; as is a pen or pencil. So there's plenty of tools that they could use that they are legally able to get through the security check points too.

Well since we're throwing out conspiracy theories... The very lack of them finding the plane (MH370) at all means that it more than not it did not crash, but was hijacked in some form and taken elsewhere. One credible person that had access to much of the data surmized that they likely took the route north, not south where everyone insists on looking, and were able to land near or in Russian territory at a site that after years of neglect happened to have a lot of activity and rebuilding of a hangar-like building that was big enough to hold the Beoing 777.

Well, I'm not sure if they made it that far. But I said from day one that it the lack of finding the plane or any evidence that it crashed thus far lends more and more to the the flight being hijacked, and we'll likely see it next when whomever decides to crash it into a building somewhere.

Now whether the pilots were in on it, or a passenger was able to access the controls via computer connections and then override the pilots is something entirely different. In either case, if it was hijacked then it's likely backed either by a nation state (e.g Russia) or a sufficiently large well funded terrorist organization (e.g Al Qaida). Which one we'll likely never know.

All true.

GitHub negates the decentralization of git in order to make it practical for real world use.

GitHub being down may not be a problem for your rinky-dink one-man JavaScript library project that nobody uses.

But for real projects with distributed teams consisting of numerous people the decentralization of git is a big problem.

GitHub is the only practical solution to the problems of decentralization.

This can actually be mitigated by several different means:

• 1. Using multiple Git services - e.g Git Hub AND Gitorious or Public GitHub and Git Hub for Enterprises if you use private repositories
• 2. Using your own servers as well - e.g. Qt has gitorious but also their own servers

It's just a matter of deciding where the "master" copy resides and keeping them all (hopefully automatically) in sync.

Now, this can be managed with tools like Subversion too, using replication, but it's no where near as nicely done as it is in git.

However, if you don't take the time to do the replication between several services then yes, you are risking this kind of situation.
Or, you could take advantage of this kind of replication by using the DVCS nature of git to your advantage.

It's usually policy based, though things like fail2ban make it easy to do for most logon methods. Even then, you cannot necessarily just use the IP address for blocking.

For instance, on your Windows system if a user locks their account, another user can come along an login (f.e support admin) and will still need to be able to validate against the domain. Once you enter into a centalized logon control that kind of things becomes a requirements. Otherwise you risk locking all your computers without any way to support them or risk severely increasing your organizations' internal help desk support load; this is often mitigated by using time period lock outs on the accounts.

So sadly there is no single, perfect solution to the issue. It's just a matter of which trade-offs are acceptable.

Not saying that is not a problem; and I don't know the comparison in EU but it's probably not much different than in the US in that SMBs (Small-Medium Businesses) make up the vast majority of businesses in the US, while no one single business has a lot of clout, there are organizations that tend to represent a majority of them and are big enough to be able to combat the larger (Large Businesses and Enterprise) organizations. In some cases, the SMBs get represented several times - between the various SMB organizations, Chambers of Commerce at different levels, etc. This is why many things - like the Family Medical Leave Act (FMLA), Americans with Disabilities Act (ADA) - are progressive in nature in the US; if fully enforced on SMBs they would put those companies out of business entirely so they are progressive in that as the business grows in size (revenue or number of employees depending upon the law or regulation) then more things kick in. For FMLA and ADA the first things kick in at around 50 employees, more at 100, more at 500, etc.

I use FMLA and ADA b/c I'm familiar with how they kick in; however, I know there are many others that are structured similarly but use different measures. For instance, Business Licenses usually have a revenue portion associated with them so you pay X + Y*M where X is the base, Y is your pre-tax revenue, and M is the progressive multiplier based on how big Y is.

Again, I don't know how well the comparison holds up for the EU, but I imagine it's not much different.

That depends on your program, and how much memory was allocated and when it would get detected. The OS is not going to detect anything until you try to leave the bounds of the program itself. Take the following function for instance:

You can extend buffer into buffer2 without any detections going off, or even any ill-effects until you surpass buffer2 and all the other variables in the function.

Heap allocated functions are a little more tricky but even then you can produce the same kind of behavior if you really wanted to - even with the HEAP randomization, which really doesn't protect the program internally, it only protects the program from the libraries the program uses by randomizing where they are loaded.

And since you control the program, you can control the optimizations so that the only that would mess you up - by re-arranging variables - are not run.

As I pointed out elsewhere, the point is not that it's the right way to do it. It's that it is possible to do in C, just as possible as in Assembly.

It was meant a counter to the GP saying that it was impossible to "extend" a string in C .

Not saying it's the correct way to do it, just that there are possibilities that the GP did not even consider, probably b/c they were taught to program using a language that protects them too much.

They do the brute force thing in A before they have access and time it such that they don't hit the lock outs.

For instance, most Windows systems will lock an account for 30 minutes when you hit the lockout. After 30 minutes, you're free to try again. Other systems behave similarly; most never do a true lockout.

So what do they do for A? Loop over a list, try the entry until locked out or gain access. If locked out, put it back in the queue and try again later. Move to the next entry.

If you want to observe this, just run an SSH server and monitor your logs. After the server gets noticed you'll see this happening quite a bit. Using tools like "fail2ban" help significantly, but that just means they have to hit from multiple IPs to do the same thing, which bigger cracker organizations will certainly be doing to start with any how.

That depends on the regulation, the cause, etc. Yes there may not be as much potential for contamination, but there is still a possibility. The regulations therefore should be progressive in nature much like many other things - if you exceed X then Y applies.

Actually that is a very bad example. A small dairy farm is actually more like to have certain issues than a large one. For instance, if the cattle are range fed then the propability of "bad feed" (e.g a cow eating a plant that when passed through in the milk can be dangerous to humans) goes up significantly with a smaller number of cattle to mix it together with, especially since the possibily that more cattle ate the "bad feed" goes up too. This is taken care of through homogonization; but pasteruization also has a good and equal roll even for small dairy farms.

True, pasterization does play a bigger role in larger dairy farms where milk is more likely to sit for longer periods of time, thus breeding more bacteria, etc. That doesn't make it irrelevant for smaller dairy farms though.

But to your point, yes regulations need to be in context and implemented progressively against the size of the organization they are regulation.

Not necessarily. It's not necessarily that "none of them chose B-E graded white goods". It's that there was not enough chosing the "B-E graded white goods" that the distributors decided it was not worth it, and thereby cut off the supply of B-E graded white goods. May be the A graded white goods high a higher margin or something else that caused the distributor to prefer the A grade over the B-E grades.

In other words, it could be a false consumer choice - one that was not really given to the consumer.

I run into this a lot. There's a number of products that I use to buy but can no longer get because the distributors decided it was in their interest to carry it. The local stores then go "well the distributor doesn't have it so I can't get it for you", and so forth. It hurts products and buyers alike. It hurts the market because it artificially destroys demand that would otherwise be there.

And, to top it off, economists don't take it into account. They just assume that if there are buyers they will buy it. They don't take into account distributors artifically changing the options available to buyers.