"We need 92% minimum coverage for herd immunity and we do not have it."
Lies, Damn Lies, and Statistics.
The 'herd' consists of everybody, not just the patients.
Your 'herd' only sampled the patients, hence your percentages are not from the entire herd...
We hope that it is likely for an incomplete or unvaccinated person to be more likely to become a patient than a fully vaccinated person...
It only needs to be is 2.4 more likely ((11+8)/8) for the 'herd' to be at 92% based on the statistics mentioned here...
So... If the vaccine is only 58% effective or better (1-(8/(11+8))), then you do have 92% coverage. If the vaccine is less than 58% effective, then it's a terrible vaccine...
Very true, and there also were the HST modems from US Robotics. Expensive but reliable and fast. I wonder if I still have that 9600bps HST modem that I bought used in a closet somewhere. IIRC, the HST modems where there a little before the PEP modems, but the PEP modems were cheaper so got more popular eventually.
And then there were these upload/download protocols, beyond xmodem/ymodem/zmodem, you had 'full duplex' ones that allowed parallel uploading and downloading of files (bimodem http://en.wikipedia.org/wiki/BiModem).
After that you started being able to do some more things off-line (I remember uucp, and QWK http://en.wikipedia.org/wiki/QWK_(file_format) , and 'soup'). You could select files for upload and download offline, and let your computer dialup into the bbs during the wee hours of the night. The bbs would have a prepared compressed package ready for you with your emails, group messages, exchange files, etc, and you could hangup immediately after the upload/download, for a much reduced number of minutes on the phone (which mattered a lot if it was not a flat-fee call)... There were special DOS programs to do all that, they could program the BIOS to turn your PC on at the right time at night and turn off when finished.
Not soon after that the Internet took off and many wheels had to be reinvented with new names and protocols.
It would take 'only a couple of days' for an email to reach the other side of the globe. Email addresses were numbers with a colon, slashes, a dot.
Yes kids: Colon, slash and dot. http colon slash and dot.
I love c++, but it definitely has some dark spots, even still the long overdue c++0x update (c++11 whatever). Thank deity we finally have standard smart pointers, better templates in various ways, move semantics, etc. It was really necessary to finally have that, even if it was a decade late (I'm sure we lost quite a bunch of good c++ programmers and projects to more newfangled languages in the delay). Even though we often won't be able to use it until all compilers (and developers) in use for a certain codebase are updated, it is a start.
c++ streams... After exceptions the second worst mistake in c++... c++ needs something good for that functionality, but streams and exceptions don't help.
Beware of std::cout, it is not thread-safe and is a gigantic pain in the expletive for outputting formatted text. The utility of overloading the shift operator for interfacing with streams is overrated. std::endl is a curse word. streambuf is an ugly hack.
while std::string is usually an improvement over the plain 'char *', it also is as often overkill as it often is underpowered. Why else would so many people have their own string class? Why would Qt have QString? It's because std::string and fstreams are severely lacking... standard c++ needs more syntactic strength in tokenizing, parsing, formatting, transforming, combining, and type-converting of string content. What is there, in the standard, is, well, imho kludgy. I'm not saying that I have the answer to what exactly it needs, it just needs something better.
c++ still has a lot of catching up to do. Libraries like boost should really only have their sandbox and legacy code left, and libraries like qt shouldn't need to redo/replace basic functionality. It should be possible to get a proof of concept implementation (aka badly optimized but mostly functional and not too many bugs for a demo or trial) working quickly as easy in c++ as it does in certain other languages. Until then, it should work hard to catch up before we lose most programmers to other languages.
Maybe the company should keep some old original crackberries and maybe a couple of RAZRs on hand as replacements for 'broken' ones... That will fix the problem faster than anything...
I'm not sure if I should believe the video, it looks like an infomercial, and the disclaimer flashed at the end doesn't instill confidence that it really exists and works...
Those people who are 35 and up now were teenagers 25 years ago, that's 1986 and earlier. In 1986 and before, the time in which the people who are at least 35 years old and today were young teenagers beginning to think about which career path to choose. And in 1986, computers were, well, mostly boring, and definitely not something to make good money in.
So, how many teenagers do you think choose a career path into something that looks boring and not making much money?
MSDOS and it's FAT filesystem (and their predecessors) had it too, and called them 'file extensions', They uses things like 'exe' for the apps, 'ico' for the related icons, 'jpg' for the photo, 'txt' for the comments, 'doc' for the related documents, 'bat' for task descriptions, etc, etc.
They just aren't used like that much...
And instead of using what already exists, it's much better to reinvent the wheel and give it a whole new name.
I've had one of those black rectangle flatscreen mobile devices to play videos for the little one quite a while now, and it was on the market before the iPad. It has been mistaken for an iPad frequently, even though it doesn't even have a touchscreen.
Here is a picture, 'looks like an iPad', or, because it predates it, 'an iPad looks like this':
I'm not saying it's an iPad, but it looks like one and it's a battery powered thing with a big screen you can carry around and it has screens with icons, menus, and stuff, it even plays videos and music.
That looks pretty helpful, almost like a synaptic for windows. Does it also get rid of the 'I have an update please do another cycle of clicks now' popups that so many windows applications have?
"there would still be some murmurings about whether or not that teachers having a direct, unfiltered, (and most of all) unmonitored access to their child outside of class is a good or bad thing."
Good point, but who says that the social networks can't make something where the parents of a child, as known to the network, can choose to want to review and filter that communication, like moderators, as it is on done certain forums?
I bet a lot of parents would love to have the option to 'approve/disapprove' certail levels of contact to their children from 'outsiders'. Nana can talk directly, others get moderated by mom, dad, or nana;-), and all postings with links to websites get moderated too...
Social Networks are not just for 'buddies', they are a way for people to communicate, and apparently quite a popular one. I can see it useful for kids to ask their teacher questions on-line, or for a teacher to notify or remind their students of something. Yes, there are other things for that such as forums, email, and chat, but there are social networks for that too, and (gasp) some people like them (probably because it both integrates a lot of the on-line methods and communication and removes things such as needing to update a contact because they switched email addresses). Don't get me wrong, I mostly use email myself, but that might just be 'legacy' or 'habit'.
Now, many students wouldn't want their teacher to see everything they do/say on the social networks, but that's what google plus has those 'circles' for. You can even let people you don't like be 'in' your social network, you just put them in a 'circle' that doesn't see anything (and vice-versa, the on-line version of fake friendlyness).
"If only it was engineered like a modern TV to burn out in a year or two"
So was most stuff in the 80s. The TV just got lucky.
At any point in time T, there will always be peope with a still working product of T-30 years wondering why they nowadays "don't make products like that anymore", ignoring how many products from time T-30 years have broken down many many years ago and are long forgotten.
The 'democracy of open source' is that if someone wants to make it, he can, and if it's better than the other thing out there (or the only thing), people will start to use it.
X has had the advantage of being the only display server out there (no I'm not counting fbdev, libsvga etc). Well, with Wayland it will have some serious competition. May the best display server win!
What you're looking for i 'strlcpy()' (or on windows maybe 'strncpy_s()'). BSD has strlcpy(), I don't know why glibc (Linux) doesn't have it by default. Actually, I do sort of know: The glibc project leader doesn't like it: http://sources.redhat.com/ml/libc-alpha/2002-01/msg00002.html
Ulrich left it out because he either doesn't like the (BSD) people who came up with strlcpy() (http://www.gratisoft.us/todd/papers/strlcpy.html), or it is what he implies, that he is convinced it encourages lazy programming and causes unexpected failure modes if the programmer forgets that strlcpy() can truncate a string (well he literally says something else, but if he literally means what he says then he just plainly doesn't understand where source strings can come from in the real world).
Besides the fact that strlcpy() has a return value that indicates truncation, he (incorrectly) assumes that ignored truncation can only be bad. I say incorrectly, because there are plenty of cases where a string truncation by strlcpy() is no problem. One important one of them is when the source string is only too long for the buffer if it is either erroneous (and a truncated version of the string is not more problematic later on), or it is specially crafted to try to cause a buffer overflow.... Honestly, I think the missing strlcpy() in glibc is more about personalities than anything else. Oh well...
The irony is that, as a result, some (many?) programmers are now using strncpy() and assuming it does the same thing as strlcpy(), causing more problems than strlcpy() even could have caused in Ulrich's imagination.
The (in case of overflow) not NUL-terminating of strncpy() means the destination is not guaranteed a string. It clearly was not meant to have a string as destination, but just a buffer (that's what the man page says too btw). It's padding with zeros to prevent 'leakage' of previous data in the destination, in case later the destination buffer is forwarded/stored as a whole (not as a string).
I think the main problem with that funtion is its name, it does not do what the name implies. A better name would be memstrcpy(dst,src,count), because it really is a memcopy where the source is a string and the destination is a buffer (it will never read past the end of the source string but always write the entire destination buffer).
I wonder how many people don't have a clue about this. For example, even "{char buf[10]; strncpy(buf,something,9);}" is still not safe, because buf[9] is uninitialized and therefore not guaranteed to be NUL... If you want to use strncpy() and the destination buffer is later treated as a string, you really have to make sure yourself that the last char in your buffer is NUL. When you do use strncpy(), you can check afterwards if the string did fit (it's going to be NUL if it did, not NUL if it didn't), and take appropriate action... But that's a lot of code if you just want a string copy with length truncation, aka strlcpy()...
Slashdot Mirror
That's a classic mistake...
Try this with your function: int main() { int a = 5; int b = MIN(++a, 10); printf("%d\n",b); }
Yeah, that's really '7' what it printed, because your macro causes the increment to happen twice...
DANGER
*Big Scary Laser*
Do not look Into beam with remaining eye!
"We need 92% minimum coverage for herd immunity and we do not have it."
Lies, Damn Lies, and Statistics.
The 'herd' consists of everybody, not just the patients.
Your 'herd' only sampled the patients, hence your percentages are not from the entire herd...
We hope that it is likely for an incomplete or unvaccinated person to be more likely to become a patient than a fully vaccinated person...
It only needs to be is 2.4 more likely ((11+8)/8) for the 'herd' to be at 92% based on the statistics mentioned here...
So... If the vaccine is only 58% effective or better (1-(8/(11+8))), then you do have 92% coverage. If the vaccine is less than 58% effective, then it's a terrible vaccine...
Very true, and there also were the HST modems from US Robotics. Expensive but reliable and fast. I wonder if I still have that 9600bps HST modem that I bought used in a closet somewhere. IIRC, the HST modems where there a little before the PEP modems, but the PEP modems were cheaper so got more popular eventually.
http://en.wikipedia.org/wiki/Us_robotics
And then there were these upload/download protocols, beyond xmodem/ymodem/zmodem, you had 'full duplex' ones that allowed parallel uploading and downloading of files (bimodem http://en.wikipedia.org/wiki/BiModem).
After that you started being able to do some more things off-line (I remember uucp, and QWK http://en.wikipedia.org/wiki/QWK_(file_format) , and 'soup'). You could select files for upload and download offline, and let your computer dialup into the bbs during the wee hours of the night. The bbs would have a prepared compressed package ready for you with your emails, group messages, exchange files, etc, and you could hangup immediately after the upload/download, for a much reduced number of minutes on the phone (which mattered a lot if it was not a flat-fee call)... There were special DOS programs to do all that, they could program the BIOS to turn your PC on at the right time at night and turn off when finished.
Not soon after that the Internet took off and many wheels had to be reinvented with new names and protocols.
It would take 'only a couple of days' for an email to reach the other side of the globe. Email addresses were numbers with a colon, slashes, a dot.
Yes kids: Colon, slash and dot. http colon slash and dot.
Bastards!
But he won anyway, because he learned a valuable lesson about Microsoft...
Yep, as they detailed back in 2009:
http://googlemobile.blogspot.com/2009/08/bright-side-of-sitting-in-traffic.html
(((((*what))) are(((you)))saying)))?((((there))))?
#warning rant coming
"printf instead of std::cout"
I love c++, but it definitely has some dark spots, even still the long overdue c++0x update (c++11 whatever). Thank deity we finally have standard smart pointers, better templates in various ways, move semantics, etc. It was really necessary to finally have that, even if it was a decade late (I'm sure we lost quite a bunch of good c++ programmers and projects to more newfangled languages in the delay). Even though we often won't be able to use it until all compilers (and developers) in use for a certain codebase are updated, it is a start.
c++ streams... After exceptions the second worst mistake in c++... c++ needs something good for that functionality, but streams and exceptions don't help.
Beware of std::cout, it is not thread-safe and is a gigantic pain in the expletive for outputting formatted text. The utility of overloading the shift operator for interfacing with streams is overrated. std::endl is a curse word. streambuf is an ugly hack.
while std::string is usually an improvement over the plain 'char *', it also is as often overkill as it often is underpowered. Why else would so many people have their own string class? Why would Qt have QString? It's because std::string and fstreams are severely lacking... standard c++ needs more syntactic strength in tokenizing, parsing, formatting, transforming, combining, and type-converting of string content. What is there, in the standard, is, well, imho kludgy. I'm not saying that I have the answer to what exactly it needs, it just needs something better.
c++ still has a lot of catching up to do. Libraries like boost should really only have their sandbox and legacy code left, and libraries like qt shouldn't need to redo/replace basic functionality. It should be possible to get a proof of concept implementation (aka badly optimized but mostly functional and not too many bugs for a demo or trial) working quickly as easy in c++ as it does in certain other languages. Until then, it should work hard to catch up before we lose most programmers to other languages.
I remember how the first building exploded and a specialist in the news said that that really isn't a big deal and that nothing really was wrong.
It's not on the web page, but there is a 0.8.10 from a week ago:
http://lists.gnu.org/archive/html/gnash/2012-02/msg00000.html
Yeah, because that never happened before. Oh, wait...
Maybe the company should keep some old original crackberries and maybe a couple of RAZRs on hand as replacements for 'broken' ones... That will fix the problem faster than anything...
I'm not sure if I should believe the video, it looks like an infomercial, and the disclaimer flashed at the end doesn't instill confidence that it really exists and works...
Well duh.
If only I could become a bank to borrow at the FED counter...
Those people who are 35 and up now were teenagers 25 years ago, that's 1986 and earlier. In 1986 and before, the time in which the people who are at least 35 years old and today were young teenagers beginning to think about which career path to choose. And in 1986, computers were, well, mostly boring, and definitely not something to make good money in.
So, how many teenagers do you think choose a career path into something that looks boring and not making much money?
MSDOS and it's FAT filesystem (and their predecessors) had it too, and called them 'file extensions', They uses things like 'exe' for the apps, 'ico' for the related icons, 'jpg' for the photo, 'txt' for the comments, 'doc' for the related documents, 'bat' for task descriptions, etc, etc.
They just aren't used like that much...
And instead of using what already exists, it's much better to reinvent the wheel and give it a whole new name.
(/sarcasm, or not?)
I've had one of those black rectangle flatscreen mobile devices to play videos for the little one quite a while now, and it was on the market before the iPad. It has been mistaken for an iPad frequently, even though it doesn't even have a touchscreen.
Here is a picture, 'looks like an iPad', or, because it predates it, 'an iPad looks like this':
http://www.technotalks.com/reviews/aluratek-preps-in-cinepal-hi-def-portable-media-player/
I'm not saying it's an iPad, but it looks like one and it's a battery powered thing with a big screen you can carry around and it has screens with icons, menus, and stuff, it even plays videos and music.
And in the article you link to, a commenter also linked to this interesting image: http://i.imgur.com/3AlUc.jpg
That looks pretty helpful, almost like a synaptic for windows. Does it also get rid of the 'I have an update please do another cycle of clicks now' popups that so many windows applications have?
"there would still be some murmurings about whether or not that teachers having a direct, unfiltered, (and most of all) unmonitored access to their child outside of class is a good or bad thing."
Good point, but who says that the social networks can't make something where the parents of a child, as known to the network, can choose to want to review and filter that communication, like moderators, as it is on done certain forums?
I bet a lot of parents would love to have the option to 'approve/disapprove' certail levels of contact to their children from 'outsiders'. Nana can talk directly, others get moderated by mom, dad, or nana ;-), and all postings with links to websites get moderated too...
Social Networks are not just for 'buddies', they are a way for people to communicate, and apparently quite a popular one. I can see it useful for kids to ask their teacher questions on-line, or for a teacher to notify or remind their students of something. Yes, there are other things for that such as forums, email, and chat, but there are social networks for that too, and (gasp) some people like them (probably because it both integrates a lot of the on-line methods and communication and removes things such as needing to update a contact because they switched email addresses). Don't get me wrong, I mostly use email myself, but that might just be 'legacy' or 'habit'.
Now, many students wouldn't want their teacher to see everything they do/say on the social networks, but that's what google plus has those 'circles' for. You can even let people you don't like be 'in' your social network, you just put them in a 'circle' that doesn't see anything (and vice-versa, the on-line version of fake friendlyness).
For completenes, the xkcd link:
http://xkcd.com/849/
"If only it was engineered like a modern TV to burn out in a year or two"
So was most stuff in the 80s. The TV just got lucky.
At any point in time T, there will always be peope with a still working product of T-30 years wondering why they nowadays "don't make products like that anymore", ignoring how many products from time T-30 years have broken down many many years ago and are long forgotten.
The 'democracy of open source' is that if someone wants to make it, he can, and if it's better than the other thing out there (or the only thing), people will start to use it.
X has had the advantage of being the only display server out there (no I'm not counting fbdev, libsvga etc). Well, with Wayland it will have some serious competition. May the best display server win!
Wayland not having a network transport is like a new cadillac model not being sold in Texas. You know, it won't take a miracle to make it happen.
I've used X since the dark ages myself, but that doesn't mean something new can't be better, and I do know X has its limitations.
What you're looking for i 'strlcpy()' (or on windows maybe 'strncpy_s()'). BSD has strlcpy(), I don't know why glibc (Linux) doesn't have it by default. Actually, I do sort of know: The glibc project leader doesn't like it: http://sources.redhat.com/ml/libc-alpha/2002-01/msg00002.html
Ulrich left it out because he either doesn't like the (BSD) people who came up with strlcpy() (http://www.gratisoft.us/todd/papers/strlcpy.html), or it is what he implies, that he is convinced it encourages lazy programming and causes unexpected failure modes if the programmer forgets that strlcpy() can truncate a string (well he literally says something else, but if he literally means what he says then he just plainly doesn't understand where source strings can come from in the real world).
Besides the fact that strlcpy() has a return value that indicates truncation, he (incorrectly) assumes that ignored truncation can only be bad. I say incorrectly, because there are plenty of cases where a string truncation by strlcpy() is no problem. One important one of them is when the source string is only too long for the buffer if it is either erroneous (and a truncated version of the string is not more problematic later on), or it is specially crafted to try to cause a buffer overflow.... Honestly, I think the missing strlcpy() in glibc is more about personalities than anything else. Oh well...
The irony is that, as a result, some (many?) programmers are now using strncpy() and assuming it does the same thing as strlcpy(), causing more problems than strlcpy() even could have caused in Ulrich's imagination.
The (in case of overflow) not NUL-terminating of strncpy() means the destination is not guaranteed a string. It clearly was not meant to have a string as destination, but just a buffer (that's what the man page says too btw). It's padding with zeros to prevent 'leakage' of previous data in the destination, in case later the destination buffer is forwarded/stored as a whole (not as a string).
I think the main problem with that funtion is its name, it does not do what the name implies. A better name would be memstrcpy(dst,src,count), because it really is a memcopy where the source is a string and the destination is a buffer (it will never read past the end of the source string but always write the entire destination buffer).
I wonder how many people don't have a clue about this. For example, even "{char buf[10]; strncpy(buf,something,9);}" is still not safe, because buf[9] is uninitialized and therefore not guaranteed to be NUL... If you want to use strncpy() and the destination buffer is later treated as a string, you really have to make sure yourself that the last char in your buffer is NUL. When you do use strncpy(), you can check afterwards if the string did fit (it's going to be NUL if it did, not NUL if it didn't), and take appropriate action... But that's a lot of code if you just want a string copy with length truncation, aka strlcpy()...