> Western nations say they have the "freedom of speech" to insult any religion as they please.
I am pretty sure that the right to insult goes well beyond religions and to everything, including insulting western nations themselves. For example, you will not find as many books as written in the west criticizing the injustice of the west to other... anywhere else (for me that is a sign of maturity... and I am not a westerner).
> When I got my PhD in statistics, one of the first things I was taught in grad school was to never extrapolate inferences beyond the range of observed data.
I am pretty sure you misunderstood the point. That’s a nice principle to keep in mind for statistical model building. But science (cold models + human theories) is all about such extrapolation and theory-building as long as we have reason to believe that the extrapolation will hold (but don’t yet know for sure) until we come up with arguments or evidence that it won’t hold. If there are errors made along the way that’s just normal science. For example, until we have reason to suspect that physics at the speed of light is different from classical physics, it is very rational *and scientific* to believe that the same will hold true. I challenge you to cite *any* science that does not do this.
> From what we know from the world of biology, patterns that appear to hold in the short term will often deviate greatly in the long term. But somehow, we are required to believe that such deviations could never happen elsewhere.
Your PhD is not in Biology. So perhaps you should not extrapolate from your lack of experience (observed data) in this area, that there are any such requirements. Again, I challenge you to cite your sources that biologists actually believe this.
Quite the contrary, I know biologists to understand evolution as a series of punctuated events (Eg: Cambrian explosion) and hardly as homogenous progression. And the current views are not derived simplistically from weak extrapolation, as you claim. There is quite a bit of interdisciplinary triangulation involved here.
I feel you are setting up science as something it never was and necessarily will never be. Statistics may be clean and elegant, but science in-the-wild will always be messy.
> I was an atheist before going to graduate school
I hope you meant you became an agnostic after (I personally don’t distinguish between the two for any significance) because religious models don’t even come close to your unrealistically idealistic epistemological criteria, much less compete with science.
> but I learned the huge number of assumptions upon which science is built. Upon close examination, many or all of the assumptions are wrong
Science was never about not being wrong. It was about being self-critical, principled and rational, with the limited knowledge we have, at the time. And claiming to have found potentially "all" assumptions to be wrong (and implicitly that others don't see) is quite presumptuous, no?
> but scientists merely ostracize those who question the assumptions, saying it is "irrelevant" or to avoid "paralysis by analysis".
Here you argue that science isn’t self-critical at all. Some of that is true. Science is self-critical, but only within limits. Thomas Kuhn pretty much covered the territory here. Scientists question the “assumptions” only when the field is in crisis and it is time for a paradigmatic revolution. Calling for a revolution every other day however is a pointless waste of time. The reason isn’t to avoid analysis paralysis. It is to make sure we move from one state of order (reasonable sound theoretical model) to another state of order, avoiding long periods of chaos in the interim. Its like saying true democracy does not exist and may never... and therefore we should not bother trying.
Look. I too have a PhD and more. I too tried to challenge the core assumptions in my own field (not challenging other fields as it seems to be the case with you) and nobody cared to engage and I moved on. Science does not revolve around me. I get where you are coming from. But you are arguing like Deepak Chopra when you should be arguing like John Ioannidis.
Stated differently... most people don't really need computers in the traditional sense (analyze, design, create). They want better TVs... personal, portable, on-demand, beyond video (magazines, music), highly interactive, with communication functionality... and the tablets are great for that.
I used to think that way too. But there are a number of lesser known open-source tools to convert AA size PDFs to fit 6" screens without resorting to vanilla reflow.
Together, they could handle (crop and clip) all the PDFs I tried them with so far. The trouble with them is that they have individual strengths and one needs to pick and choose by PDF type. By the time we get polished do-it-all tools, we will likely have cheap AA sized eReaders.
Good point. DSL was light, but also felt very clunky: UI and to install extra software. I wanted something with the backing of a standard package repository.
An year or two ago, I was looking for a light Linux to run in a VM and was balancing usability with RAM usage. Here are my numbers from some old notes. Unless specified, the numbers are for RAM usage at login to Desktop at default config (I might have removed some apps I considered non-essential - I don't recall).
Of course, these are not exactly scientific. Was sshd running for Arch?, I didn't note down. The distro version numbers were also not noted, but all distros were roughly from 1.5 years ago. They were more for getting ballpark estimates. AFAI-recall, they were all booted in a 256 MB VM (Virtualbox).
Lubuntu - 85 MB Fluxbuntu 48 MB (31 MB without X) Lubuntu 64 MB (41 MB without X)
Ubuntu Server 10.04 without servers and X - 145 MB (did not expect this) Ubuntu Mint (Gloria) 144 MB Debian Mint 138 MB
ULite Desktop - 54 MB (17 MB without X) ULite Desktop without GDM - 26 MB
Non-Debian (without X) Suse in light server config - 13 MB (incl sshd, 10 MB without) Arch - 14 MB
So, Suse took the light-weight crown for RAM usage at terminal boot. For me though, Lubuntu was the sweet-spot at that time.
Fair enough. *Very basic* arithmetic (coarsely dealing with 1-3 digit numbers) is not just a means. But I am not convinced that calculators destroyed those elementary skills.
If a person neither wants to do mental arithmetic nor wants to pull out a calculator, it just means that he is either plain lazy or simply trusts that the incidence of errors to be small enough that an occasional error does not merit review every time. And don't forget that the same technology that gave us calculators also gave us bar codes & electronic sales registers and online shopping, where arithmetic accuracy issue of store is close to irrelevance. Checking if the price on bill matches what you saw on shelf is a different check. This is the only error I had to concern myself with.
> While these examples don't require exact figures, they require getting a feel for numbers
Math is very much about getting a feel for numbers and their wonderful properties and concepts. I am not suggesting that people stop learning math. Quite the contrary, I think we should learn more and get an even better feel for numbers. It's the focus on old mechanics that is a dialectic consequence of the technology of the day that I object to. Take the carry over method in arithmetic where students spend most of their time. It is only useful when you have a paper and a pen (or something similar like maybe some sand and a twig). It assumes a non-computing, physical external representational medium and is not useful in mental arithmetic instances that you list. If you have the initiative to pull out your pen to apply the method you learned in school, you have the initiative to pull out your smartphone and tap them in. And these days, I can be caught more often without a pen than I can be without a device that can calculate. Logarithmic tables are another example where the look up technique is best forgotten by all, except by math historians. Again, I am not suggesting that we not understand the concept of the logarithmic scale, but that we should not waste time on learning the old table method.
> When the digital clocks came, our children slowly lost the ability to read analog clocks.
Good riddance. The method was an artifact of an archaic technology. Our way of denoting time is also archaic and at some point in the future, might also be considered for revision, in order to harmonize it with other types of measurement.
> Then ubiquitous calculators eroded arithmetic skills.
Arithmetic is a means to an end, not an end in itself. During this time, our math curriculum has also become more advanced than it was from before when there were no calculators. As a society, we have a greater statistical sense than ever before (and need to further improve, a lot more). As a side note, look up "A Mathematician's Lament" by Paul Lockhart.
> The with ever acclerating speed GPS killed our map reading abilities
As maps and even address systems killed our need for honing our instinctive positioning skill.
> smartphones eroded our memory by taking over address lists and phone numbers.
As did Gutenberg press of oral traditions. Also, before smartphones (and speaking as a guy who is still suspicious of smartphones, as they stand), we used paper address books for that, not memorize them all. And before automobiles came along, our address lists were a lot smaller.
> I could see eventually being connected to all the stored information of mankind all the time, and being able to store individual experiences cheaply will allow us to outsource most of our brain functions.
Kind of already happened. Google, Wikipedia, Facebook, Mechanical Turk. Unless you mean cybernetic cognitive integration with the cloud (shudder: not for atrophy fears though).
> But brain is not a factory where the released capacity will be put to some other use.
On what do you base that assertion on? The human brain is remarkably plastic. There is a lot of neuroscience research to back that up. The contrary is exactly what happens.
> Brain and muscle atrophy without usage. What we don't use, we lose, we don't redeploy.
So what parts of our brain have been documented to have atrophied so far? None, of course. Muscle is a different matter. I won't get into the reasons, but the mechanical revolution and the information revolution differ in certain respects.
We are cognitively consuming and processing more information than ever, not less. Whether this is mostly useful or simply information pollution is another matter. But we do think more of many different things now than we ever did. When the computers do our work, we take on more work... either to fully live, according to new expectations... or expect to be paid by showing value in tasks beyond the capability of computers. As computers progressively take on mundane and repetitive tasks, our tasks have become complex, not less.
You doubt you are one... but that is a Luddite argument.
Uh, answering my own post with a counter-argument, spying on your employees really isn't a very good way to accomplish this though. It creates distrust, bad morale, etc. I think there must be a better way to accomplish the same goal, of secrecy.
The issue is not distrust, bad morale, etc. Again, you are only looking at this from a mundane office perspective. That's just an issue of productivity. This is a much bigger issue than that. This is an inquisition on whistle blowers. It is an issue over the very soul for FDA and unlike your average office spying, is very much a headline article.
> but if it is interesting, someone will still leak it. That's why Apple announced the iPhone originally before getting FTC approval.
Your iPhone example doesn't hold here. The targeted personnel are responsible scientists communicating with proper whistle blowing channels regarding impropriety, not some lower-tier techies leaking shallow trinket tidbits for cash to rumor web sites.
> The FTC should do this.
No, they should not. They can certainly act if the leak question was on leaking to competitors and such. But these were issues of public concern and they were clearly told to not investigate... and then they went ahead and did it anyway.
"F.D.A. officials went to the inspector general at the Department of Health and Human Services to seek a criminal investigation into the possible leak, but they were turned down. The inspector general found that there was no evidence of a crime, noting that “matters of public safety” can legally be released to the news media."
> It seems to me that at the beginning of the video (~4:15), the guy peeping out from behind the wall is holding something long and thin aggressively.
It looked that way briefly and that's when they think they saw an RPG and even shooting. However, when they swing around, the crowd or the said person do not realign themselves. They just seem busy with themselves. It hard to confuse a group of mostly unarmed people even if a couple were thought to have arms so closely grouped together as getting ready to fire an RPG at a gun ship. But then again, what do I know. Hind sight - 20/20.
> I guess he thought the guy in the van was giving aid to the enemy.
Even then... if the gunner thought that the wounded insurgent should not be removed, a warning shot at a little distance would have communicated that quite well to the people from the van playing good Samaritans.
But then he goes to open fire on them taking cover by the wall as well. So he must have assumed that they were insurgents as well even though there was no indication that these people were ever armed or hostile.
I hope it caused a broad review of the engagement protocols.
Cython is really about writing C code in a Python like style to create Python extensions. This adds additional complexities in debugging (can't step through in your IDE seamlessly), building and distributing. The trade-off is acceptable in specific cases, but quite clunky otherwise. I am not eager to write anything substantial in it since tool support is not super. Cython is a neat hack. But a better example of using a statically typed native code for performance and a dynamically typed language for productivity is Java + Groovy.
Ultimately however, the language choice boils down to it's eco-system, the point that Miguel was stressing. I pick the language based on whatever community has the libraries and experience for the kind of problem I am solving, even if the language and performance are not the best fit. Python is great for my scientific projects (lots of easy-to-use libraries, quick prototyping). But I am yet to see proper mature equivalents with tooling for things like ZK, and Eclipse RCP on the Python VM.
The point of "wax on wax off" is to teach our karate kid to react with instinctive speed, without needing to think. Quite appropriate for a fighting scenario where split second reactions are required. If you want to teach a student to be a human calculator replacement, then yes, that would be a great strategy. What a waste it is to waste a human potential to replace a device that costs less than a cheap meal... and can still outperform the said human.
There are many learning methods to reach the stated goals. But there is much more to learning than dry goals, and every method choice has its own unique consequences.
What do you think are the chances that a mother in a *developing country* is English literate and understands computer terms - and what hacking means, no less?
What's strange about a son spending all his time on computers when working on computers happens to be his educational background and his current job. To her, that's just a good boy who is working hard.
Given the level of US outsourcing to China, is an occasional western face so unusual now? He might even be working for a company that might be a subsidiary to a US firm.
All this does not translate to her being stupid either. Her competence would be better measured elsewhere.
This is a vulnerability, not an attack that has happened. Vulnerabilities can *potentially* lead to attacks. The title implies that it had already happened.
AFAIK, testing vulnerabilities is not termed an attack; only when they are exploited by a malicious third party.
I don't know Australian law, but armed rebellion is not a "legitimate" (definition: complying with the law) choice anywhere. If you disagree, quote the law which says so. Armed rebellion may be be just, but never legitimate.
The nice bit about a democratic government of laws is that you can use *legitimate* methods to have the laws and rulers changed, without having to resort to violence.
If one cannot be bothered to campaign to the general public (or their representatives) to create enough public understanding to have the laws changed, that one is certainly unlikely to succeed through the use of violent force.
I disagree. It believe it is *mostly* the fault of systems. Nurses and Doctors will embrace technology if they feel it is working for them. It is the systems that don't adequately take into account the nature of the work that they do. Good technologies are viral. They don't need enforcement.
> That some of this has to do with the staff being largely of the 35+ crowd and the propensity of that crowd to not know how to use computers even remotely as well as, say, a 16 year old kid does right now.
That used to be a favorite argument to explain away poor clinical system adoption. But it does not hold true anymore. An average doctor today is at least as computer savvy as an average teenager. They may not use SMS, twitter or use facebook as much as the teens, but they certainly know how a computer works. This isn't the 90s when computers were optional in life.
> Computers take more work to use when you don't have a nice grasp on not only the software or function you're doing, but the regular logical deductions you make from repeated observation and experience.
Good clinical software should not need you to be an expert in computers... just that software... the one they use for several hours each day. And if it takes considerable experience to get up to speed... that's a usability problem... not a user problem.
One would wish. Doctors either spend more time with electronic systems than with paper systems... or if it is a good system... about the same time. The current systems haven't made doctors more productive. There may be an exception or two though in select settings where considerable grant dollars were poured in to build a locally optimized system. Building good clinical systems is hard.
Nope. The current Electronic Medical Record systems are not capable of exchanging information freely. There is no standard data format that everyone can exchange. There are a few standards that can package data, but they are not adequately specified for seamless interoperability. If you request records, they can print them out quickly for you though.
I watched the presentation. It was about time for Google to join the programming language space, but I was not impressed as much as I had been with other Google projects.
Go is fast: Sure. But compared to what? C and C++? They were never known to be fast compiling languages. Go is still a very simple language. So compilation speed is not impressive, relevant or novel *yet*. I recall from my Pascal (Delphi) days of how blazingly fast the compilations were when the language did not have a pre-processor or generics and had a more strict type system. Once Go gets generics and exceptions, we can see how well it compares to similar modern languages.
Go is safe: I somehow kept seeing OCaml in a C style syntax in all this despite Go not being functional (perhaps I am just sleepy:-) ). Better type system, garbage collection, optional typing, higher data types. Imperative Ocaml also only takes a minor performance hit compared to C despite providing a much safer language.
Concurrency: This could be something. The languages with built in support for this are somewhat obscure ATM (Erlang). Hopefully, Go will be more palatable to the mainstream.
Programming languages are finally more than grammars and compilers. Many excellent languages never make it to limelight. C and C++ continue to be first choice for system software despite the existence of several excellent "language" alternatives. Google brand may help Go with an early boost, but it will be the tools, libraries and the community that will have to deliver it; or we will just have another Java FXScript story in front of us.
> How easy it is to show that you do not understand anything at all
And yet you show nothing more than hyperbolic exaggerations when I am talking about my *empirical* observations.
> who cares what size your installers are?
In Delphi days, software download sizes made or broke a shareware's success. In broadband era, download sizes are somewhat less important. But then you can extend the same argument to - computers are faster, RAM is cheaper and anything else.
> average Windows computer would need 32G of memory just to function
Why would you need more memory if apps are statically linked? When loading in-process DLLs, you still load multiple copies into memory, one into each application process. Things are different with out-process DLLs of course, but they are slower since marshaling needs to be done across process space. My statically linked apps took same or less memory space.
And I specifically noted that there is an argument to be made in using dynamic loading for unchanging and common components, just not everything and anything. Your arguments are entirely based on reflexive pre-conceptions, not experience.
Slashdot Mirror
> Western nations say they have the "freedom of speech" to insult any religion as they please.
I am pretty sure that the right to insult goes well beyond religions and to everything, including insulting western nations themselves. For example, you will not find as many books as written in the west criticizing the injustice of the west to other... anywhere else (for me that is a sign of maturity... and I am not a westerner).
> When I got my PhD in statistics, one of the first things I was taught in grad school was to never extrapolate inferences beyond the range of observed data.
I am pretty sure you misunderstood the point. That’s a nice principle to keep in mind for statistical model building. But science (cold models + human theories) is all about such extrapolation and theory-building as long as we have reason to believe that the extrapolation will hold (but don’t yet know for sure) until we come up with arguments or evidence that it won’t hold. If there are errors made along the way that’s just normal science. For example, until we have reason to suspect that physics at the speed of light is different from classical physics, it is very rational *and scientific* to believe that the same will hold true. I challenge you to cite *any* science that does not do this.
> From what we know from the world of biology, patterns that appear to hold in the short term will often deviate greatly in the long term. But somehow, we are required to believe that such deviations could never happen elsewhere.
Your PhD is not in Biology. So perhaps you should not extrapolate from your lack of experience (observed data) in this area, that there are any such requirements. Again, I challenge you to cite your sources that biologists actually believe this.
Quite the contrary, I know biologists to understand evolution as a series of punctuated events (Eg: Cambrian explosion) and hardly as homogenous progression. And the current views are not derived simplistically from weak extrapolation, as you claim. There is quite a bit of interdisciplinary triangulation involved here.
I feel you are setting up science as something it never was and necessarily will never be. Statistics may be clean and elegant, but science in-the-wild will always be messy.
> I was an atheist before going to graduate school
I hope you meant you became an agnostic after (I personally don’t distinguish between the two for any significance) because religious models don’t even come close to your unrealistically idealistic epistemological criteria, much less compete with science.
> but I learned the huge number of assumptions upon which science is built. Upon close examination, many or all of the assumptions are wrong
Science was never about not being wrong. It was about being self-critical, principled and rational, with the limited knowledge we have, at the time. And claiming to have found potentially "all" assumptions to be wrong (and implicitly that others don't see) is quite presumptuous, no?
> but scientists merely ostracize those who question the assumptions, saying it is "irrelevant" or to avoid "paralysis by analysis".
Here you argue that science isn’t self-critical at all. Some of that is true. Science is self-critical, but only within limits. Thomas Kuhn pretty much covered the territory here. Scientists question the “assumptions” only when the field is in crisis and it is time for a paradigmatic revolution. Calling for a revolution every other day however is a pointless waste of time. The reason isn’t to avoid analysis paralysis. It is to make sure we move from one state of order (reasonable sound theoretical model) to another state of order, avoiding long periods of chaos in the interim. Its like saying true democracy does not exist and may never... and therefore we should not bother trying.
Look. I too have a PhD and more. I too tried to challenge the core assumptions in my own field (not challenging other fields as it seems to be the case with you) and nobody cared to engage and I moved on. Science does not revolve around me. I get where you are coming from. But you are arguing like Deepak Chopra when you should be arguing like John Ioannidis.
Stated differently... most people don't really need computers in the traditional sense (analyze, design, create). They want better TVs... personal, portable, on-demand, beyond video (magazines, music), highly interactive, with communication functionality... and the tablets are great for that.
I used to think that way too. But there are a number of lesser known open-source tools to convert AA size PDFs to fit 6" screens without resorting to vanilla reflow.
http://code.google.com/p/sopdf/ (had to compile)
http://sourceforge.net/projects/briss/
http://code.google.com/p/papercrop/
There are also plain image based converters like this one.
http://www.mobileread.com/forums/showthread.php?t=13135
Together, they could handle (crop and clip) all the PDFs I tried them with so far. The trouble with them is that they have individual strengths and one needs to pick and choose by PDF type. By the time we get polished do-it-all tools, we will likely have cheap AA sized eReaders.
Good point. DSL was light, but also felt very clunky: UI and to install extra software. I wanted something with the backing of a standard package repository.
An year or two ago, I was looking for a light Linux to run in a VM and was balancing usability with RAM usage. Here are my numbers from some old notes. Unless specified, the numbers are for RAM usage at login to Desktop at default config (I might have removed some apps I considered non-essential - I don't recall).
Of course, these are not exactly scientific. Was sshd running for Arch?, I didn't note down. The distro version numbers were also not noted, but all distros were roughly from 1.5 years ago. They were more for getting ballpark estimates. AFAI-recall, they were all booted in a 256 MB VM (Virtualbox).
Lubuntu - 85 MB
Fluxbuntu 48 MB (31 MB without X)
Lubuntu 64 MB (41 MB without X)
Ubuntu Server 10.04 without servers and X - 145 MB (did not expect this)
Ubuntu Mint (Gloria) 144 MB
Debian Mint 138 MB
ULite Desktop - 54 MB (17 MB without X)
ULite Desktop without GDM - 26 MB
Non-Debian (without X)
Suse in light server config - 13 MB (incl sshd, 10 MB without)
Arch - 14 MB
So, Suse took the light-weight crown for RAM usage at terminal boot. For me though, Lubuntu was the sweet-spot at that time.
Fair enough. *Very basic* arithmetic (coarsely dealing with 1-3 digit numbers) is not just a means. But I am not convinced that calculators destroyed those elementary skills.
If a person neither wants to do mental arithmetic nor wants to pull out a calculator, it just means that he is either plain lazy or simply trusts that the incidence of errors to be small enough that an occasional error does not merit review every time. And don't forget that the same technology that gave us calculators also gave us bar codes & electronic sales registers and online shopping, where arithmetic accuracy issue of store is close to irrelevance. Checking if the price on bill matches what you saw on shelf is a different check. This is the only error I had to concern myself with.
> While these examples don't require exact figures, they require getting a feel for numbers
Math is very much about getting a feel for numbers and their wonderful properties and concepts. I am not suggesting that people stop learning math. Quite the contrary, I think we should learn more and get an even better feel for numbers. It's the focus on old mechanics that is a dialectic consequence of the technology of the day that I object to. Take the carry over method in arithmetic where students spend most of their time. It is only useful when you have a paper and a pen (or something similar like maybe some sand and a twig). It assumes a non-computing, physical external representational medium and is not useful in mental arithmetic instances that you list. If you have the initiative to pull out your pen to apply the method you learned in school, you have the initiative to pull out your smartphone and tap them in. And these days, I can be caught more often without a pen than I can be without a device that can calculate. Logarithmic tables are another example where the look up technique is best forgotten by all, except by math historians. Again, I am not suggesting that we not understand the concept of the logarithmic scale, but that we should not waste time on learning the old table method.
> When the digital clocks came, our children slowly lost the ability to read analog clocks.
Good riddance. The method was an artifact of an archaic technology. Our way of denoting time is also archaic and at some point in the future, might also be considered for revision, in order to harmonize it with other types of measurement.
> Then ubiquitous calculators eroded arithmetic skills.
Arithmetic is a means to an end, not an end in itself. During this time, our math curriculum has also become more advanced than it was from before when there were no calculators. As a society, we have a greater statistical sense than ever before (and need to further improve, a lot more). As a side note, look up "A Mathematician's Lament" by Paul Lockhart.
> The with ever acclerating speed GPS killed our map reading abilities
As maps and even address systems killed our need for honing our instinctive positioning skill.
> smartphones eroded our memory by taking over address lists and phone numbers.
As did Gutenberg press of oral traditions. Also, before smartphones (and speaking as a guy who is still suspicious of smartphones, as they stand), we used paper address books for that, not memorize them all. And before automobiles came along, our address lists were a lot smaller.
> I could see eventually being connected to all the stored information of mankind all the time, and being able to store individual experiences cheaply will allow us to outsource most of our brain functions.
Kind of already happened. Google, Wikipedia, Facebook, Mechanical Turk. Unless you mean cybernetic cognitive integration with the cloud (shudder: not for atrophy fears though).
> But brain is not a factory where the released capacity will be put to some other use.
On what do you base that assertion on? The human brain is remarkably plastic. There is a lot of neuroscience research to back that up. The contrary is exactly what happens.
> Brain and muscle atrophy without usage. What we don't use, we lose, we don't redeploy.
So what parts of our brain have been documented to have atrophied so far? None, of course. Muscle is a different matter. I won't get into the reasons, but the mechanical revolution and the information revolution differ in certain respects.
We are cognitively consuming and processing more information than ever, not less. Whether this is mostly useful or simply information pollution is another matter. But we do think more of many different things now than we ever did. When the computers do our work, we take on more work... either to fully live, according to new expectations... or expect to be paid by showing value in tasks beyond the capability of computers. As computers progressively take on mundane and repetitive tasks, our tasks have become complex, not less.
You doubt you are one... but that is a Luddite argument.
Uh, answering my own post with a counter-argument, spying on your employees really isn't a very good way to accomplish this though. It creates distrust, bad morale, etc. I think there must be a better way to accomplish the same goal, of secrecy.
The issue is not distrust, bad morale, etc. Again, you are only looking at this from a mundane office perspective. That's just an issue of productivity. This is a much bigger issue than that. This is an inquisition on whistle blowers. It is an issue over the very soul for FDA and unlike your average office spying, is very much a headline article.
> but if it is interesting, someone will still leak it. That's why Apple announced the iPhone originally before getting FTC approval.
Your iPhone example doesn't hold here. The targeted personnel are responsible scientists communicating with proper whistle blowing channels regarding impropriety, not some lower-tier techies leaking shallow trinket tidbits for cash to rumor web sites.
> The FTC should do this.
No, they should not. They can certainly act if the leak question was on leaking to competitors and such. But these were issues of public concern and they were clearly told to not investigate... and then they went ahead and did it anyway.
"F.D.A. officials went to the inspector general at the Department of Health and Human Services to seek a criminal investigation into the possible leak, but they were turned down. The inspector general found that there was no evidence of a crime, noting that “matters of public safety” can legally be released to the news media."
> ...which sort of runs counter to the point
Perhaps they did have a clear directive to not shoot at down-and-unarmed targets.
> It seems to me that at the beginning of the video (~4:15), the guy peeping out from behind the wall is holding something long and thin aggressively. It looked that way briefly and that's when they think they saw an RPG and even shooting. However, when they swing around, the crowd or the said person do not realign themselves. They just seem busy with themselves. It hard to confuse a group of mostly unarmed people even if a couple were thought to have arms so closely grouped together as getting ready to fire an RPG at a gun ship. But then again, what do I know. Hind sight - 20/20.
> I guess he thought the guy in the van was giving aid to the enemy. Even then... if the gunner thought that the wounded insurgent should not be removed, a warning shot at a little distance would have communicated that quite well to the people from the van playing good Samaritans. But then he goes to open fire on them taking cover by the wall as well. So he must have assumed that they were insurgents as well even though there was no indication that these people were ever armed or hostile. I hope it caused a broad review of the engagement protocols.
Cython is really about writing C code in a Python like style to create Python extensions. This adds additional complexities in debugging (can't step through in your IDE seamlessly), building and distributing. The trade-off is acceptable in specific cases, but quite clunky otherwise. I am not eager to write anything substantial in it since tool support is not super. Cython is a neat hack. But a better example of using a statically typed native code for performance and a dynamically typed language for productivity is Java + Groovy. Ultimately however, the language choice boils down to it's eco-system, the point that Miguel was stressing. I pick the language based on whatever community has the libraries and experience for the kind of problem I am solving, even if the language and performance are not the best fit. Python is great for my scientific projects (lots of easy-to-use libraries, quick prototyping). But I am yet to see proper mature equivalents with tooling for things like ZK, and Eclipse RCP on the Python VM.
The point of "wax on wax off" is to teach our karate kid to react with instinctive speed, without needing to think. Quite appropriate for a fighting scenario where split second reactions are required. If you want to teach a student to be a human calculator replacement, then yes, that would be a great strategy. What a waste it is to waste a human potential to replace a device that costs less than a cheap meal... and can still outperform the said human. There are many learning methods to reach the stated goals. But there is much more to learning than dry goals, and every method choice has its own unique consequences.
What do you think are the chances that a mother in a *developing country* is English literate and understands computer terms - and what hacking means, no less? What's strange about a son spending all his time on computers when working on computers happens to be his educational background and his current job. To her, that's just a good boy who is working hard. Given the level of US outsourcing to China, is an occasional western face so unusual now? He might even be working for a company that might be a subsidiary to a US firm. All this does not translate to her being stupid either. Her competence would be better measured elsewhere.
This is a vulnerability, not an attack that has happened. Vulnerabilities can *potentially* lead to attacks. The title implies that it had already happened. AFAIK, testing vulnerabilities is not termed an attack; only when they are exploited by a malicious third party.
I don't know Australian law, but armed rebellion is not a "legitimate" (definition: complying with the law) choice anywhere. If you disagree, quote the law which says so. Armed rebellion may be be just, but never legitimate. The nice bit about a democratic government of laws is that you can use *legitimate* methods to have the laws and rulers changed, without having to resort to violence. If one cannot be bothered to campaign to the general public (or their representatives) to create enough public understanding to have the laws changed, that one is certainly unlikely to succeed through the use of violent force.
I disagree. It believe it is *mostly* the fault of systems. Nurses and Doctors will embrace technology if they feel it is working for them. It is the systems that don't adequately take into account the nature of the work that they do. Good technologies are viral. They don't need enforcement.
HL7 3.0 is XML. But not enough adopted it. And it's not all the fault of XML... really :-).
If they were big help, nurses would not be *working around* them.
http://scholar.google.com/scholar?q=Workarounds+to+Barcode+Medication+Administration+Systems
The trouble is... clinical care settings are not like business systems. Solutions that work in one place don't transfer over.
> That some of this has to do with the staff being largely of the 35+ crowd and the propensity of that crowd to not know how to use computers even remotely as well as, say, a 16 year old kid does right now.
That used to be a favorite argument to explain away poor clinical system adoption. But it does not hold true anymore. An average doctor today is at least as computer savvy as an average teenager. They may not use SMS, twitter or use facebook as much as the teens, but they certainly know how a computer works. This isn't the 90s when computers were optional in life.
> Computers take more work to use when you don't have a nice grasp on not only the software or function you're doing, but the regular logical deductions you make from repeated observation and experience.
Good clinical software should not need you to be an expert in computers... just that software... the one they use for several hours each day. And if it takes considerable experience to get up to speed... that's a usability problem... not a user problem.
One would wish. Doctors either spend more time with electronic systems than with paper systems... or if it is a good system... about the same time.
The current systems haven't made doctors more productive. There may be an exception or two though in select settings where considerable grant dollars were poured in to build a locally optimized system.
Building good clinical systems is hard.
Nope. The current Electronic Medical Record systems are not capable of exchanging information freely. There is no standard data format that everyone can exchange.
There are a few standards that can package data, but they are not adequately specified for seamless interoperability.
If you request records, they can print them out quickly for you though.
I watched the presentation. It was about time for Google to join the programming language space, but I was not impressed as much as I had been with other Google projects.
Go is fast: Sure. But compared to what? C and C++? They were never known to be fast compiling languages. Go is still a very simple language. So compilation speed is not impressive, relevant or novel *yet*. I recall from my Pascal (Delphi) days of how blazingly fast the compilations were when the language did not have a pre-processor or generics and had a more strict type system. Once Go gets generics and exceptions, we can see how well it compares to similar modern languages.
Go is safe: I somehow kept seeing OCaml in a C style syntax in all this despite Go not being functional (perhaps I am just sleepy :-) ). Better type system, garbage collection, optional typing, higher data types. Imperative Ocaml also only takes a minor performance hit compared to C despite providing a much safer language.
Concurrency: This could be something. The languages with built in support for this are somewhat obscure ATM (Erlang). Hopefully, Go will be more palatable to the mainstream.
Programming languages are finally more than grammars and compilers. Many excellent languages never make it to limelight. C and C++ continue to be first choice for system software despite the existence of several excellent "language" alternatives. Google brand may help Go with an early boost, but it will be the tools, libraries and the community that will have to deliver it; or we will just have another Java FXScript story in front of us.
> Oh and my eclipse application doesn't include SWT/JFace or any of that stuff. :)
Then your application probably isn't an RCP application but rather an OSGi application.
> How easy it is to show that you do not understand anything at all
And yet you show nothing more than hyperbolic exaggerations when I am talking about my *empirical* observations.
> who cares what size your installers are?
In Delphi days, software download sizes made or broke a shareware's success. In broadband era, download sizes are somewhat less important. But then you can extend the same argument to - computers are faster, RAM is cheaper and anything else.
> average Windows computer would need 32G of memory just to function
Why would you need more memory if apps are statically linked? When loading in-process DLLs, you still load multiple copies into memory, one into each application process. Things are different with out-process DLLs of course, but they are slower since marshaling needs to be done across process space. My statically linked apps took same or less memory space.
And I specifically noted that there is an argument to be made in using dynamic loading for unchanging and common components, just not everything and anything. Your arguments are entirely based on reflexive pre-conceptions, not experience.