Actually, it is that hard. I needed some CR32032 batteries, and looked on Amazon. Guess what? There's a ton of sellers, claiming to sell from a ton of vendors. I'll guess that many of them will sell me a battery with the right physical and electrical form factor, but....
Which brands last longer? Which sellers are selling official brands, and which are selling indistinguishable knockoffs? Are the knockoffs actually worse?
Is something that looks more official and appears more reputable actually selling something better? Or am I paying for reputation and not actual quality?
How valid are the reviews? Are they astroturf? Does it matter? How can someone tell a good battery from a bad one, anyway, right after getting it. Are the just giving 5 stars because the batteries came quickly in nice packaging?
I think these are all reasonable questions, but I don't have an answer to any of them. I'm hoping that someone has done a real comparison, and can provide some kind of solid data.
What's the probabilitiy... It's easily possible to idly speculate on answers: Probability of life starting? On Earth, life started up pretty much right away. If it was unlikely, it's more likely to have started later, not earlier.
Probability of life becoming complex: low (ish). Out of roughly 5 billion years, 4 billion were spent on one-celled organisms
Probability of sentience: out of a metric buttload of species, we know of exactly one species with both sentience and high technology. That kind of indicates that's it's not so much a survival trait:-)
Actually, most of the comments I've seen about the OpenSSL code are immature, and show a lack of appreciation for the changes in the industry.
Like, remember that if-isupper-then-tolower code? Well, back in the day, tolower on most platforms would just bit-bang in a '1' bit. That will convert A to a, but also converts at-sign to back-tick. In "modern" toolchains, this doesn't happen any more; tolower is expected to handle all chars, and work correctly.
But -- as a developer, can you prove that every system that you're running on has a proper implementation of tolower? It's easy for me; I only work with one version of Visual Studio, and I can quickly prove that tolower work.
I've done code that works on multiple platforms. It used to be really, really gnarly: everything platform was always just a little bit different. And you get code that looks just like what I've seen in the snarky comments.
Eyeballing the data, there's a ton of noise but there is a decent trend in there. And the data in the last 7 years doesn't look like it is violation of that trend, or the prediction voiced by Mr. Gore.
WTF? Are you mad? Or drunk? The whole point of a model is to predict the future. And they can, and do, make predictions. And over time, we can see if the predictions worked.
And your biggest issue is that the model conserved energy? You do know that in the middle of a time-step, things get wonky, right? And that the modelers know this, and therefore apply some brainpower to make it work?
The early models of galaxy collision (per the Toomre brothers) were astonishingly low-res, and yet they captured some pretty subtle effects. And guess what? They had to apply fix-ups on each time-step, too!
Climate researchers have certainly put some real thought into geo-engineering. The neatest simulation was, "what happens if we try geo-engineering, and have to stop". Result: everything goes to heck, and in a hurry.
I've used some of the earlier "internet tablets" (e.g., the Nokia N800) and PDA. Early machines had real issues with being powerful enough to actually work well -- something my low-end phone still struggles with.
(Not to mention the terrible, terrible connection managers. For one particularly horrid PDA, I spent more time trying to get on the internet than actually using the internet)
That's a pretty strong accusation. Other than, "I don't know anything about this government department, so I'll throw around a random accusation", do you have any actual evidence?
For example, how well do they handle paperwork compared to a typical insurance company? Personally, I find the IRS documents more straightforward and less confusing.
How do they compare in cost to a typical payroll processor like ADP? They have about the same scale; according to because ADP is private and the IRS is public, ADP should have radically lower costs. Do they?
In short, just because they are big, that doesn't make them "inefficient".
Specifically, the Republican mismanagement. Would it have been so hard to deliver the IT budget that the IRS asked for in order to mitigate this very problem?
OK, I'm a little late to the party here. The issue with the apps isn't that "SSL is insecure" or that "SSH is better". The problem is: most security APIs require multiple levels of APIs to work correctly, where each level is hard to get right, and easy to get wrong.
Worse, a substantial number of apps will turn off one level or another "for debugging" and then not turn them back on for their release version.
Some of the earliest (European) laws are about the duty of hotels to serve all comers. If you're a country, and you want people to travel to market towns to buy and sell, it turns out that you have to make laws requiring that hotels treat everyone uniformly; that traders can go to a town knowing (with high confidence) that they will be able to eat and sleep. In some places, there were additional requirements that hotels be able to feed and care for a herd of animals, too. This is also why hotels are required to safes: traders have to know that their goods are secure, especially from the people most able to steal it (the hotel workers)
So, the solution to "standard deviation is hard" to is rephrase it in terms of "square root of the second moment about the mean"? I'm on board! that's totally simpler and more intuitive!
Ummm-- nonsense? Lots of people have one person, above all others, that they cherish. And for most of life, it doesn't really matter that this is the case (but like, for most of life, my hobby doesn't actually much matter to other people). But sometimes, that one person I cherish really does have extra power. Who gets to visit me in the hospital (answer: the one I cherish does!) Who gets my kids if I die (answer: the one I cherish does) Who gets my stuff if I don't have a will? (answer: the one I cherish does).
And hey, isn't it handy that there's a super-simple, cheap way to tell who I cherish: it's the person holding the marriage certificate! So an entire mass of horrible, messy, expensive problems becomes simple and clear.
Oh, and it also turns out that there's a nasty problem with the way that humans procreate: it's really long term, only one gender can do a bunch of the hard work. And often people who cherish each other have a commitment that one will do more of the looking after kids and the other more of the earning money. And because it's two people that work like one unit, it makes sense to fiddle the tax codes a bit so that it's more or less fair. (Like everything in tax code, there's always corner cases)
WTF? We're talking about bulk here; the normal 95% of people in a profession, not the nobel prize winners. I've literally no idea how you managed even think that "rockstar" was the key issue here in any way, shape or form.
You're not trying very hard to find any counter-evidence, are you? The fact that other STEM fields are experiencing increasing balance, and our is increasingly unbalanced doesn't register for you? The many personal anecdotes are not in your site?
Worse, you don't see the increasing evidence that men and women are much, much more alike than non-alike? That both sides are fully capable of essentially all tasks that the other can do?
In ever so many fields, over the last hundred years, men have declared that only men can do job A, B, or C; it's been clearly proven wrong in basically all cases. Is our field so very different? History would say no: we are like cooking (once a male prerogative), telephone operator, surgeon, and CEO.
Damn straight. IBM had a network, and Burroughs had a network, and ICL had a network,... everyone had a network! And nobody's network talked to anybody elses. Except IBM. They have about four incompatible network schemes:-)
Yes: they would have been one of "n" winners, each with incompatible content. You'd be in the situation (like the old phone companies) where a person on network "a" couldn't contact a person on network "b". That would be substantially less valuable than the fully interoperable internet we have today.
You're rather cherry-picking your data. Solyndra made a big bet: that the raw cost of the silicon in solar power would be important, and that a remarkably cool manufacturing technique to use a lot less would have a ton of value. As it turns out, that's not how the industry went: silicon costs dropped faster than anticipated, and the manufacturing costs of the Solyndra didn't.
We weren't "picking winners and losers" here: we enabled a big bet. Big bets don't always work.
And the internet was absolutely funded for years by the public purse to develop all of the major technologies and to make the same set of "big bets" about the valuable and non-valuable aspects of internet communication. Private people only became interested because of that investment.
And part of the investment was the "picking a winner". The key to the internet is that it worked across multiple vendors. If we hadn't have done that, there would be an ATT network, an IBM network, a Unisys network, and so on. The government chose a winner (cross platform) and a loser (per-company networks).
Yes, but that not how IP networks work. When the server sends you a packet, it needs to pick exactly one IP address as the destination. Because your WiFi and Cell are on different networks, they give you different IP addresses. So the server has to pick either your WiFi or your cell IP address. Once that packet is sent, it's not going to ever get to you via the "other" network.
That's why the multipath needs special support. Among other things, lots of web sites which are on multiple load-balanced servers need to affinitize your session to a single server. Those load balancers are currently (AFAICT) knowledgeable about Multipath.
My prediction: apps will have to opt-in to get this feature, but beyond setting a flag when they set up the connection, nothing more is needed.
New protocols? A low-level protocol like like a PGM or ICMP? No, the RT sockets don't let you do that (among other things, there's hardly any value: even if you made a new low--level protocol, you'd have trouble getting internet-scale adoption (heck, even useful things like PGM have trouble, and we're never getting another ICMP again).
RT Sockets are a wrapper over WinSock (aka, Windows version of BSD sockets), but with some stuff cut out and object-orient-ified.
(cough). Actually, we rebuilt the RT Socket API from top to bottom, and part of that work involves changing all the names.
What you get with the change is APIs that actually work together: it's a smaller set of objects and radically fewer data structures and the result is something more powerful.
For example, to pull a byte-swapped integer out of a RT Socket, all you do it slap a "DataReader" onto the socket's stream, and read ints until the cows come home. In BSD, it's definitely more awkward: recv returns a void* which in practice is commonly a big char buffer which you pull data out of. But when it comes time to swab your bytes with htonl, you need to convert a pointer-to-char to a u_long. But a u_long needs to be u_long-aligned, so you can't just do some casting; you have to pull the data out and memcpy it into a u_long.
Or, to see a real advance; given a socket, you can, just by "hopping" from socket to hostname to IP information to network adapter, and from there you can get to the network information itself.
You can also directly get some useful socket statistics like your bandwidth usage and the round trip time data.
And (Ok, last point): we have sockets, and we have WebSockets (which follow the normal WebSocket protocol standards). And they have the same basic set of functions, meaning that your socket code and your websocket code are easily swappable!
I'm an old fart who went to a good private school way back in the 80's. And our professors complained about our lack of work ethic, our ability to do assignments, and our writing ability.
IMHO, what's really happening is that your skills are getting better as you age, and you're automatically up-leveling what "average" is. Back when your were in college, other kids were about as good as you. But now you have years of experience and you're way better. Only you still compare yourself to the kids, and of course they do worse.
The long term tests on college performance show that we aren't in any way getting worse academically.
Slashdot Mirror
Actually, it is that hard. I needed some CR32032 batteries, and looked on Amazon. Guess what? There's a ton of sellers, claiming to sell from a ton of vendors. I'll guess that many of them will sell me a battery with the right physical and electrical form factor, but....
Which brands last longer?
Which sellers are selling official brands, and which are selling indistinguishable knockoffs?
Are the knockoffs actually worse?
Is something that looks more official and appears more reputable actually selling something better? Or am I paying for reputation and not actual quality?
How valid are the reviews? Are they astroturf? Does it matter? How can someone tell a good battery from a bad one, anyway, right after getting it. Are the just giving 5 stars because the batteries came quickly in nice packaging?
I think these are all reasonable questions, but I don't have an answer to any of them. I'm hoping that someone has done a real comparison, and can provide some kind of solid data.
Funny, I remember the same thing. And it's an old usage to -- I see from the Electric Interlocking Handbook (1913) at http://books.google.com/books?id=ZPINAAAAYAAJ&pg=PA93&dq=%2B%22buss%22+electric&hl=en&sa=X&ei=4kfUU4_2McW1iwKwyYHIBA&ved=0CFgQuwUwBg#v=onepage&q=%2B%22buss%22%20electric&f=false that it's been used in the industry.
What's the probabilitiy...
It's easily possible to idly speculate on answers:
Probability of life starting? On Earth, life started up pretty much right away. If it was unlikely, it's more likely to have started later, not earlier.
Probability of life becoming complex: low (ish). Out of roughly 5 billion years, 4 billion were spent on one-celled organisms
Probability of sentience: out of a metric buttload of species, we know of exactly one species with both sentience and high technology. That kind of indicates that's it's not so much a survival trait :-)
Tenure exists in the secondary education market because local school boards used to always fire teachers before they could qualify for their pension.
Actually, most of the comments I've seen about the OpenSSL code are immature, and show a lack of appreciation for the changes in the industry.
Like, remember that if-isupper-then-tolower code? Well, back in the day, tolower on most platforms would just bit-bang in a '1' bit. That will convert A to a, but also converts at-sign to back-tick. In "modern" toolchains, this doesn't happen any more; tolower is expected to handle all chars, and work correctly.
But -- as a developer, can you prove that every system that you're running on has a proper implementation of tolower? It's easy for me; I only work with one version of Visual Studio, and I can quickly prove that tolower work.
I've done code that works on multiple platforms. It used to be really, really gnarly: everything platform was always just a little bit different. And you get code that looks just like what I've seen in the snarky comments.
From TFA (2007): "Gore said that Arctic ice could be gone entirely in 34 years, and he made it seem like a really precise prediction"
OK, it's been 6 or 7 years since then. Would you say the artic ice is substantially less, substantially more, or about the same from then?
Hint: data at http://nsidc.org/arcticseaicen...
Eyeballing the data, there's a ton of noise but there is a decent trend in there. And the data in the last 7 years doesn't look like it is violation of that trend, or the prediction voiced by Mr. Gore.
WTF? Are you mad? Or drunk? The whole point of a model is to predict the future. And they can, and do, make predictions. And over time, we can see if the predictions worked.
And your biggest issue is that the model conserved energy? You do know that in the middle of a time-step, things get wonky, right? And that the modelers know this, and therefore apply some brainpower to make it work?
The early models of galaxy collision (per the Toomre brothers) were astonishingly low-res, and yet they captured some pretty subtle effects. And guess what? They had to apply fix-ups on each time-step, too!
Climate researchers have certainly put some real thought into geo-engineering. The neatest simulation was, "what happens if we try geo-engineering, and have to stop". Result: everything goes to heck, and in a hurry.
More like 3K for a terminal, and 5K for a PC.
I've used some of the earlier "internet tablets" (e.g., the Nokia N800) and PDA. Early machines had real issues with being powerful enough to actually work well -- something my low-end phone still struggles with.
(Not to mention the terrible, terrible connection managers. For one particularly horrid PDA, I spent more time trying to get on the internet than actually using the internet)
That's a pretty strong accusation. Other than, "I don't know anything about this government department, so I'll throw around a random accusation", do you have any actual evidence?
For example, how well do they handle paperwork compared to a typical insurance company? Personally, I find the IRS documents more straightforward and less confusing.
How do they compare in cost to a typical payroll processor like ADP? They have about the same scale; according to because ADP is private and the IRS is public, ADP should have radically lower costs. Do they?
In short, just because they are big, that doesn't make them "inefficient".
Specifically, the Republican mismanagement. Would it have been so hard to deliver the IT budget that the IRS asked for in order to mitigate this very problem?
OK, I'm a little late to the party here. The issue with the apps isn't that "SSL is insecure" or that "SSH is better". The problem is: most security APIs require multiple levels of APIs to work correctly, where each level is hard to get right, and easy to get wrong.
Worse, a substantial number of apps will turn off one level or another "for debugging" and then not turn them back on for their release version.
Some of the earliest (European) laws are about the duty of hotels to serve all comers. If you're a country, and you want people to travel to market towns to buy and sell, it turns out that you have to make laws requiring that hotels treat everyone uniformly; that traders can go to a town knowing (with high confidence) that they will be able to eat and sleep.
In some places, there were additional requirements that hotels be able to feed and care for a herd of animals, too.
This is also why hotels are required to safes: traders have to know that their goods are secure, especially from the people most able to steal it (the hotel workers)
So, the solution to "standard deviation is hard" to is rephrase it in terms of "square root of the second moment about the mean"? I'm on board! that's totally simpler and more intuitive!
(note for the sarcasm-impaired: that was sarcasm)
Ummm-- nonsense? Lots of people have one person, above all others, that they cherish. And for most of life, it doesn't really matter that this is the case (but like, for most of life, my hobby doesn't actually much matter to other people). But sometimes, that one person I cherish really does have extra power. Who gets to visit me in the hospital (answer: the one I cherish does!) Who gets my kids if I die (answer: the one I cherish does) Who gets my stuff if I don't have a will? (answer: the one I cherish does).
And hey, isn't it handy that there's a super-simple, cheap way to tell who I cherish: it's the person holding the marriage certificate! So an entire mass of horrible, messy, expensive problems becomes simple and clear.
Oh, and it also turns out that there's a nasty problem with the way that humans procreate: it's really long term, only one gender can do a bunch of the hard work. And often people who cherish each other have a commitment that one will do more of the looking after kids and the other more of the earning money. And because it's two people that work like one unit, it makes sense to fiddle the tax codes a bit so that it's more or less fair. (Like everything in tax code, there's always corner cases)
WTF? We're talking about bulk here; the normal 95% of people in a profession, not the nobel prize winners. I've literally no idea how you managed even think that "rockstar" was the key issue here in any way, shape or form.
You're not trying very hard to find any counter-evidence, are you? The fact that other STEM fields are experiencing increasing balance, and our is increasingly unbalanced doesn't register for you? The many personal anecdotes are not in your site?
Worse, you don't see the increasing evidence that men and women are much, much more alike than non-alike? That both sides are fully capable of essentially all tasks that the other can do?
In ever so many fields, over the last hundred years, men have declared that only men can do job A, B, or C; it's been clearly proven wrong in basically all cases. Is our field so very different? History would say no: we are like cooking (once a male prerogative), telephone operator, surgeon, and CEO.
Damn straight. IBM had a network, and Burroughs had a network, and ICL had a network, ... everyone had a network! And nobody's network talked to anybody elses. :-)
Except IBM. They have about four incompatible network schemes
Yes: they would have been one of "n" winners, each with incompatible content. You'd be in the situation (like the old phone companies) where a person on network "a" couldn't contact a person on network "b". That would be substantially less valuable than the fully interoperable internet we have today.
You're rather cherry-picking your data. Solyndra made a big bet: that the raw cost of the silicon in solar power would be important, and that a remarkably cool manufacturing technique to use a lot less would have a ton of value. As it turns out, that's not how the industry went: silicon costs dropped faster than anticipated, and the manufacturing costs of the Solyndra didn't.
We weren't "picking winners and losers" here: we enabled a big bet. Big bets don't always work.
And the internet was absolutely funded for years by the public purse to develop all of the major technologies and to make the same set of "big bets" about the valuable and non-valuable aspects of internet communication. Private people only became interested because of that investment.
And part of the investment was the "picking a winner". The key to the internet is that it worked across multiple vendors. If we hadn't have done that, there would be an ATT network, an IBM network, a Unisys network, and so on. The government chose a winner (cross platform) and a loser (per-company networks).
Yes, but that not how IP networks work. When the server sends you a packet, it needs to pick exactly one IP address as the destination. Because your WiFi and Cell are on different networks, they give you different IP addresses. So the server has to pick either your WiFi or your cell IP address. Once that packet is sent, it's not going to ever get to you via the "other" network.
That's why the multipath needs special support. Among other things, lots of web sites which are on multiple load-balanced servers need to affinitize your session to a single server. Those load balancers are currently (AFAICT) knowledgeable about Multipath.
My prediction: apps will have to opt-in to get this feature, but beyond setting a flag when they set up the connection, nothing more is needed.
New protocols? A low-level protocol like like a PGM or ICMP? No, the RT sockets don't let you do that (among other things, there's hardly any value: even if you made a new low--level protocol, you'd have trouble getting internet-scale adoption (heck, even useful things like PGM have trouble, and we're never getting another ICMP again).
RT Sockets are a wrapper over WinSock (aka, Windows version of BSD sockets), but with some stuff cut out and object-orient-ified.
Links: documentation is at http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.sockets.aspx/
and there's a talk: http://channel9.msdn.com/Events/Build/BUILD2011/PLAT-580T/
(cough). Actually, we rebuilt the RT Socket API from top to bottom, and part of that work involves changing all the names.
What you get with the change is APIs that actually work together: it's a smaller set of objects and radically fewer data structures and the result is something more powerful.
For example, to pull a byte-swapped integer out of a RT Socket, all you do it slap a "DataReader" onto the socket's stream, and read ints until the cows come home. In BSD, it's definitely more awkward: recv returns a void* which in practice is commonly a big char buffer which you pull data out of. But when it comes time to swab your bytes with htonl, you need to convert a pointer-to-char to a u_long. But a u_long needs to be u_long-aligned, so you can't just do some casting; you have to pull the data out and memcpy it into a u_long.
Or, to see a real advance; given a socket, you can, just by "hopping" from socket to hostname to IP information to network adapter, and from there you can get to the network information itself.
You can also directly get some useful socket statistics like your bandwidth usage and the round trip time data.
And (Ok, last point): we have sockets, and we have WebSockets (which follow the normal WebSocket protocol standards). And they have the same basic set of functions, meaning that your socket code and your websocket code are easily swappable!
Hmmm -- a quick bing search for "aviation grade connector" shows lots and lots of connectors. There are even magazine articles about them.
http://www.aviationtoday.com/av/issue/feature/Product-Focus-Connectors_18865.html
I'm an old fart who went to a good private school way back in the 80's. And our professors complained about our lack of work ethic, our ability to do assignments, and our writing ability.
IMHO, what's really happening is that your skills are getting better as you age, and you're automatically up-leveling what "average" is. Back when your were in college, other kids were about as good as you. But now you have years of experience and you're way better. Only you still compare yourself to the kids, and of course they do worse.
The long term tests on college performance show that we aren't in any way getting worse academically.