Same as today: Actively considering every method that could be an alternative to providing IT support by hiring intelligent, well-educated and well-informed people. Because that would be unthinkable.
I don't think the business will be its own IT department. I do know that we in the business are today already hiring our own consultants to provide the IT support that we actually need.
Probably for the simple reason that aircraft are not built or kept in a basement. Suppliers of parts, engineering staff working on upgrades, and maintenance people are spread not just over the whole USA but over several countries and continents. Sooner or later, a subcontractor or a military engineer in Spain or Australia is going to need information on how to integrate their local piece of kit with the F/A-18. Deck crews on an aircraft carrier somewhere in the Indian ocean will have questions that need to be resolved by referring to the technical documentation and by conferring with engineers in the US. And because modern military aircraft are continuously upgraded, the distribution of technical documentation in paper form would be enormously burdensome.
Sometimes I feel that IT people get so obsessed over security that they forget that the internet is a great enabler as well, especially for international collaborations... Managed sensitive data is ALWAYS a trade-off between security and the ability to use the information productively. And commercial factors play a role as well, because access to design documentation will often be part of the negotiation in a foreign sales deal, valued because it enables the buyer to integrate the products of the local defense industry. In some ways sharing information on the internet, for access on a need-to-have basis, may be a more secure option than just handing over a complete copy.
Presumably not all the technical information is stored with the same level of security. I would assume that information relating e.g. the software of electronic warfare systems, radar and IFF is very highly classified, but information on external features or on basic weapon interfaces is more widely shared and easier to access. Some information will be "US eyes only" while other information would be shared not only with foreign users of the hardware but also with potential buyers.
What the Chinese have -- if this is not a baseless scare story -- will be much harder to determine.
The NSA's objections to the publication of "The Codebreakers", would not, by any chance, refer to some less than flattering comments on the performance of this semi-mythical organization? The bitter irony of all that is that, despite all the precautions, NSA has been involved in security breaches more spectacular and more damaging to the free world than any others in the Cold War except those of the atomic spies.
And on NSA's relations with Congress, This stratagem plays upon Congress' fear and ignorance., continuing a little further down with It is much easier not to bother with checking up on NSA. But it must be done. Otherwise the nation jeopardizes some of the very freedom that NSA exists to preserve.. I concede my quotes are form the 1996 revised edition, not the original 1967 edition. Still, it is hard to believe that anything in The Codebreakers can have been a technical risk to national security in 1967. A political risk to the people in the intelligence community, perhaps.
But here is a fascinating thought: America cryptography owns a lot to Elizabeth Wells Gallup, a high school principal from Michigan, who had "discovered" a secret message in the works of Shakespeare. A secret message of Bacon, of course. But Mrs. Gallup's theory attracted the attention of the rich George Fabyan, Fabyan hired Elizebeth Smith to help investigate it, and Elizebeth attracted (and married) William Friedman. Without that unlikely chain of events, William Friedman would never have entered cryptology, and the course of history could have been very different -- including the course of a few wars.
The paper on confocal system performance by Zucker and Price (Cytometry 44, 273-294, 2001) has a few useful data points and references, although it does not refer to two-photon systems. Maybe a later publication by them does.
I can't comment on the figures for two-photon microscopes, but on single-photon systems the ratio of the maximal power output from the objective to input beam power tends to be depressingly low, often much less than 0.1. There are fairly high losses in the microscope optics, especially in the highly corrected high-NA objectives used for confocal imaging. Of course there also is the problem of trying to achieve a fairly homogeneous illumination of the entrance pupil of the objective with a more-or-less Gaussian laser beam, and most solutions are wasteful in power.
A widefield deconvolution system doesn't really need a laser. Probably a lamp coupled by a liquid light guide is the better option for such a system. The excitation is not monochromatic but the illumination of the field is excellent.
Prices for this class of laboratory equipment are rarely put on paper, because you are expected to haggle. There usually is considerable margin for negotiation. Sometimes you can beat them down by as much as a third of the list price, although 10 to 20% is more common.
Why do you want to buy a Tsunami? It's a good laser system, but unless you have a specialization in optics or physics and are willing to spend a lot of time on tuning the system, it is better to spend your money on a laser with automatic tuning. (A Mai Tai, in Newport's case.) Performance is a bit less than a well-tuned Tsunami, but certainly good enough for most purposes, and the single box is more convenient than a Tsunami plus an external pump laser.
Anyway, femtosecond pulsed laser systems are somewhere in the quarter-million range, but the small solid-state lasers in most confocal microscopes can be had for an order of magnitude less.
A bit over $50,000 will buy you a good quality inverted research microscope with a basic set of options for widefield fluorescence imaging, with a sensitive camera and a few objective lenses. If you want to add options, $1,000 will pay for an extra set of optical filters, and roughly $5,000 for a single high-resolution objective. By adding more options you can spend $100,000 on a fairly standard microscope.
About $250,000 is roughly the ballpark for a confocal system, depending on exchange rate fluctuations. (Most manufacturers are German or Japanese, still reflecting the traditional location of the optical industries.) You would pay two or three times as much if you equip it for two-photon imaging or fancy techniques such as FCS or FLIM. Deconvolution systems are a bit cheaper (less hardware, more software) and they are also preferred for long-term experiments because they are more gently on the cells under study.
These are expensive tools, and besides most biologists don't understand microscopy nearly well enough to let them loose on it without assistance and supervision. The systems also need a suitable location (vibration free, stable temperature, moderate darkness) to work well. So at universities these systems tend to be in core facilities with a dedicated staff that keeps the instrument in shape, helps the users, and charges the departments back for their use.
In the long term, certainly yes, variants of disease that are are not recognized by the immune system or resistant to existing treatments will spread again, even from a small core, perhaps one created by accidental mutations. Influenza, of course, manages to do so every year, demonstrating how efficient viruses can be at playing this game. Experience with bacteria and parasites (malaria) is also rather discouraging.
However, how fast that occurs depends on quite a number of factors, including the ability of those mutant viruses to replicate, infect, and cause disease; and of course their geographical spread. Characteristic for many treatment-resistant mutants of HIV is that they are less virulent, because their optimal functioning as a virus has been compromised. Resistance mutations are known to all existing antiviral drugs, and it is only a matter of time before these resistant viruses will become more frequent, but meanwhile the drugs do increase the life expectancy of most patients by about thirty years. In reality, partial solutions are worth the effort. Imagine for a moment that you would have a vaccine that would largely eliminate HIV-1 subtype C, which accounts for over half the infections in the worlds poorest countries. That might be worth having, even if it is only a "short-term" solution and the virus will reconquer the lost terrain.
Unfortunately, in this case it is not clear from the information that I can access, what the practical implications of those 10% of viruses that escape the potential treatment are. The summary mentions 90% of HIV-1 strains, but actually the abstract in Science claims 90% of isolates. I can't access the article from here, but probably the authors identified the sequence of the binding site for their antibody, and then looked how frequently this occurs in a database of known HIV sequences, probably the Los Alamos database. That number doesn't tell you much about the viruses in which is does not occur.
Curated Computing sounds like a bad idea to me, because those third persons are making decisions without actually knowing my needs and habits as a user. Therefore less choice is very likely to lead to less relevance as well. This is the kind of computing you get in a big company where a central IT department sets policies and standards for everything, and it generally drives people who try to develop something new or display some creativity into raging fury -- even if the choices that are being made for you aren't braindead.
I think in the long term devices such as the iPad are going to be a success only if they can be personal enough. In theory a more convenient model could be one in which the systems learns from my behavior as a user and adapts accordingly. However, so far this tends to be based on a frequency-of-use approach, which is rather limiting. It isn't much help to the less skilled user, who might never be able to find the right options. And there are potential privacy considerations, if this is focused on monitoring the behavior of a single person.
A better mechanism could be a kind of 'Evolved Computing' working like this: I make myself a member of a peer group, based on common activities and common user interface preferences. I get a software package which may be inherently flexible but complex, perhaps too complex for the daily needs. Monitoring the group statistics allows the system's managers to de-emphasize some features, and highlight or offers others which might be attractive to this group. As a user, I can be presented with tools that other members in my peer group have found useful, and can adapt or reject. Another group may have another set of preferences, of course, but a particular group is offered the relevant subset in its user interface.
It's nothing really knew -- it's traditional user feedback, and the selection mechanism for iPod Apps or other extension packages. But it could be done smoother and more intelligently.
I think the most useful application of systems like this (not necessarily this one) would be in research to identify the causes of disease. There has been a long-standing suspicion that bacterial or viral infections at least contribute to many diseases, from asthma to depression, but this has been difficult and costly to investigate on a large scale. The most infamous case is chronic fatigue syndrome, long suspected to be the result of a viral infection.
Don't forget that it wasn't until 1982 that we figured out that stomach ulcers are mostly caused by bacteria, not by stress or acid food. The discovery that most cervical cancers are caused by a papillomavirus (of the same family as the viruses that cause warts) was a few years later. The impact on treatment and prevention of these diseases has been huge.
A tool that would permit clinicians to study the presence of infections, even at low levels, in relatively large numbers of patients might reveal surprising links.
Most modern structures are designed to have a finite life plus some safety margin. That's not just a trick to sell more cell phones and washing machines, it is normal engineering practice to get the right balance of cost. The FAA would even refuse to approve a wing design for an aircraft that did not have a predicted but finite life. If the design life is exceeded that can be regarded as a bonus, but often it is also considered a sign that the engineers made it too expensive / heavy / complicated.
I guess that a life of 2,500 days for a design goal of 90 days can be justified on the grounds that, given the cost of getting it there, a premature failure would have been a great disappointment. On the other hand, maybe we could have added some useful extra sensor to the Rover, reducing its lifespan to "only" 1,000 days but providing it with a means to avoid sand traps...
I think it was Edmund Burke who pointed out that "It isn't always wise to do what you have a right to do". However, the common law legal system doesn't operate that way. It tends to assume that it you don't exercise your rights, you implicitly abandon them.
This is what makes companies take legal action in such cases, even if they might have sympathy for the project itself. If they do not, it might be used as a precedent next time, when somebody has a project that is less beneficial to Nintendo.
So don't blame them -- write to your Congressman instead.
There is more to scientific serendipity than just luck. A degree of luck is certainly involved, as by definition the process involves observing something one did not plan to see. However, that is why scientists do research: If we only ever saw what we expected to see, then why bother?
But there is an important additional ingredient to it, and that is being able to actually absorb the unexpected and to be able to think of a reasonable explanation for it. The ability to give unexpected data a rational interpretation is crucial, because this is what protects good scientists from the cognitive dissonance that makes other close their eyes for the unexpected. Without interpretation, a surprising observation is just that; it may be a coincidence or an experimental error, and is often thrown out.
The most famous example is Alfred Wegener and his theory of continental drift. Mainstream science has been criticised a lot for its scepticism about Wegener's ideas, but Wegener failed to propose a credible mechanism for the motion of the continents -- the concept of plate tectonics arrived fifty years later. Without an explanation, the observation didn't convince, and Wegener was long dead when it was recognized that his intuitive idea had been right.
The reverse is also true, there is a real danger in theory without experimental observation. This is illustrated by the case of the mysterious "N-Rays" of a patriotic French scientist, who "discovered" them as a counterweight to the German Roentgen's discovery of X-Rays. The N-rays did not exist, but an otherwise very capable scientist also proved highly capable of seeing just what he wanted to see.
Yes for local systems, and that is using a wide definition of "developers" -- not just the professional software developers we employ, but also the people in "informatics" who are basically scientists who build or evaluate new software tools for data analysis, and the engineers who write software to control automated systems.
As far as I understand, this is against our own Very-Large-Company policy, and the threat of having administrator rights taken away is hovering constantly over our heads (now said to be a central IT goal by the end of 2010), but fortunately our local IT managers do understand that we need them. It wouldn't be worth the massive overhead of routing all requests for installation of new software over three different continents (I'm not kidding) and some people with difficult-to-replace skills would simply walk out if this was taken away from them.
There are always dire predictions of the disasters that will result by granting mere end-users administrator rights, but incidents are rare and usually easily resolved. Frankly, while it is true enough that many of the people with admin rights don't know that much about system administration, they actually know a lot more than the average helpdesk jockey who is in and out within a year, but can apparently be trusted with the powers to mess things up thoroughly...
Admin rights for servers we don't have on a personal basis, but on servers that are dedicated for specific purposes, some of us have access to service accounts that have administrator rights. If the server provides services to multiple people, the IT people are usually unwilling to grant that, and I find that understandable even if I don't entirely agree.
Yes, but that pre-supposes the ability to invent a new theory, because scientists are very unwilling to discard a theory if they have no alternative. After all, having no theoretical framework at all is very uncomfortable.
And there I do think that Dunbar makes a perfectly valid point: Any group of specialists who are all of the same mind is very bad a thinking "out of the box" and inventing a new theory. To be able to do that, you need a healthy mixture of different backgrounds, and enough dissent to stimulate the debate. Unfortunately scientists often assemble in excessively homogeneous groups, sometimes on their own initiative ("old boys network") and sometimes through deliberate but foolish policy ("center of excellence").
This is part of the reason why publishing and attending scientific congresses is a vital part of scientific activity. I've often noticed that in industry, this is regarded as a kind of bonus, a perk that allows scientists to travel to nice places. But is absolutely essential, even if that means talking things through with direct competitors.
That number of IT people sounds like about our own rate, around 30 people in a company with 600 employees. Of which about half a dozen are helpdesk people. In practice that is not enough for us.
Yes, it all depends on what you do. If your company only needs an off-the-shelf accounting system and MS Office, these 2 people should do fine. But we have half a dozen transactional database systems, a number of servers that are running heavyweight scientific data analysis, a commercial web interface which we need to keep running 24/7, very strong legal requirements to maintain privacy and data integrity, and almost daily requests to make changes to applications.
Our IT departement therefore includes programmers, database analysts, testers and validation staff, and of course various managers. These 24 extra people in practice boil down to only 1 or 2 skilled people to support every business-critical system, which means that there are serious gaps every time when people are on holiday or leave the company... We have to cover part of the gaps by allocating time from IT-skilled people in the business unit.
As for the helpdesk, simply giving everybody the same PC and the same image isn't a viable solution, although sadly our CIO is incompetent enough to think it would be. There is a rather wide gap in requirements between addressing the needs of a manager or his secretary, meeting the more demanding requirements or bio-informatician wrestling with gigabytes of sequencing data, and setting up a controller for a robot that could easily crack somebody's skull. Not to mention all the internal development of software tools.
However, in fairness, it also depends on how people are organized. Our management has discovered outsourcing, specialization, and centralization: In practice that leads to a bureaucratic merry-go-round in which a simple problem passes through a dozen different mailboxes before somebody does something about it. I've seen trouble tickets that bounced back and forth for two weeks before they landed on the desk of some IT manager, who honestly had to admit that he too couldn't figure out who was responsible for actually solving the problem.
My experience is from the user side, and I would strongly discourage uniforms for the IT helpdesk, in fact for any helpdesk.
The reality of life is that individuality matters, especially in a person from which one seeks help: People need to establish personal contact. And when it comes to essential tools such as computers, which can make our workday hell if they don't work properly, trust matters a lot. Putting your helpdesk people in uniform is the first step to make them uniformized drones. It will have a bad effect on employee morale, not just of the people who wear the uniforms, but also the people who call on them.
My advice is to fight it, tooth and claw. Instead promote rapprochement between the helpdesk people and the business by making sure that when people call, they get the same helpdesk person whenever possible. Don't over-emphasize central helpdesk lines and by all means avoid trouble ticket systems -- I've never seen one that didn't succeed in infuriating the end users.
The richer syntax means you can write code faster. But I am not so sure that that means that you can actually get you work done faster, although it of course depends on who you are and what you do. If you always work more or less in the same context, and that is not too complex, there will be no problem for you.
But my experience is that programmers spend half their time or more with trying to figure out what other programmers have done, and that they find that far more difficult and exhausting than writing their own code. That seems particularly true in an environment such as.NET, which comes with a rich set of libraries, including some that provide high levels of abstraction.
The problem with property syntax is not in the idea itself, but in its potential for abuse. As long as a.x = y is indeed a shorthand for a.setX(y), there is no problem. Dragons awake when somebody starts using it as a shorthand for a.addX(y). And yes, potentially somebody could write a.setX(y) and give it the functionality of a.addX(y), but the temptation to do so is much smaller.
But I admitted that I stretched it a bit when I quipped about properties being a bad idea. Operator overloading, however, almost certainly is.
I am not convinced that it is such a bad thing that Java-the-language is 'stagnated'. As language, Java was designed from the start to eliminate features that were, in the parlance of the day, "Considered Harmful". So yes, it was and is a bit restrictive. C# has a richer syntax, including "goto"... The richer syntax can be a plus because it often saves time in coding.
But creating code is what, 20% of the lifetime cost of a software package? And meanwhile C# provides the less disciplined programmer with plenty of opportunities to create write-only code. Never mind lambdas and closures --- I am not so sure that having properties in C# is a great idea, because their very purpose is to hide that code invocation happens. And I positively dislike the opt-out from declaring which exceptions a method throws. Exception handling is simply too important.
That your students where more "productive" after 16 weeks than CS majors is irrelevant. CS majors need to absorb quite a lot more of background information, which means that they inevitably will take a slower start. And, at the risk of upsetting everyone, in many places being a more productive programmer than a CS major is not that much of an achievement anyway. My own teachers managed to achieve that for many of us using dialects of PASCAL and, out of all possible creeping horrors, FORTRAN77.
That you students could write multimedia stuff perhaps illustrates the strength of the available programming environment and libraries, but not the quality or ease of use of the syntax of the language, or the need to invent a new programming language. It is technically possible -- if anyone would be mad enough to set himself to it -- to write a toolset and library that would allow students to quickly and conveniently write cross-platform multimedia games in FORTRAN77. That language doesn't have a particularly complex syntax.
And no doubt, given a trajectory of 16 weeks, this achievement also illustrates your own priorities as an educator. But if your standard of achievement computer education is generating multimedia games -- many aspire, but few are called to that job. And this risk of emphasizing this is that it reduces the activity of programming itself to a game. No doubt fun for the students, but do they really benefit?
I must wonder whether your students will know how to properly structure their code, how to handle possible error conditions and exceptions properly, and how to manage memory and resources. Will they be able to read the technical manual of an unfamiliar platform and get to grips with it, to figure out why a particular method call does not do what it is supposed to do, or to self-educate into another language than the sandbox you trained them in?
As for my knowledge of learning to program, I'll concede without hesitation that I am not a professional educator and unfamiliar with the literature on programming education. I have, however, far more experience that I would ever have liked to have in observing the gaps in the programming education of people, both IT professionals and amateurs, and the horrendous consequences these can have. And, incidentally, some experience of the difficulty of teaching people better strategies and habits. No doubt I have less practical experience of this than others -- I've seen only a few million dollars wasted, and I am sure others could faithfully claim orders of magnitude more.
So, although admittedly on thin ice where the how of educating people is concerned, I have pretty strong ideas on what people should learn. You fail to convince me that, if your students would apply for a job here, I should in any way regard it as an advantage that they were trained by you, or trained using rev.
Look at the tutorials; for example the File I/O code. I concede that to the average person without any programming education, this may look simpler than its C++ or Python counterpart, but is this syntax really simpler? I think not! On contrary this bit would be easier to code, with a rather lower risk of time-consuming compile errors, in many traditional languages.
I've seen enough attempts to "dumb down" computer languages for people whose computer programming examination only asked: "Which of the following three is not a valid BASIC keyword: (a) PRINT (b) GOTO (c) TERMINATE?" (I kid you not -- when I was at university, this was the level of knowledge expected from bachelor's students in, if I remember correctly, veterinary medicine.) Generally these languages did not succeed in making computer programming easier; they only succeeded in making it look superficially easier. The threshold appears lower for the uninitiated, but after the first three days there is no advantage and you're stuck with a stupid syntax.
The real choice, as far as I can tell, is between a "minimalist" design of a language which provides only those features that a developer is expected to really need, and a "maximalist" design that provides the extra features a programmer might like to have to save him some time and make code look more elegant. The pair Java and C#, despite their similarities in syntax, exemplify the contrasting approaches very well. Personally, having seen how even professional programmers can mess up their exception handling and mismanage their dependencies, I am firmly minimalist. Never mind time saved in writing code, that barely matters. What matters is time saved in code reviewing and debugging, and that is nearly always easier in a minimalist language.
That said, I hope there would be a market for a good, simple language suitable for automation purposes: Something that is suitable for anything from writing macros in a text editor to controlling a complicated robot, for which people now usually reinvent the wheel -- generally producing something roughly triangular with an off-set axle.
Yes, but is he supposed to know that the Royal Air Force has Air Marshals instead of Generals?
Anyway, his main point is an exaggeration. The RAF supported Whittle's work from about 1936 onwards, after having sponsored his engineering courses, first in the RAF, then at Cambridge. It was a mere trickle of money until the outbreak of war, but it was there. The scepticism about Whittle's work was fostered, ironically enough, by turbine specialists -- they did not believe a centrifugal compressor could be sufficiently efficient.
It is true that when the RAF decided to orders its first jet-powered aircraft, the experimental Gloster E.28/39, the German He 178 had already flown. But AFAIK they did not know that.
Technologically, the Japanese were not very advanced in the 1930s and 1940s. They were not as far behind as the Western powers had assumed, but they were behind nevertheless. However, they had that wonderful Japanese skill of achieving great results with very little. So if they lacked powerful aircraft engines, they compensated by making their aircraft lighter. There were downsides to that too, but given the available means, the results were very impressive.
That is why US commanders were surprised by the performance and agility of the A6M 'Zero'. The reports they received did not seem to make sense. They did not expect, and could not understand, that anyone would choose to go to war in a glorified sports aircraft, lightly built and lacking any armour. "An ideal sports aircraft for millionaires" was the verdict of US test pilots, when they got their hands onto one. And actually, they were right --- the vulnerability of the A6M cost the Japanese a lot of pilots they could not replace.
There is another lesson there. The Japanese knew their opponents could field superior technology, in almost any field, and would do it in superior numbers. They went to war nevertheless, in the belief that they could outsmart the US Navy and that sheer willpower and courage would bring victory. It didn't.
Sounds like you are making a strong, dedicated effort to keep systems running, but users are still unhappy, and they take it out on you. So perhaps it is time to do a sanity check: Assume for a moment that all existing systems would be 100% functional, without problems --- Would users be satisfied in that case?
If not, you can't win by doing the best possible maintenance or upgrade job. Perhaps the company should be thinking about some serious reappraisal of requirements and solutions.
Alternatively, bring your users into contact with the victims -- err, end users -- of a "professionally managed", large Corporate IT department. Then they may start to realize how lucky they are.
We are also more-or-less stuck with IE6 at work, because this is the "supported" browser of the IT department. Those of us who still retain adequate user rights to do it have installed Firefox -- and actually that is the unofficial advice we get from the people in the IT department if we report browser problems!
Very little of our internal applications doesn't run under Firefox. More is broken under IE6... Yet IT continues to install and support IE6 as default browser. (I don't know whether they are trying to fudge IE6 onto Windows Vista!)
Slashdot Mirror
Same as today: Actively considering every method that could be an alternative to providing IT support by hiring intelligent, well-educated and well-informed people. Because that would be unthinkable.
I don't think the business will be its own IT department. I do know that we in the business are today already hiring our own consultants to provide the IT support that we actually need.
Probably for the simple reason that aircraft are not built or kept in a basement. Suppliers of parts, engineering staff working on upgrades, and maintenance people are spread not just over the whole USA but over several countries and continents. Sooner or later, a subcontractor or a military engineer in Spain or Australia is going to need information on how to integrate their local piece of kit with the F/A-18. Deck crews on an aircraft carrier somewhere in the Indian ocean will have questions that need to be resolved by referring to the technical documentation and by conferring with engineers in the US. And because modern military aircraft are continuously upgraded, the distribution of technical documentation in paper form would be enormously burdensome. Sometimes I feel that IT people get so obsessed over security that they forget that the internet is a great enabler as well, especially for international collaborations... Managed sensitive data is ALWAYS a trade-off between security and the ability to use the information productively. And commercial factors play a role as well, because access to design documentation will often be part of the negotiation in a foreign sales deal, valued because it enables the buyer to integrate the products of the local defense industry. In some ways sharing information on the internet, for access on a need-to-have basis, may be a more secure option than just handing over a complete copy. Presumably not all the technical information is stored with the same level of security. I would assume that information relating e.g. the software of electronic warfare systems, radar and IFF is very highly classified, but information on external features or on basic weapon interfaces is more widely shared and easier to access. Some information will be "US eyes only" while other information would be shared not only with foreign users of the hardware but also with potential buyers. What the Chinese have -- if this is not a baseless scare story -- will be much harder to determine.
The NSA's objections to the publication of "The Codebreakers", would not, by any chance, refer to some less than flattering comments on the performance of this semi-mythical organization? The bitter irony of all that is that, despite all the precautions, NSA has been involved in security breaches more spectacular and more damaging to the free world than any others in the Cold War except those of the atomic spies.
And on NSA's relations with Congress, This stratagem plays upon Congress' fear and ignorance., continuing a little further down with It is much easier not to bother with checking up on NSA. But it must be done. Otherwise the nation jeopardizes some of the very freedom that NSA exists to preserve.. I concede my quotes are form the 1996 revised edition, not the original 1967 edition. Still, it is hard to believe that anything in The Codebreakers can have been a technical risk to national security in 1967. A political risk to the people in the intelligence community, perhaps.
But here is a fascinating thought: America cryptography owns a lot to Elizabeth Wells Gallup, a high school principal from Michigan, who had "discovered" a secret message in the works of Shakespeare. A secret message of Bacon, of course. But Mrs. Gallup's theory attracted the attention of the rich George Fabyan, Fabyan hired Elizebeth Smith to help investigate it, and Elizebeth attracted (and married) William Friedman. Without that unlikely chain of events, William Friedman would never have entered cryptology, and the course of history could have been very different -- including the course of a few wars.
The paper on confocal system performance by Zucker and Price (Cytometry 44, 273-294, 2001) has a few useful data points and references, although it does not refer to two-photon systems. Maybe a later publication by them does.
I can't comment on the figures for two-photon microscopes, but on single-photon systems the ratio of the maximal power output from the objective to input beam power tends to be depressingly low, often much less than 0.1. There are fairly high losses in the microscope optics, especially in the highly corrected high-NA objectives used for confocal imaging. Of course there also is the problem of trying to achieve a fairly homogeneous illumination of the entrance pupil of the objective with a more-or-less Gaussian laser beam, and most solutions are wasteful in power.
.
A widefield deconvolution system doesn't really need a laser. Probably a lamp coupled by a liquid light guide is the better option for such a system. The excitation is not monochromatic but the illumination of the field is excellent.
Prices for this class of laboratory equipment are rarely put on paper, because you are expected to haggle. There usually is considerable margin for negotiation. Sometimes you can beat them down by as much as a third of the list price, although 10 to 20% is more common.
Why do you want to buy a Tsunami? It's a good laser system, but unless you have a specialization in optics or physics and are willing to spend a lot of time on tuning the system, it is better to spend your money on a laser with automatic tuning. (A Mai Tai, in Newport's case.) Performance is a bit less than a well-tuned Tsunami, but certainly good enough for most purposes, and the single box is more convenient than a Tsunami plus an external pump laser.
Anyway, femtosecond pulsed laser systems are somewhere in the quarter-million range, but the small solid-state lasers in most confocal microscopes can be had for an order of magnitude less.
A bit over $50,000 will buy you a good quality inverted research microscope with a basic set of options for widefield fluorescence imaging, with a sensitive camera and a few objective lenses. If you want to add options, $1,000 will pay for an extra set of optical filters, and roughly $5,000 for a single high-resolution objective. By adding more options you can spend $100,000 on a fairly standard microscope.
About $250,000 is roughly the ballpark for a confocal system, depending on exchange rate fluctuations. (Most manufacturers are German or Japanese, still reflecting the traditional location of the optical industries.) You would pay two or three times as much if you equip it for two-photon imaging or fancy techniques such as FCS or FLIM. Deconvolution systems are a bit cheaper (less hardware, more software) and they are also preferred for long-term experiments because they are more gently on the cells under study.
These are expensive tools, and besides most biologists don't understand microscopy nearly well enough to let them loose on it without assistance and supervision. The systems also need a suitable location (vibration free, stable temperature, moderate darkness) to work well. So at universities these systems tend to be in core facilities with a dedicated staff that keeps the instrument in shape, helps the users, and charges the departments back for their use.
In the long term, certainly yes, variants of disease that are are not recognized by the immune system or resistant to existing treatments will spread again, even from a small core, perhaps one created by accidental mutations. Influenza, of course, manages to do so every year, demonstrating how efficient viruses can be at playing this game. Experience with bacteria and parasites (malaria) is also rather discouraging.
However, how fast that occurs depends on quite a number of factors, including the ability of those mutant viruses to replicate, infect, and cause disease; and of course their geographical spread. Characteristic for many treatment-resistant mutants of HIV is that they are less virulent, because their optimal functioning as a virus has been compromised. Resistance mutations are known to all existing antiviral drugs, and it is only a matter of time before these resistant viruses will become more frequent, but meanwhile the drugs do increase the life expectancy of most patients by about thirty years. In reality, partial solutions are worth the effort. Imagine for a moment that you would have a vaccine that would largely eliminate HIV-1 subtype C, which accounts for over half the infections in the worlds poorest countries. That might be worth having, even if it is only a "short-term" solution and the virus will reconquer the lost terrain.
Unfortunately, in this case it is not clear from the information that I can access, what the practical implications of those 10% of viruses that escape the potential treatment are. The summary mentions 90% of HIV-1 strains, but actually the abstract in Science claims 90% of isolates. I can't access the article from here, but probably the authors identified the sequence of the binding site for their antibody, and then looked how frequently this occurs in a database of known HIV sequences, probably the Los Alamos database. That number doesn't tell you much about the viruses in which is does not occur.
Surely half a monologue is a hemilogue?
If one must invent neologisms, then at least it should be done properly. It's the only thing people are going to remember from this 'research'.
Curated Computing sounds like a bad idea to me, because those third persons are making decisions without actually knowing my needs and habits as a user. Therefore less choice is very likely to lead to less relevance as well. This is the kind of computing you get in a big company where a central IT department sets policies and standards for everything, and it generally drives people who try to develop something new or display some creativity into raging fury -- even if the choices that are being made for you aren't braindead.
I think in the long term devices such as the iPad are going to be a success only if they can be personal enough. In theory a more convenient model could be one in which the systems learns from my behavior as a user and adapts accordingly. However, so far this tends to be based on a frequency-of-use approach, which is rather limiting. It isn't much help to the less skilled user, who might never be able to find the right options. And there are potential privacy considerations, if this is focused on monitoring the behavior of a single person.
A better mechanism could be a kind of 'Evolved Computing' working like this: I make myself a member of a peer group, based on common activities and common user interface preferences. I get a software package which may be inherently flexible but complex, perhaps too complex for the daily needs. Monitoring the group statistics allows the system's managers to de-emphasize some features, and highlight or offers others which might be attractive to this group. As a user, I can be presented with tools that other members in my peer group have found useful, and can adapt or reject. Another group may have another set of preferences, of course, but a particular group is offered the relevant subset in its user interface.
It's nothing really knew -- it's traditional user feedback, and the selection mechanism for iPod Apps or other extension packages. But it could be done smoother and more intelligently.
I think the most useful application of systems like this (not necessarily this one) would be in research to identify the causes of disease. There has been a long-standing suspicion that bacterial or viral infections at least contribute to many diseases, from asthma to depression, but this has been difficult and costly to investigate on a large scale. The most infamous case is chronic fatigue syndrome, long suspected to be the result of a viral infection. Don't forget that it wasn't until 1982 that we figured out that stomach ulcers are mostly caused by bacteria, not by stress or acid food. The discovery that most cervical cancers are caused by a papillomavirus (of the same family as the viruses that cause warts) was a few years later. The impact on treatment and prevention of these diseases has been huge. A tool that would permit clinicians to study the presence of infections, even at low levels, in relatively large numbers of patients might reveal surprising links.
Yes, or of over-engineering...
Most modern structures are designed to have a finite life plus some safety margin. That's not just a trick to sell more cell phones and washing machines, it is normal engineering practice to get the right balance of cost. The FAA would even refuse to approve a wing design for an aircraft that did not have a predicted but finite life. If the design life is exceeded that can be regarded as a bonus, but often it is also considered a sign that the engineers made it too expensive / heavy / complicated.
I guess that a life of 2,500 days for a design goal of 90 days can be justified on the grounds that, given the cost of getting it there, a premature failure would have been a great disappointment. On the other hand, maybe we could have added some useful extra sensor to the Rover, reducing its lifespan to "only" 1,000 days but providing it with a means to avoid sand traps...
I think it was Edmund Burke who pointed out that "It isn't always wise to do what you have a right to do". However, the common law legal system doesn't operate that way. It tends to assume that it you don't exercise your rights, you implicitly abandon them.
This is what makes companies take legal action in such cases, even if they might have sympathy for the project itself. If they do not, it might be used as a precedent next time, when somebody has a project that is less beneficial to Nintendo.
So don't blame them -- write to your Congressman instead.
There is more to scientific serendipity than just luck. A degree of luck is certainly involved, as by definition the process involves observing something one did not plan to see. However, that is why scientists do research: If we only ever saw what we expected to see, then why bother?
But there is an important additional ingredient to it, and that is being able to actually absorb the unexpected and to be able to think of a reasonable explanation for it. The ability to give unexpected data a rational interpretation is crucial, because this is what protects good scientists from the cognitive dissonance that makes other close their eyes for the unexpected. Without interpretation, a surprising observation is just that; it may be a coincidence or an experimental error, and is often thrown out.
The most famous example is Alfred Wegener and his theory of continental drift. Mainstream science has been criticised a lot for its scepticism about Wegener's ideas, but Wegener failed to propose a credible mechanism for the motion of the continents -- the concept of plate tectonics arrived fifty years later. Without an explanation, the observation didn't convince, and Wegener was long dead when it was recognized that his intuitive idea had been right.
The reverse is also true, there is a real danger in theory without experimental observation. This is illustrated by the case of the mysterious "N-Rays" of a patriotic French scientist, who "discovered" them as a counterweight to the German Roentgen's discovery of X-Rays. The N-rays did not exist, but an otherwise very capable scientist also proved highly capable of seeing just what he wanted to see.
Yes for local systems, and that is using a wide definition of "developers" -- not just the professional software developers we employ, but also the people in "informatics" who are basically scientists who build or evaluate new software tools for data analysis, and the engineers who write software to control automated systems.
As far as I understand, this is against our own Very-Large-Company policy, and the threat of having administrator rights taken away is hovering constantly over our heads (now said to be a central IT goal by the end of 2010), but fortunately our local IT managers do understand that we need them. It wouldn't be worth the massive overhead of routing all requests for installation of new software over three different continents (I'm not kidding) and some people with difficult-to-replace skills would simply walk out if this was taken away from them.
There are always dire predictions of the disasters that will result by granting mere end-users administrator rights, but incidents are rare and usually easily resolved. Frankly, while it is true enough that many of the people with admin rights don't know that much about system administration, they actually know a lot more than the average helpdesk jockey who is in and out within a year, but can apparently be trusted with the powers to mess things up thoroughly...
Admin rights for servers we don't have on a personal basis, but on servers that are dedicated for specific purposes, some of us have access to service accounts that have administrator rights. If the server provides services to multiple people, the IT people are usually unwilling to grant that, and I find that understandable even if I don't entirely agree.
Yes, but that pre-supposes the ability to invent a new theory, because scientists are very unwilling to discard a theory if they have no alternative. After all, having no theoretical framework at all is very uncomfortable.
And there I do think that Dunbar makes a perfectly valid point: Any group of specialists who are all of the same mind is very bad a thinking "out of the box" and inventing a new theory. To be able to do that, you need a healthy mixture of different backgrounds, and enough dissent to stimulate the debate. Unfortunately scientists often assemble in excessively homogeneous groups, sometimes on their own initiative ("old boys network") and sometimes through deliberate but foolish policy ("center of excellence").
This is part of the reason why publishing and attending scientific congresses is a vital part of scientific activity. I've often noticed that in industry, this is regarded as a kind of bonus, a perk that allows scientists to travel to nice places. But is absolutely essential, even if that means talking things through with direct competitors.
That number of IT people sounds like about our own rate, around 30 people in a company with 600 employees. Of which about half a dozen are helpdesk people. In practice that is not enough for us.
Yes, it all depends on what you do. If your company only needs an off-the-shelf accounting system and MS Office, these 2 people should do fine. But we have half a dozen transactional database systems, a number of servers that are running heavyweight scientific data analysis, a commercial web interface which we need to keep running 24/7, very strong legal requirements to maintain privacy and data integrity, and almost daily requests to make changes to applications.
Our IT departement therefore includes programmers, database analysts, testers and validation staff, and of course various managers. These 24 extra people in practice boil down to only 1 or 2 skilled people to support every business-critical system, which means that there are serious gaps every time when people are on holiday or leave the company... We have to cover part of the gaps by allocating time from IT-skilled people in the business unit.
As for the helpdesk, simply giving everybody the same PC and the same image isn't a viable solution, although sadly our CIO is incompetent enough to think it would be. There is a rather wide gap in requirements between addressing the needs of a manager or his secretary, meeting the more demanding requirements or bio-informatician wrestling with gigabytes of sequencing data, and setting up a controller for a robot that could easily crack somebody's skull. Not to mention all the internal development of software tools.
However, in fairness, it also depends on how people are organized. Our management has discovered outsourcing, specialization, and centralization: In practice that leads to a bureaucratic merry-go-round in which a simple problem passes through a dozen different mailboxes before somebody does something about it. I've seen trouble tickets that bounced back and forth for two weeks before they landed on the desk of some IT manager, who honestly had to admit that he too couldn't figure out who was responsible for actually solving the problem.
My experience is from the user side, and I would strongly discourage uniforms for the IT helpdesk, in fact for any helpdesk.
The reality of life is that individuality matters, especially in a person from which one seeks help: People need to establish personal contact. And when it comes to essential tools such as computers, which can make our workday hell if they don't work properly, trust matters a lot. Putting your helpdesk people in uniform is the first step to make them uniformized drones. It will have a bad effect on employee morale, not just of the people who wear the uniforms, but also the people who call on them.
My advice is to fight it, tooth and claw. Instead promote rapprochement between the helpdesk people and the business by making sure that when people call, they get the same helpdesk person whenever possible. Don't over-emphasize central helpdesk lines and by all means avoid trouble ticket systems -- I've never seen one that didn't succeed in infuriating the end users.
The richer syntax means you can write code faster. But I am not so sure that that means that you can actually get you work done faster, although it of course depends on who you are and what you do. If you always work more or less in the same context, and that is not too complex, there will be no problem for you.
But my experience is that programmers spend half their time or more with trying to figure out what other programmers have done, and that they find that far more difficult and exhausting than writing their own code. That seems particularly true in an environment such as .NET, which comes with a rich set of libraries, including some that provide high levels of abstraction.
The problem with property syntax is not in the idea itself, but in its potential for abuse. As long as a.x = y is indeed a shorthand for a.setX(y), there is no problem. Dragons awake when somebody starts using it as a shorthand for a.addX(y). And yes, potentially somebody could write a.setX(y) and give it the functionality of a.addX(y), but the temptation to do so is much smaller.
But I admitted that I stretched it a bit when I quipped about properties being a bad idea. Operator overloading, however, almost certainly is.
I am not convinced that it is such a bad thing that Java-the-language is 'stagnated'. As language, Java was designed from the start to eliminate features that were, in the parlance of the day, "Considered Harmful". So yes, it was and is a bit restrictive. C# has a richer syntax, including "goto"... The richer syntax can be a plus because it often saves time in coding.
But creating code is what, 20% of the lifetime cost of a software package? And meanwhile C# provides the less disciplined programmer with plenty of opportunities to create write-only code. Never mind lambdas and closures --- I am not so sure that having properties in C# is a great idea, because their very purpose is to hide that code invocation happens. And I positively dislike the opt-out from declaring which exceptions a method throws. Exception handling is simply too important.
I'm still not convinced at all.
That your students where more "productive" after 16 weeks than CS majors is irrelevant. CS majors need to absorb quite a lot more of background information, which means that they inevitably will take a slower start. And, at the risk of upsetting everyone, in many places being a more productive programmer than a CS major is not that much of an achievement anyway. My own teachers managed to achieve that for many of us using dialects of PASCAL and, out of all possible creeping horrors, FORTRAN77.
That you students could write multimedia stuff perhaps illustrates the strength of the available programming environment and libraries, but not the quality or ease of use of the syntax of the language, or the need to invent a new programming language. It is technically possible -- if anyone would be mad enough to set himself to it -- to write a toolset and library that would allow students to quickly and conveniently write cross-platform multimedia games in FORTRAN77. That language doesn't have a particularly complex syntax.
And no doubt, given a trajectory of 16 weeks, this achievement also illustrates your own priorities as an educator. But if your standard of achievement computer education is generating multimedia games -- many aspire, but few are called to that job. And this risk of emphasizing this is that it reduces the activity of programming itself to a game. No doubt fun for the students, but do they really benefit?
I must wonder whether your students will know how to properly structure their code, how to handle possible error conditions and exceptions properly, and how to manage memory and resources. Will they be able to read the technical manual of an unfamiliar platform and get to grips with it, to figure out why a particular method call does not do what it is supposed to do, or to self-educate into another language than the sandbox you trained them in?
As for my knowledge of learning to program, I'll concede without hesitation that I am not a professional educator and unfamiliar with the literature on programming education. I have, however, far more experience that I would ever have liked to have in observing the gaps in the programming education of people, both IT professionals and amateurs, and the horrendous consequences these can have. And, incidentally, some experience of the difficulty of teaching people better strategies and habits. No doubt I have less practical experience of this than others -- I've seen only a few million dollars wasted, and I am sure others could faithfully claim orders of magnitude more.
So, although admittedly on thin ice where the how of educating people is concerned, I have pretty strong ideas on what people should learn. You fail to convince me that, if your students would apply for a job here, I should in any way regard it as an advantage that they were trained by you, or trained using rev.
Look at the tutorials; for example the File I/O code. I concede that to the average person without any programming education, this may look simpler than its C++ or Python counterpart, but is this syntax really simpler? I think not! On contrary this bit would be easier to code, with a rather lower risk of time-consuming compile errors, in many traditional languages.
I've seen enough attempts to "dumb down" computer languages for people whose computer programming examination only asked: "Which of the following three is not a valid BASIC keyword: (a) PRINT (b) GOTO (c) TERMINATE?" (I kid you not -- when I was at university, this was the level of knowledge expected from bachelor's students in, if I remember correctly, veterinary medicine.) Generally these languages did not succeed in making computer programming easier; they only succeeded in making it look superficially easier. The threshold appears lower for the uninitiated, but after the first three days there is no advantage and you're stuck with a stupid syntax.
The real choice, as far as I can tell, is between a "minimalist" design of a language which provides only those features that a developer is expected to really need, and a "maximalist" design that provides the extra features a programmer might like to have to save him some time and make code look more elegant. The pair Java and C#, despite their similarities in syntax, exemplify the contrasting approaches very well. Personally, having seen how even professional programmers can mess up their exception handling and mismanage their dependencies, I am firmly minimalist. Never mind time saved in writing code, that barely matters. What matters is time saved in code reviewing and debugging, and that is nearly always easier in a minimalist language.
That said, I hope there would be a market for a good, simple language suitable for automation purposes: Something that is suitable for anything from writing macros in a text editor to controlling a complicated robot, for which people now usually reinvent the wheel -- generally producing something roughly triangular with an off-set axle.
Jet engines aren't much use to the army.
Yes, but is he supposed to know that the Royal Air Force has Air Marshals instead of Generals?
Anyway, his main point is an exaggeration. The RAF supported Whittle's work from about 1936 onwards, after having sponsored his engineering courses, first in the RAF, then at Cambridge. It was a mere trickle of money until the outbreak of war, but it was there. The scepticism about Whittle's work was fostered, ironically enough, by turbine specialists -- they did not believe a centrifugal compressor could be sufficiently efficient.
It is true that when the RAF decided to orders its first jet-powered aircraft, the experimental Gloster E.28/39, the German He 178 had already flown. But AFAIK they did not know that.
Technologically, the Japanese were not very advanced in the 1930s and 1940s. They were not as far behind as the Western powers had assumed, but they were behind nevertheless. However, they had that wonderful Japanese skill of achieving great results with very little. So if they lacked powerful aircraft engines, they compensated by making their aircraft lighter. There were downsides to that too, but given the available means, the results were very impressive.
That is why US commanders were surprised by the performance and agility of the A6M 'Zero'. The reports they received did not seem to make sense. They did not expect, and could not understand, that anyone would choose to go to war in a glorified sports aircraft, lightly built and lacking any armour. "An ideal sports aircraft for millionaires" was the verdict of US test pilots, when they got their hands onto one. And actually, they were right --- the vulnerability of the A6M cost the Japanese a lot of pilots they could not replace.
There is another lesson there. The Japanese knew their opponents could field superior technology, in almost any field, and would do it in superior numbers. They went to war nevertheless, in the belief that they could outsmart the US Navy and that sheer willpower and courage would bring victory. It didn't.
Sounds like you are making a strong, dedicated effort to keep systems running, but users are still unhappy, and they take it out on you. So perhaps it is time to do a sanity check: Assume for a moment that all existing systems would be 100% functional, without problems --- Would users be satisfied in that case?
If not, you can't win by doing the best possible maintenance or upgrade job. Perhaps the company should be thinking about some serious reappraisal of requirements and solutions.
Alternatively, bring your users into contact with the victims -- err, end users -- of a "professionally managed", large Corporate IT department. Then they may start to realize how lucky they are.
We are also more-or-less stuck with IE6 at work, because this is the "supported" browser of the IT department. Those of us who still retain adequate user rights to do it have installed Firefox -- and actually that is the unofficial advice we get from the people in the IT department if we report browser problems!
Very little of our internal applications doesn't run under Firefox. More is broken under IE6... Yet IT continues to install and support IE6 as default browser. (I don't know whether they are trying to fudge IE6 onto Windows Vista!)