So manslaughter wasn't a crime? Because by definition, there can't have been a criminal intent (otherwise it would have been murder).
That's a variation on criminal negligence. There was no intent to kill, but there was intent to take insufficient care to ensure that nobody was killed. The "insufficient care" is (of course) rather tricky, but that sort of thing is why there is trial by jury for serious crimes and not just an administrative action by the prosecutor's office.
Some scientists call it maximum likelihood estimation, and others call it Bayesian statistics.
But you've got to calculate the likelihoods correctly in the first place, and that requires knowing the characteristics of the event in the first place. If there are features of the event that are strongly divergent with your "leading" theory, then the probability that that theory is the correct reason should be deemed highly unlikely.
Collect evidence, be prepared to revise your opinion if the facts don't support it. (The natural human approach is the opposite: "revise" the facts if they don't match the official explanation...)
How about those protocols which have remained unpublished?
You need to test "Just make it up so that results give the answer we want in order to get more funding"? Really?
Not that good scientists ever use that method. Alas, not all scientists are good, and that's why it is important to check published results. (It's a good task for grad students...)
Horesmeat burgers over here would perhaps be more expensive as it isn't as usual as it was 50 years ago and now something like a speciality.
Price depends on the balance of demand and supply; if not so many people want to purchase dobbinburgers then their natural price will tend to be lower.
There is then the wrinkle that to not do 'B' may be against your shareholders best interests.
I wouldn't really say there's much of a maybe about it... and as far as I know isn't it a legal requirement that you can't do anything against their best interests?
But there's usually a way to spin virtually anything that management want to do as being in the shareholders' best interest. The issue is that shareholders have a very large range of interests, many of which will be directly divergent from one another, and there's a need to have many different strategies over many spans of time.
In practice, the fiduciary responsibility regulations only really have real bite in limited circumstances where the actions of management may verge on the fraudulent (e.g., selling substantial parts of the company for much less than their fair value to another company owned by the CEO; whether or not that's technically fraud, it's still seen as clearly wrong). Most of the time, so long as management are trying to do the best for the company as they see it, they're not on the hook for fiduciary responsibility violation.
If you want to identify real problems, point your finger at investment firms that just want a fast return on their money and care nothing for the success of the businesses that they invest in. All they do is try to force everyone else to act like as big a corporate psychopath as they are. (This is why businesses run by their founding entrepreneurs often do better: they don't just focus on boosting their share price or returning dividends over the next 3 months, but instead actually build the business.)
Not entirely. It does seem that bats have a problem with windmills in some locations.
So that's what's happened to the lesser north sea bat! Or not.
Wind turbines at sea can get much larger than on the land, have far fewer problems with turbulence and shear forces, and are generally a lot more cost effective. Combining them with localized power storage seems like a sensible approach (the one thing you can say for sure is that wind power isn't constant).
If flying out of AMS to the USA, there is a high likelihood he was on either Delta or KLM, a Delta hub because of the old KLM-Northwest joint venture, and two of the AMS-US likely routes are into either MEM or ATL. With SEA also a possibility; I think KL still flies that.
KLM still fly quite a wide selection of routes to the US out of AMS — the last couple of times for me were to ORD and IAD — and it is the fourth largest hub in Europe IIRC so there's a lot of traffic through there. (It's also far less frustrating than LHR, CDG or FRA in my experience; AMS seems to run a pretty tight operation.)
It's called the internet archive, and not making a robots.txt file that denies it access.
They guarantee to index all other content? Every last little boring bit? And they guarantee to have the data continue to be available in 30 years? Really?
And it took them YEARS to work this out? And only really weeks to "fix"?
Just because it is obvious to you doesn't mean that it is obvious to others. Really.
If there's a problem, kick up a fuss, complain, let someone know who can do something about it. This is true whether it is software, hardware, real life services, etc. There's always plenty for the people doing support to do, so if you want YOUR issues to be the ones fixed then you'd better sing up about them so that they get some priority. If you say nothing, everyone else will assume you're doing fine with no problems at all. That's the way the world works.
Only C works on more platforms. And if there's a platform that does not have a C++ compiler, I doubt it is relevant today.
I think you have failed to understand. C does what it does, and doesn't try to be all things to all men; not only does it have goals, but it also has non-goals, and thus it occupies its niche clearly. I've yet to comprehend what the non-goals of C++ are (unless you're into snarkiness).
Practically though, C++ has had a history of ABI incompatibility (especially on platforms other than Windows) which has meant that rebuilding the world is a far more common occurrence there than with other languages. Given the tendency to slow compiles caused by the complexity of the template system, the need to be dragged through the swamp more often than is nice is highly frustrating. I hope newer C++ compilers have addressed these key technical issues.
Swing is one of the few things I've seen leave programmers speechless with frustration.
I see you've never used Motif. Direct use of Xlib is nicer and less frustrating than Motif. Heck, personally whistling the X protocol down a telephone line connected to a 300 baud modem would probably be better than Motif. Did I mention that I really disliked Motif, and think that no matter how much GTK and Qt are idiotic, they still do a better job?
Swing's main problem was that every single one of the layout managers was crap (and writing a good one is genuinely hard, though that's actually not a Java problem per se but rather due to the fact that the algorithms required to do a good job are genuinely tricky).
We use Skype all the time for groups at work... I can say it sucks unless you have one person talking and everyone else listening -- last time I checked listened to an xbox game it was nothing like that. I see this as a huge failure... unless you don't want to hear video games or their players.
Having used a number of different systems for teleconferencing (and videoconferencing) over the years for work, Skype is definitely one of the better ones in that they do a lot better at handling the volume matching problem than most, and they're pretty good at stamping out feedback loops. Only Webex was consistently better on those fronts of the things I've tried, and given how much that costs, that's what you'd expect. Skype is also probably the best at firewall navigation (a serious issue when you're not just staying in one place) and I've not tried the traditional-telephone integration stuff with it. As long as you've got enough bandwidth, the only real issues with Skype are actually to do with people switching their microphones off or other similarly dumb stuff.
In short, if you think Skype is bad, you've lived a very sheltered life (and I'm jealous!).
Only allow mahcines with known, registered MAC addresses, after pre-auditing and authorising them.
right. a 6 byte mac is such a strong protection measure.
Just because some people have lockpicks doesn't mean that you shouldn't put a lock on your front door. Same principle.
Which isn't to say that the devices should then allow anyone on the network to connect — sane security is always in depth — but neglecting a simple measure that keeps a lot of trouble off the network is foolish. Most people inclined to try are just looking to get free networking, and don't care which network they use. Wireless MAC filtering is how you deal with them, along with implementing other orthogonal security measures like WPA2.
Having lengthy-but-descriptive variable and function names has one nice advantage over comments - it forces all people who muck around with that code to use that name whenever they refer to variable/function, thereby retaining its descriptiveness at points of use.
You wait until you come across code where people use that long-named function all over the place for purposes other than its name characterizes. (Double points if it is never used for its original purpose any more at all!) At that point, the name has ceased to be a good thing, and become an active hinderance.
Write the name to be useful to the consumers of the code, not the maintainer of the code.
Yes, English beats random code, but comments can get outdated very easily.
If your comments are getting outdated easily, you're probably writing the wrong comments. Comments should be for information that is not obvious in the code (e.g., which bug report IDs are related, which journal has the paper that you cribbed the algorithm from) or that is not going to go out of validity easily (e.g.,/* check preconditions */ is reasonable, even if a little obvious, because it is still a higher-level concern that doesn't go out of date rapidly. You don't normally need to describe how you're doing the checking though, as the machine-readable part of the code says that and ought to be clear.)
Maybe a simple notallowed() function doesn't scale linearly across many PB of data.
In a simple situation, you have a table or simple ruleset describing everything that is allowed, and disallow everything else. In that case, isallowed() is cheap. Or you might have a table of all the things that aren't allowed, which is dumb as a box of rocks but still cheap. FB must instead have rulesets where the operation of the rule depends on knowing the graph of relationships, and maybe also the provenance of the data which you're talking about (was it shared by route A or by route B?). Evaluating that sort of system is much more expensive, especially when dealing with as large an amount of data and number of participating actors as they've got; it's just the nature of graph closure algorithms. You can do some tricks which will make things cheaper I suppose, like precomputing limited closures and things like that, but it is still non-trivial as you have to deal with permission removal.
I try to avoid such complexity in my systems; keeping security decisions simple is a good thing where possible.
K&R is perhaps the single ugliest coding style I have ever seen or used.
You wait till you encounter "traditional FORTRAN" style, which can be characterized as (approximately) "Indentation? What's that?" It is a number of years since I worked with someone who wrote that way by choice, but it is still a clear reminder that most people's indentation isn't that bad. Yes, if you were coding in FORTRAN77 then you might write stuff that way, but this was in C...
Personally? As long as the indentation step is at least 3 and is consistent through the codebase, I'm not too fussed. And 8 is usually excessive.
Java qualifies as a "bigger risk", and you mitigate it by uninstalling JRE.
You mitigate by disabling Java in the browser. You also want to do that for performance reasons; the Java plugin is resource hungry by comparison with most other plugins (let alone with running Javascript code). I've been keeping it switched off for ages, and the logic behind that wasn't security even though that was one of the nice outcomes. Uninstalling the JRE is a much more extensive change, in that it tends to result in the inability to run any Java program, including many that are totally unrelated to web security. The best response is always the proportionate one.
Of course, with this much hyperbole you're well suited to be a security commentator. Throwing babies out with bathwater a speciality! Next up, why you should disable HTTPS because of the compromise of one CA...
I have never, ever, in my life seen too much documentation. I have rarely seen anything that was even close to sufficiently documented.
Oh, it's pretty common. I've seen large libraries that had lots of documentation generated from doxygen, but which had nothing that actually informed you about how you were actually supposed to use the library. Vast state models that depended on knowing whole reams of stuff that was never ever explained (but boy, was it documented!) In essence, I could see very clearly that the original developers were on something illegal, but not what exactly it was they were smoking. I've also seen systems where the architecture documentation ran to thousands of pages, but the installation instructions were scribbled on the back of an envelope (and thus totally inadequate).
Documentation. It's useless unless you've got the RIGHT amount.
Slashdot Mirror
So manslaughter wasn't a crime? Because by definition, there can't have been a criminal intent (otherwise it would have been murder).
That's a variation on criminal negligence. There was no intent to kill, but there was intent to take insufficient care to ensure that nobody was killed. The "insufficient care" is (of course) rather tricky, but that sort of thing is why there is trial by jury for serious crimes and not just an administrative action by the prosecutor's office.
By Betteridge's Law, I am forced to agree with you.
Some scientists call it maximum likelihood estimation, and others call it Bayesian statistics.
But you've got to calculate the likelihoods correctly in the first place, and that requires knowing the characteristics of the event in the first place. If there are features of the event that are strongly divergent with your "leading" theory, then the probability that that theory is the correct reason should be deemed highly unlikely.
Collect evidence, be prepared to revise your opinion if the facts don't support it. (The natural human approach is the opposite: "revise" the facts if they don't match the official explanation...)
How about those protocols which have remained unpublished?
You need to test "Just make it up so that results give the answer we want in order to get more funding"? Really?
Not that good scientists ever use that method. Alas, not all scientists are good, and that's why it is important to check published results. (It's a good task for grad students...)
Horesmeat burgers over here would perhaps be more expensive as it isn't as usual as it was 50 years ago and now something like a speciality.
Price depends on the balance of demand and supply; if not so many people want to purchase dobbinburgers then their natural price will tend to be lower.
So, FB are finally getting around to putting the creepy in feature creep?
I wouldn't really say there's much of a maybe about it... and as far as I know isn't it a legal requirement that you can't do anything against their best interests?
But there's usually a way to spin virtually anything that management want to do as being in the shareholders' best interest. The issue is that shareholders have a very large range of interests, many of which will be directly divergent from one another, and there's a need to have many different strategies over many spans of time.
In practice, the fiduciary responsibility regulations only really have real bite in limited circumstances where the actions of management may verge on the fraudulent (e.g., selling substantial parts of the company for much less than their fair value to another company owned by the CEO; whether or not that's technically fraud, it's still seen as clearly wrong). Most of the time, so long as management are trying to do the best for the company as they see it, they're not on the hook for fiduciary responsibility violation.
If you want to identify real problems, point your finger at investment firms that just want a fast return on their money and care nothing for the success of the businesses that they invest in. All they do is try to force everyone else to act like as big a corporate psychopath as they are. (This is why businesses run by their founding entrepreneurs often do better: they don't just focus on boosting their share price or returning dividends over the next 3 months, but instead actually build the business.)
Big Wind
How dare you talk about our beloved political leaders like that?!
Not entirely. It does seem that bats have a problem with windmills in some locations.
So that's what's happened to the lesser north sea bat! Or not.
Wind turbines at sea can get much larger than on the land, have far fewer problems with turbulence and shear forces, and are generally a lot more cost effective. Combining them with localized power storage seems like a sensible approach (the one thing you can say for sure is that wind power isn't constant).
If flying out of AMS to the USA, there is a high likelihood he was on either Delta or KLM, a Delta hub because of the old KLM-Northwest joint venture, and two of the AMS-US likely routes are into either MEM or ATL. With SEA also a possibility; I think KL still flies that.
KLM still fly quite a wide selection of routes to the US out of AMS — the last couple of times for me were to ORD and IAD — and it is the fourth largest hub in Europe IIRC so there's a lot of traffic through there. (It's also far less frustrating than LHR, CDG or FRA in my experience; AMS seems to run a pretty tight operation.)
Most cargo arrives in US on passenger planes.
Most air freight does. The majority of cargo arrives by sea or over land (because nobody is dumb enough to ship bulk cargo by air).
It's called the internet archive, and not making a robots.txt file that denies it access.
They guarantee to index all other content? Every last little boring bit? And they guarantee to have the data continue to be available in 30 years? Really?
And it took them YEARS to work this out? And only really weeks to "fix"?
Just because it is obvious to you doesn't mean that it is obvious to others. Really.
If there's a problem, kick up a fuss, complain, let someone know who can do something about it. This is true whether it is software, hardware, real life services, etc. There's always plenty for the people doing support to do, so if you want YOUR issues to be the ones fixed then you'd better sing up about them so that they get some priority. If you say nothing, everyone else will assume you're doing fine with no problems at all. That's the way the world works.
Academic publishers have been price gouging universities and students for a long time
FTFY...
Only C works on more platforms. And if there's a platform that does not have a C++ compiler, I doubt it is relevant today.
I think you have failed to understand. C does what it does, and doesn't try to be all things to all men; not only does it have goals, but it also has non-goals, and thus it occupies its niche clearly. I've yet to comprehend what the non-goals of C++ are (unless you're into snarkiness).
Practically though, C++ has had a history of ABI incompatibility (especially on platforms other than Windows) which has meant that rebuilding the world is a far more common occurrence there than with other languages. Given the tendency to slow compiles caused by the complexity of the template system, the need to be dragged through the swamp more often than is nice is highly frustrating. I hope newer C++ compilers have addressed these key technical issues.
Swing is one of the few things I've seen leave programmers speechless with frustration.
I see you've never used Motif. Direct use of Xlib is nicer and less frustrating than Motif. Heck, personally whistling the X protocol down a telephone line connected to a 300 baud modem would probably be better than Motif. Did I mention that I really disliked Motif, and think that no matter how much GTK and Qt are idiotic, they still do a better job?
Swing's main problem was that every single one of the layout managers was crap (and writing a good one is genuinely hard, though that's actually not a Java problem per se but rather due to the fact that the algorithms required to do a good job are genuinely tricky).
We use Skype all the time for groups at work... I can say it sucks unless you have one person talking and everyone else listening -- last time I checked listened to an xbox game it was nothing like that. I see this as a huge failure... unless you don't want to hear video games or their players.
Having used a number of different systems for teleconferencing (and videoconferencing) over the years for work, Skype is definitely one of the better ones in that they do a lot better at handling the volume matching problem than most, and they're pretty good at stamping out feedback loops. Only Webex was consistently better on those fronts of the things I've tried, and given how much that costs, that's what you'd expect. Skype is also probably the best at firewall navigation (a serious issue when you're not just staying in one place) and I've not tried the traditional-telephone integration stuff with it. As long as you've got enough bandwidth, the only real issues with Skype are actually to do with people switching their microphones off or other similarly dumb stuff.
In short, if you think Skype is bad, you've lived a very sheltered life (and I'm jealous!).
Only allow mahcines with known, registered MAC addresses, after pre-auditing and authorising them.
right. a 6 byte mac is such a strong protection measure.
Just because some people have lockpicks doesn't mean that you shouldn't put a lock on your front door. Same principle.
Which isn't to say that the devices should then allow anyone on the network to connect — sane security is always in depth — but neglecting a simple measure that keeps a lot of trouble off the network is foolish. Most people inclined to try are just looking to get free networking, and don't care which network they use. Wireless MAC filtering is how you deal with them, along with implementing other orthogonal security measures like WPA2.
Having lengthy-but-descriptive variable and function names has one nice advantage over comments - it forces all people who muck around with that code to use that name whenever they refer to variable/function, thereby retaining its descriptiveness at points of use.
You wait until you come across code where people use that long-named function all over the place for purposes other than its name characterizes. (Double points if it is never used for its original purpose any more at all!) At that point, the name has ceased to be a good thing, and become an active hinderance.
Write the name to be useful to the consumers of the code, not the maintainer of the code.
Yes, English beats random code, but comments can get outdated very easily.
If your comments are getting outdated easily, you're probably writing the wrong comments. Comments should be for information that is not obvious in the code (e.g., which bug report IDs are related, which journal has the paper that you cribbed the algorithm from) or that is not going to go out of validity easily (e.g., /* check preconditions */ is reasonable, even if a little obvious, because it is still a higher-level concern that doesn't go out of date rapidly. You don't normally need to describe how you're doing the checking though, as the machine-readable part of the code says that and ought to be clear.)
Maybe a simple notallowed() function doesn't scale linearly across many PB of data.
In a simple situation, you have a table or simple ruleset describing everything that is allowed, and disallow everything else. In that case, isallowed() is cheap. Or you might have a table of all the things that aren't allowed, which is dumb as a box of rocks but still cheap. FB must instead have rulesets where the operation of the rule depends on knowing the graph of relationships, and maybe also the provenance of the data which you're talking about (was it shared by route A or by route B?). Evaluating that sort of system is much more expensive, especially when dealing with as large an amount of data and number of participating actors as they've got; it's just the nature of graph closure algorithms. You can do some tricks which will make things cheaper I suppose, like precomputing limited closures and things like that, but it is still non-trivial as you have to deal with permission removal.
I try to avoid such complexity in my systems; keeping security decisions simple is a good thing where possible.
K&R is perhaps the single ugliest coding style I have ever seen or used.
You wait till you encounter "traditional FORTRAN" style, which can be characterized as (approximately) "Indentation? What's that?" It is a number of years since I worked with someone who wrote that way by choice, but it is still a clear reminder that most people's indentation isn't that bad. Yes, if you were coding in FORTRAN77 then you might write stuff that way, but this was in C...
Personally? As long as the indentation step is at least 3 and is consistent through the codebase, I'm not too fussed. And 8 is usually excessive.
No one is going to see the real thing anyway (apart from your own staff).
You must be a CEO to consider each and every last customer to be a no one.
No, he would be a CEO if he considered the customers AND the employees to be a no one.
No, he would be a CEO if he considered the customers AND the employees AND the investors AND all relevant regulators to be a no one.
There's no point in assuming a limited level of psychopathy here...
Java qualifies as a "bigger risk", and you mitigate it by uninstalling JRE.
You mitigate by disabling Java in the browser. You also want to do that for performance reasons; the Java plugin is resource hungry by comparison with most other plugins (let alone with running Javascript code). I've been keeping it switched off for ages, and the logic behind that wasn't security even though that was one of the nice outcomes. Uninstalling the JRE is a much more extensive change, in that it tends to result in the inability to run any Java program, including many that are totally unrelated to web security. The best response is always the proportionate one.
Of course, with this much hyperbole you're well suited to be a security commentator. Throwing babies out with bathwater a speciality! Next up, why you should disable HTTPS because of the compromise of one CA...
I have never, ever, in my life seen too much documentation. I have rarely seen anything that was even close to sufficiently documented.
Oh, it's pretty common. I've seen large libraries that had lots of documentation generated from doxygen, but which had nothing that actually informed you about how you were actually supposed to use the library. Vast state models that depended on knowing whole reams of stuff that was never ever explained (but boy, was it documented!) In essence, I could see very clearly that the original developers were on something illegal, but not what exactly it was they were smoking. I've also seen systems where the architecture documentation ran to thousands of pages, but the installation instructions were scribbled on the back of an envelope (and thus totally inadequate).
Documentation. It's useless unless you've got the RIGHT amount.