Good security code should be as simple and straightforward as possible, to make it easy to verify. The authors of OpenSSL took a... different approach.
<sarcasm> It must be correct, it has no obvious bugs (instead of having obviously no bugs, which is only for lamers and ivory tower types). </sarcasm>
Languages evolve. We've got a more culturally diverse ecosystem over here and, as a result, our English evolved differently than England's English.
Actually, it's less diverse given the relative populations and land sizes. This is (probably) due to the considerably greater amount of internal migration seen in the US during the late 19th and early 20th centuries. (At the start of the 18th century, England itself had enormously more linguistic diversity than the English speaking parts of North America; not all parts were prone to emigration.)
Of course, telecoms are pushing things to become more uniform everywhere (especially TV) but they're really only of significance from the mid 20th century onwards. I have no idea what effect the different nature of the Internet will create; yes, you can get information from anywhere but you're also more likely to only read it from elsewhere rather than listening to it. Hmm. Guess that's something for a linguist to study...
I've had some very nice ales in the south, London especially has a lot of pubs round the city that have some very good ales.
I'm happy to grant that there's good beers brewed in London, but would point out that there's good beer brewed all round the country. Alas, there's a lot of rubbish about too; I'm not sure if the worst beer I ever had was in London or Manchester, but it managed to be worse than the average standard you get in the US (whoever it was that was to blame, they'd made something worse than a warm Bud...) My favourites are usually the ones you get in a small country pub that you've never heard of before; sometimes they're better than other times, but the variation in the microbrewery output remains interesting.
London is extremely London-centric. (Seriously, they only really have proper regard for Paris, NYC and LA of everywhere else in the world.) They mistake this for thinking that they actually matter.
If Stallman were really that interested in freedom he'd go with the BSD license, since that actually offers, you know, the most freedom. GPLv3 is all about Stallman's ego and his personal, anti-corporate agenda, not about free software.
The GPL (in its various versions) and the BSD license emphasize different parts of freedom. GPL is particularly about the freedom of those upstream, and the BSD license is particularly about the freedom of those downstream. Unfortunately, it's not possible to maximize both of those at the same time as they're somewhat antagonistic; some things that a downstream participant (a consumer of the licensed code) might want to do will reduce the power of the upstream participant (a producer of the licensed code). A case in point is where the code in question is used as a component (despite not being originally intended as such) and resold as part of a larger product; the freedom for the downstream actor to do that is much more extensively curtailed by the GPL than by the BSD license.
This is really a philosophical difference — you can't reconcile them, and it's really about a statement of values — and it is often counterweighted by a community that uses "soft power" to encourage the other sorts of freedom; patches still flow upstream in BSD-based communities, people still build products in GPL-based communities.
This ruling would only provide precedent in the jurisdiction that it was made in, and in the jurisdiction of the appellate court that affirmed it. That being New York, Connecticut, and Vermont. Since the Supreme Court declined to hear the case, no national precedent was set.
Though judges in other jurisdictions with sufficiently equivalent legal systems (i.e., the US excluding the 2nd Circuit) may read the arguments and decisions that were made and find them persuasive when they feel that cases are sufficiently similar. This is the purpose of legal scholarship, and it is generally a good thing; it means that resorting to the Supreme Court is only necessary when there are contradictory decisions in lower courts. Precedent is not the only mechanism in a common law legal system.
Android chose Java because Java was popular, not the other way around. You must be unaware of the other uses of Java in this world.
Exactly. Java's got a huge number of server-side programs written for it, and it mostly gets on and supports those pretty well. Its somewhat chunky startup costs aren't a big problem in that situation (you don't need to start processes very often and you can usefully throw hardware at it) and its both fast and safe; fast because this is the case that JITting does best with, and safe because there's no loading of strange native code or user-supplied classes. The only real competitor in this space is.Net (yes, I know its not a language but a group of them targeting a single runtime, but then again what I say about Java really applies to a suite of languages too) and that only really has traction on Windows; Mono isn't very trusted yet, and most of the organizations with these sorts of code bases are very conservative (the only reason that Java and C# have had real traction into this space is because a lot of effort was made by Sun and Microsoft to enable relatively low-skilled programmers to work on connecting nasty legacy databases with relatively modern front-ends; that finally displaced a lot of companies away from COBOL and MUMPS).
The amazing thing is that people still write new desktop apps in Java...
True, but that's because it's not actually a truly independent organization. It could however have its budget (the source of its income) cut enormously and be so forced into doing many things that would look distinctly like what companies do when in close-to-bankrupt scenarios.
Overall, governments can go bankrupt (though as noted individual agencies can't, in a formal sense) though the nature of that bankruptcy would vary. In the US, you're not allowed to just outright default on the debts (though I wouldn't really want to rely on getting my money back in a timely fashion if things were getting really bad) so you'd probably have to print your way out, which would stoke hyperinflation. The net result would be similar to a debt default though: nobody sane would lend to the US. You're not in that situation.
the monopolistic coercive government of which it is a part can certainly destroy the merchant at any time. See Lehman Bros and the old AT&T for just a few of many examples
OTOH, it's harder to influence a powerful merchant than a democratically-elected government; it can take a huge amount of coercion to make a company change its behavior.
Most normal people won't though, being quite happy with NATed connectivity.
That NAT layer at your ISP is the perfect place for the Government to spy on all your traffic. If it's all hidden behind NAT, you won't even be able to notice when They turn up the levels of censorship on you...
No, you simply described all fiat currency. Not all currency. Even paper money is based on wealth and not debt if it's representative currency backed by gold or silver.
But I can't really do all that much with gold except make jewelry with it. Oh, and contacts on silicon chips. Guess we need some of it, but not that much. Silver's more useful, as it has anti-bacterial properties. Why again would we value those metals as much as you seem to think we should? They're just as much a kind of fiat currency, unless you can come up with a way to tightly bind those to the amount of work a person can do (and the value of that work). Nobody's ever succeeded at that, and if they could, it would work just as well with paper or even pure digital currency.
BTW, I was originally going to say "a way to fix the cost of goods" in the previous paragraph, i.e., to get zero inflation, but then I thought about the fact that the prices of things naturally change as they become easier or harder to produce. Eternally fixing prices just petrifies current imbalances, and in any case it is human effort that people really care about.
It's still a long way from being able to cut out the for-profit journals, though some open-access journals do exist.
It costs some money to produce a journal and to keep it available to people long into the future. Given that, the options are to either have it paid for directly through taxes or to have it run by an organization that seeks to make a working profit. ("Non-profit" organizations do different things with that working profit than normal companies, but both are keen on not making a loss.) Instead, the real questions are 1) whether the costs should be borne by those seeking to get their research published or by those reading that research, and 2) what the right level of charges is. There's been a strong case made for changes to the standard answer to the first question, but that doesn't really address the second one which is what a lot of people are actually cross about. The key problem is that the market is naturally not very free; the extreme pressure to publish somewhere "good" creates the ability to have a monopoly pricing regime. Technology doesn't change that.
Java should only be used by good programmers. Good programmers don't want to program in Java.
The countervailing argument is that there are some very good libraries and frameworks written in Java, things that it would take a lot of work to replicate, and that encourages good programmers to continue to work with Java. In a perfect world they'd use something else, but a grand rewrite-from-scratch is very hard to justify.
There are limits to video too. These so-called "retina" displays are a good example of the resolution limit of the human eye (we passed the color depth perception limit a good decade ago).
For display equipment that is generally available to the public, we've not passed the color depth perception limit yet. We have our best sensitivity to fine color differences in green and worst in blue (red's in between); blue doesn't need much more than 8 bits, but green needs around 12 bits. That said, this really is about fine detail and you only notice the issues in very rare circumstances (e.g., a very fine gradient); actually worrying about this (when not a professional scientist studying color perception) marks you out as the video equivalent of an audiophile who only uses Denon cables for their digital interconnect. Also, you have more issues anyway from the fact that the channels in color displays don't stimulate each channel of photoreceptors in our eyes perfectly, and the fact that we can't ever get displays to manage the brightness range found in the real world; the formal issues from lack of bit-depth in the color channels are the least of anyone's problems really.
I believe ammunition has been banned by airlines for a long time as being too damn dangerous. Even a small likelihood of it going off and making holes in the thin wall of the aircraft hold is judged to be too much.
So buy some once you arrive or have your supplies shipped separately.
I've seen so many clucterf***s in software development that I called BS, but here's their definition of Software Engineer -
Researches, designs, develops and maintains software systems along with hardware development for medical, scientific, and industrial purposes.
Guess that's different. It's quite narrow. Maybe the rating is actually accurate for that niche. But the rest of the industry? Not a chance.
That's what a real SE does. The rest? Well, they're either called Programmers or Code Monkeys, and they tend to be people who don't care about what it really takes to produce programs for the long term and that solve real people's problems. The SE might have some CM underlings, or might not: depends on the organization where he/she is working and the nature of the project. (Remember, "industrial purposes" can have quite a wide interpretation.)
They may be used for their original purpose, but they're not used exclusively for that purpose.
That depends entirely on the whim of the registrar, and each registrar is a law unto themselves. Some take money for old rope, others hold the line against the ravening hordes.
According to TFA the only disadvantage of splitting is that there has to be a computing centre built on each site, slightly increasing the costs. But I'm sure that the losing one of the two countries would happily foot the bill for that if it meant that they could still get one half.
It might actually reduce costs. The projected computing needs for the full SKA were crazy-high, right at the boundaries of what was conceivable as possible even allowing for Moore's Law. If splitting it up means you don't need a computer center that's quite so cutting edge, that will save a huge amount. (The really cutting edge kit is much more expensive than the stuff that's a little more commodity.) It helps that the computer centres would be built in areas with really low land prices...
The downside is that this increases overall costs. Two sites need to be prepared; two sets of computing facilities need to be built; two different national governments have to be placated.
The costs are definitely an issue (though not having everything running at once means that the ferocious data rate would be reduced, which will cut costs a lot even if you need to build two supercomputers). The governmental placation shouldn't be a big issue; they're currently competing strongly for it after all.
Scientifically, it means that the entire array can't always be 'pointed' in the same place across its entire frequency spectrum--sometimes the high- or low-frequency portion of the array will be below the horizon.
For almost all astronomical objects, it matters not one bit at all whether the observations are simultaneous or separated by a few hours. Even supernovae last for weeks. It would only matter if there was the opportunity of having full 24-hour observation of objects, but that's not going to happen with any telescope as far away from the poles as either Australia or South Africa. Since continuous observation is impossible, having the breaks in observation time at different times of the day won't matter too much.
Seems like you are talking about switching from a "strong memory model" to a "weak memory model" and TBQH I know my share of developers that can barely handle multithreaded programming as it is... throwing this at them could be a disaster on the software side.
Depends on the model. If the model is "oh, you got one big space of memory; anything goes but you'd better sprinkle a few locks in" then yes, that will suck boulders when the hardware switches to message passing, but there are other parallelism models in use in programming. Those that have each thread as being essentially isolated and only communicating with the other threads by sending messages will adapt much more easily; that's basically MPI, and that's known to scale massively. It's also a heck of a lot easier to reason about message passing parallelism; that's been known since at least the '80s. What's more, there are actually quite a lot of programmers who have experience with distributed component programming; they just tend to work at a much higher level than a single process (or single computer).
Good security code should be as simple and straightforward as possible, to make it easy to verify. The authors of OpenSSL took a... different approach.
<sarcasm> It must be correct, it has no obvious bugs (instead of having obviously no bugs, which is only for lamers and ivory tower types). </sarcasm>
Languages evolve. We've got a more culturally diverse ecosystem over here and, as a result, our English evolved differently than England's English.
Actually, it's less diverse given the relative populations and land sizes. This is (probably) due to the considerably greater amount of internal migration seen in the US during the late 19th and early 20th centuries. (At the start of the 18th century, England itself had enormously more linguistic diversity than the English speaking parts of North America; not all parts were prone to emigration.)
Of course, telecoms are pushing things to become more uniform everywhere (especially TV) but they're really only of significance from the mid 20th century onwards. I have no idea what effect the different nature of the Internet will create; yes, you can get information from anywhere but you're also more likely to only read it from elsewhere rather than listening to it. Hmm. Guess that's something for a linguist to study...
Me, I think it's filthy and crowded.
The best thing they could do with London would be to relocate the whole of national government elsewhere, every last lock, stock and barrel.
I've had some very nice ales in the south, London especially has a lot of pubs round the city that have some very good ales.
I'm happy to grant that there's good beers brewed in London, but would point out that there's good beer brewed all round the country. Alas, there's a lot of rubbish about too; I'm not sure if the worst beer I ever had was in London or Manchester, but it managed to be worse than the average standard you get in the US (whoever it was that was to blame, they'd made something worse than a warm Bud...) My favourites are usually the ones you get in a small country pub that you've never heard of before; sometimes they're better than other times, but the variation in the microbrewery output remains interesting.
The UK is London-centric.
London is extremely London-centric. (Seriously, they only really have proper regard for Paris, NYC and LA of everywhere else in the world.) They mistake this for thinking that they actually matter.
Err, corporate sector is private sector. He doesn't move out of private sector at any point.
Strictly, the corporate sector is a sub-sector of the private sector.
If Stallman were really that interested in freedom he'd go with the BSD license, since that actually offers, you know, the most freedom. GPLv3 is all about Stallman's ego and his personal, anti-corporate agenda, not about free software.
The GPL (in its various versions) and the BSD license emphasize different parts of freedom. GPL is particularly about the freedom of those upstream, and the BSD license is particularly about the freedom of those downstream. Unfortunately, it's not possible to maximize both of those at the same time as they're somewhat antagonistic; some things that a downstream participant (a consumer of the licensed code) might want to do will reduce the power of the upstream participant (a producer of the licensed code). A case in point is where the code in question is used as a component (despite not being originally intended as such) and resold as part of a larger product; the freedom for the downstream actor to do that is much more extensively curtailed by the GPL than by the BSD license.
This is really a philosophical difference — you can't reconcile them, and it's really about a statement of values — and it is often counterweighted by a community that uses "soft power" to encourage the other sorts of freedom; patches still flow upstream in BSD-based communities, people still build products in GPL-based communities.
Why do you need a PC to "manage" an iPhone?
For much the same reason you need an MBA to "manage" a software development team.
This ruling would only provide precedent in the jurisdiction that it was made in, and in the jurisdiction of the appellate court that affirmed it. That being New York, Connecticut, and Vermont. Since the Supreme Court declined to hear the case, no national precedent was set.
Though judges in other jurisdictions with sufficiently equivalent legal systems (i.e., the US excluding the 2nd Circuit) may read the arguments and decisions that were made and find them persuasive when they feel that cases are sufficiently similar. This is the purpose of legal scholarship, and it is generally a good thing; it means that resorting to the Supreme Court is only necessary when there are contradictory decisions in lower courts. Precedent is not the only mechanism in a common law legal system.
OK, since when is a crappy TV show some sort of barometer of government?
Have you ever watched C-SPAN?
Android chose Java because Java was popular, not the other way around. You must be unaware of the other uses of Java in this world.
Exactly. Java's got a huge number of server-side programs written for it, and it mostly gets on and supports those pretty well. Its somewhat chunky startup costs aren't a big problem in that situation (you don't need to start processes very often and you can usefully throw hardware at it) and its both fast and safe; fast because this is the case that JITting does best with, and safe because there's no loading of strange native code or user-supplied classes. The only real competitor in this space is .Net (yes, I know its not a language but a group of them targeting a single runtime, but then again what I say about Java really applies to a suite of languages too) and that only really has traction on Windows; Mono isn't very trusted yet, and most of the organizations with these sorts of code bases are very conservative (the only reason that Java and C# have had real traction into this space is because a lot of effort was made by Sun and Microsoft to enable relatively low-skilled programmers to work on connecting nasty legacy databases with relatively modern front-ends; that finally displaced a lot of companies away from COBOL and MUMPS).
The amazing thing is that people still write new desktop apps in Java...
The FBI can never go bankrupt
True, but that's because it's not actually a truly independent organization. It could however have its budget (the source of its income) cut enormously and be so forced into doing many things that would look distinctly like what companies do when in close-to-bankrupt scenarios.
Overall, governments can go bankrupt (though as noted individual agencies can't, in a formal sense) though the nature of that bankruptcy would vary. In the US, you're not allowed to just outright default on the debts (though I wouldn't really want to rely on getting my money back in a timely fashion if things were getting really bad) so you'd probably have to print your way out, which would stoke hyperinflation. The net result would be similar to a debt default though: nobody sane would lend to the US. You're not in that situation.
the monopolistic coercive government of which it is a part can certainly destroy the merchant at any time. See Lehman Bros and the old AT&T for just a few of many examples
OTOH, it's harder to influence a powerful merchant than a democratically-elected government; it can take a huge amount of coercion to make a company change its behavior.
You're missing the point that Roosevelt was ALSO a Socialist.
So what? So was Joe McCarthy. (Seriously, he campaigned to gain public office as a Democrat in 1936.)
Most normal people won't though, being quite happy with NATed connectivity.
That NAT layer at your ISP is the perfect place for the Government to spy on all your traffic. If it's all hidden behind NAT, you won't even be able to notice when They turn up the levels of censorship on you...
No, you simply described all fiat currency. Not all currency. Even paper money is based on wealth and not debt if it's representative currency backed by gold or silver.
But I can't really do all that much with gold except make jewelry with it. Oh, and contacts on silicon chips. Guess we need some of it, but not that much. Silver's more useful, as it has anti-bacterial properties. Why again would we value those metals as much as you seem to think we should? They're just as much a kind of fiat currency, unless you can come up with a way to tightly bind those to the amount of work a person can do (and the value of that work). Nobody's ever succeeded at that, and if they could, it would work just as well with paper or even pure digital currency.
BTW, I was originally going to say "a way to fix the cost of goods" in the previous paragraph, i.e., to get zero inflation, but then I thought about the fact that the prices of things naturally change as they become easier or harder to produce. Eternally fixing prices just petrifies current imbalances, and in any case it is human effort that people really care about.
It's still a long way from being able to cut out the for-profit journals, though some open-access journals do exist.
It costs some money to produce a journal and to keep it available to people long into the future. Given that, the options are to either have it paid for directly through taxes or to have it run by an organization that seeks to make a working profit. ("Non-profit" organizations do different things with that working profit than normal companies, but both are keen on not making a loss.) Instead, the real questions are 1) whether the costs should be borne by those seeking to get their research published or by those reading that research, and 2) what the right level of charges is. There's been a strong case made for changes to the standard answer to the first question, but that doesn't really address the second one which is what a lot of people are actually cross about. The key problem is that the market is naturally not very free; the extreme pressure to publish somewhere "good" creates the ability to have a monopoly pricing regime. Technology doesn't change that.
Java should only be used by good programmers.
Good programmers don't want to program in Java.
The countervailing argument is that there are some very good libraries and frameworks written in Java, things that it would take a lot of work to replicate, and that encourages good programmers to continue to work with Java. In a perfect world they'd use something else, but a grand rewrite-from-scratch is very hard to justify.
There are limits to video too. These so-called "retina" displays are a good example of the resolution limit of the human eye (we passed the color depth perception limit a good decade ago).
For display equipment that is generally available to the public, we've not passed the color depth perception limit yet. We have our best sensitivity to fine color differences in green and worst in blue (red's in between); blue doesn't need much more than 8 bits, but green needs around 12 bits. That said, this really is about fine detail and you only notice the issues in very rare circumstances (e.g., a very fine gradient); actually worrying about this (when not a professional scientist studying color perception) marks you out as the video equivalent of an audiophile who only uses Denon cables for their digital interconnect. Also, you have more issues anyway from the fact that the channels in color displays don't stimulate each channel of photoreceptors in our eyes perfectly, and the fact that we can't ever get displays to manage the brightness range found in the real world; the formal issues from lack of bit-depth in the color channels are the least of anyone's problems really.
I'm not sure about ammo, though.
I believe ammunition has been banned by airlines for a long time as being too damn dangerous. Even a small likelihood of it going off and making holes in the thin wall of the aircraft hold is judged to be too much.
So buy some once you arrive or have your supplies shipped separately.
I've seen so many clucterf***s in software development that I called BS, but here's their definition of Software Engineer -
Researches, designs, develops and maintains software systems along with hardware development for medical, scientific, and industrial purposes.
Guess that's different. It's quite narrow. Maybe the rating is actually accurate for that niche. But the rest of the industry? Not a chance.
That's what a real SE does. The rest? Well, they're either called Programmers or Code Monkeys, and they tend to be people who don't care about what it really takes to produce programs for the long term and that solve real people's problems. The SE might have some CM underlings, or might not: depends on the organization where he/she is working and the nature of the project. (Remember, "industrial purposes" can have quite a wide interpretation.)
They may be used for their original purpose, but they're not used exclusively for that purpose.
That depends entirely on the whim of the registrar, and each registrar is a law unto themselves. Some take money for old rope, others hold the line against the ravening hordes.
According to TFA the only disadvantage of splitting is that there has to be a computing centre built on each site, slightly increasing the costs. But I'm sure that the losing one of the two countries would happily foot the bill for that if it meant that they could still get one half.
It might actually reduce costs. The projected computing needs for the full SKA were crazy-high, right at the boundaries of what was conceivable as possible even allowing for Moore's Law. If splitting it up means you don't need a computer center that's quite so cutting edge, that will save a huge amount. (The really cutting edge kit is much more expensive than the stuff that's a little more commodity.) It helps that the computer centres would be built in areas with really low land prices...
The downside is that this increases overall costs. Two sites need to be prepared; two sets of computing facilities need to be built; two different national governments have to be placated.
The costs are definitely an issue (though not having everything running at once means that the ferocious data rate would be reduced, which will cut costs a lot even if you need to build two supercomputers). The governmental placation shouldn't be a big issue; they're currently competing strongly for it after all.
Scientifically, it means that the entire array can't always be 'pointed' in the same place across its entire frequency spectrum--sometimes the high- or low-frequency portion of the array will be below the horizon.
For almost all astronomical objects, it matters not one bit at all whether the observations are simultaneous or separated by a few hours. Even supernovae last for weeks. It would only matter if there was the opportunity of having full 24-hour observation of objects, but that's not going to happen with any telescope as far away from the poles as either Australia or South Africa. Since continuous observation is impossible, having the breaks in observation time at different times of the day won't matter too much.
Seems like you are talking about switching from a "strong memory model" to a "weak memory model" and TBQH I know my share of developers that can barely handle multithreaded programming as it is... throwing this at them could be a disaster on the software side.
Depends on the model. If the model is "oh, you got one big space of memory; anything goes but you'd better sprinkle a few locks in" then yes, that will suck boulders when the hardware switches to message passing, but there are other parallelism models in use in programming. Those that have each thread as being essentially isolated and only communicating with the other threads by sending messages will adapt much more easily; that's basically MPI, and that's known to scale massively. It's also a heck of a lot easier to reason about message passing parallelism; that's been known since at least the '80s. What's more, there are actually quite a lot of programmers who have experience with distributed component programming; they just tend to work at a much higher level than a single process (or single computer).
That's right--16 cores/chip X 100 chips for a total of 160 cores.
16 * 100 = 160?
You must be a hardware engineer. Did you work for Intel on the early Pentium floating point unit?