To argue from my standpoint for a moment rather than Deusberg's; HIV is not simply "the virus which causes AIDS" though it seems to do that. HIV is relatively weak when it starts out. Only a minority of infected needlesticks lead to seroconversion.
Warning: I am not a virologist! The following is my best understanding of the issue, given for what it is worth. It may be wrong.
As far as I know, the way in which HIV interacts with the immune system is far from fully understood. To enter cells, HIV needs the CD4 receptor, but it also needs a co-receptor, and this can be CCR5 or CXCR4 (and possibly others). So HIV strains are labeled X4-tropic, R5-tropic, or dual, depending on their binding ability. An X4 strain targets different immune system cells than an R5 does, and with different effects. The X4 strains are very destructive.
In the early periods of infection, before AIDS develops, R5 viruses dominate. In the minority of people that have CCR5 receptors with mutations, the virus doesn't get a hold and they can remain free from disease for a long time. However, if R5 viruses are present in large numbers for a sufficient time, they evolve into the X4 viruses that are associated with the late stages of AIDS. To the best of my knowledge, it is still very unclear whether X4 strains can replicate only after R5 strains have damaged the immune system, whether the immune system actually selects for X4 viruses by becoming more effective on R5 strains, or whether X4 simply evolves after the virus has taken out all the R5 target cells.
The point is that mutations both in the genetic sequence of HIV itself, and of the receptors in the patient's cells, can be conclusively linked to infection, replication, and disease progression. Whether an infected person will develops AIDS and how long this will take is clearly dependent, not just on the presence of HIV, but also on the properties of the virus and on the properties of the receptors the virus uses. That indicates that HIV is far more than a marker virus.
HHV-8 on the other hand, is not predictive for AIDS, although it is for KS. The presence of this virus is far more likely in HIV infected people, perhaps only because it is easily suppressed by a healthy immune system, and perhaps because some of the proteins HIV codes for to assist its own lifecycle, are also useful for HHV-8.
If you use a different model for the evolution of infectious diseases, there is less need to describe HIV as coming from SIV.
The relation between HIV and SIV is rather more than an assumption or description: We have quantifiable evidence, in the form of the genetic sequences of isolates. Cladograms derived from these cannot really prove that one virus evolved from another (indeed a radical cladist would be opposed to the very notion that a cladogram can show ancestry) but they do indicate which viruses share common ancestors, what the likely nature of that ancestor was, how different SIV/HIV strains are associated with different primate hosts, and (with the many caveats of molecular biology) approximately when viruses jumped species.
The results indicate that SIV and HIV viruses are very closely related. Both HIV-1 and HIV-2 seem to have made the species jump several times, i.e. there are HIV-1 viruses that are more closely related to SIV strains than to other HIV viruses; and the same for HIV-2.
If HIV would have evolved from a harmless human virus, the cladogram would look very different. There would be a common ancestor human virus, separating the HIV tree from the SIV tree, and other human viruses (other descendants from the harmless ancestor) would sit on the same branch.
And if SIV would have developed from HIV, an HIV-like ancestor would be at the "root" of the tree, instead of an SIV-like ancestor. This is not the case. There is a common SIV-like ancestor, from which have originated several SIV viruses that have made the ju
On the Western blot test: The virus has parts that can be allowed to be highly variable without seriously affecting its activity, and parts that need to be conserved because otherwise it would be deficient and longer replicate. On an intact, infective virus the parts exposed to the outer world tend to be highly variable ones, while the conserved ones are kept buried inside.
Immunological tests are done on viruses that are broken up and no longer infective: Not only is this safer, but it allows the individual proteins to bind to their target sites, which is obviously impossible if they are bundled together in the virus. Nevertheless, the designers of the tests do have to take into account the variability of the virus, and AFAIK HIV testing kits are specific for regions.
There is not a shred of a rational reason to doubt that HIV causes AIDS, as it has been very convincingly demonstrated that inhibitors of HIV enzymes delay progression to AIDS and can suppress the disease symptions. That the early tests on AZT were not so convincing is irrelevant; we now know that if patients are given only AZT, the virus will become resistant to it in a matter of weeks.
That other viruses can also suppress the immune system is not surprising -- such a capability is obviously beneficial to a virus and would evolve naturally. HIV has an substantial and little understood arsenal of immune-suppressing tricks. And BTW immuno-deficiency this is by no means its only harmful effect, it also causes damage to the nervous system and the brain, in ways yet unclear.
As for the idea that HIV may have evolved from a less dangerous human virus: This is not impossible in theory, but there is strong evidence that HIV originates from SIV, and no evidence for another origin. Also, the co-evolution of a virus with its host tends to make it less and not more harmful to the host; this is the trend that was observed for syphilis and has recently been reported for HIV as well. It is not in the interest of a disease to kill its host.
You cannot use X-ray crystallography on the whole HIV particle, if only because there is too much variation in size and shape between individual viruses. You can never grow a regularly ordered crystal of it.
Cryo-electron tomography does not offer the resolution of X-Ray crystallography, but it can be used on single particles without the need to grow crystals, and it is also quite suitable for the study of particles the size of viruses. It also provides images that are fairly close to the body-temperature "biological condition".
X-Ray crystallography is a great technique, but its problem is that there are many proteins that don't crystallize properly. Some critical HIV proteins are notoriously hard to do and people have been working on them for years... And the tricks that are then used to get crystals, such as cutting out specific parts of proteins and/or adding stabilizing substances, result in reconstructions that are less than lifelike.
A method that has been used in the past with good results is to combine results from the two methods by fitting the X-Ray data in the CET model.
The biggest advance of the study is that it illuminates how the maturation process of the virus works.
HIV contains an enzyme, known as HIV protease, with related functionality to the proteases found in "biological" washing powders: It cuts other proteins in pieces. In HIV one of its functions is to cut a protein called gag, which helps the virus to assemble and leave a cell, into two others, known as matrix and capsid. The matrix supports the outer membrane of the virus, while the capsid surrounds the critical part of the virus that enters an infected cells, i.e. its genome and some other enzymes. The gag and matrix proteins form round shapes, but capsid assembles to a conical structure.
This maturation process (probably and mostly) happens after newly made viral particles leave cells, but before they can infect other cells. Apparently, if I understand the paper correctly, the capsid assembles from one end the virus and just stops to grow and seals when it reaches the other end.
Maturation is a potentially interesting drug target. But medical possibilities aside, the gag protein has interesting applications in biotechnology, as it forms a self-assembling nanostructure. You can already get commercially grown gag nanoparticles. The building blocks of HIV are potenial building blocks for the next generation of computers, strange as it may seem...
Frankly, the Conservatives have only themselves to blame.
Nobody forced them to associate with people who advocate Intelligent Design. Nobody forced them to reject the evidence for human-induced climate change out of hand. Nobody forced them to enter the ethical debate on stem cell research with fallacious arguments about the number of available cell lines. Nobody forced them to loan heaps of money to finance their current spending and at the same time make cuts on long-term investment. Nobody forced them to annoy military historians by going public with badly chosen and misleading analogies.
If highly educated people tend to be liberal, that is in no small part because modern conservatives have failed to provide an intellectually satisfying alternative. There is no rule that says that you have to be left-leaning to be intelligent, but conservatives have increasingly adopted views and positions that are simply very hard to accept for people with some insight and education. These days, you don't have to be stupid to be a conservative -- but it certainly helps.
How did this happen? Historically, there was no real shortage of bright, conservative thinkers. I don't know what set this trend in motion, but clearly it is self-reinforcing. When the conservatives began to profile themselves as the anti-intellectual, populist party of the gut feeling, they became increasingly unattractive to critical thinkers; and this allowed conservatism to become even more emotional and less intellectual, starting a vicious circle.
The way forward for Conservatives is to stop moaning about Liberial bias in media and academia, and clean up their own act. The Conservative case can often be presented much more satisfactorily than they bother to do now. Intellectual honesty, consistency and factual accuracy are not sins.
Well, as a great Republican once said "You may fool all the people some of the time, you can even fool some of the people all of the time, but you cannot fool all of the people all the time."
In this day and age, people who you can fool all of the time are called Republicans. And there are millions of them.
During WWII, US and British officials indeed opened letters and snooped into communications on a large scale. But the crucial difference is that they had the legal authority to do it, granted through the proper constitutional channels. Censorship regulations allowed government officials to open letters and read cable messages; there 1200 British censors in a hotel in Bermuda monitoring transatlantic communications.
Even within the USA, censors listened in to cable communications; they also opened millions of letters and labelled them as such. Regulation of communication went as far as banning all messages ordering the delivery of flowers, because such messages were seen as offering too many possibilties for secret communication. Indeed it was illegal to send any cable message that the censors would not be able to easily understand.
The current NSA listening operation is a very different matter. It is clearly illegal act, as the president has no authority to grant himself additional powers, certainly not if there are already laws that regulate these. There is no point in the illegality, as the regulations are flexible enough, and no purpose, for FBI agents have stated that little useful information is coming from it. It is just an exercise in the unbridled authoritarianism that characterizes this White House.
In the mind of George W. Bush, the US constitution has apparently been replaced by one simple line: Because of the war I have declared, I am allowed to do whatever I want.
Let us not exaggerate the problem. There is no such thing as an "authoritative" source; while some are indeed (much) better than others, all sources have their problems and faults. Articles in peer-reviewed journals are not necessarily free of error or reliable, as the recent problems around Dr. Hwang Woo-Suk clearly illustrates. And that particular work was published in Nature.
One of the fundamental qualities a student should develop is a critical sense towards published materials, no matter how highly recommended, and a tendency to think things over for himself. If handled with sufficient wisdom, Wikipedia may indeed be useful to the researcher, because it is a very accessible quick reference. However, he would be stupid to stop at only one reference.
Access to high-quality journals is not always easy. We are not all so fortunate to have good scientific libraries next door, or a large bunch of institutional subscriptions to e-journals. And if you have to order publications from other libraries, you may have to wait for weeks and/or pay a hefty price for them. I suppose China might be as bad as any other place.
1. Why aren't schools teaching this methodoly thoroughly?
From what I have seen -- as an outsider -- of programming education, it was so heavily theoretical that students simply didn't have the opportunity to generate many bugs, and therefore teachers were not confronted by them. Teaching was untainted by the practicalities and problems of real programming, so "obviously" there was no need to discuss methods to deal with them.
2. Someone developed a nice methodology, with a nice toolset and programming language, and got greedy and made it too expensive to acquire.
Perhaps, but formal, mathematical tools do not appeal to many people. Perhaps you would hope programmers to be different, but they are not; such formal rigour is congenial only to a minority. Most people prefer their logic to be fuzzier, more "humanities" and less "hard science". And QA departments, who love formal rigour, tend to focus exclusively on the user interfaces, not the internals of software, and to be fairly clueless anyway.
3. Programmers are asked to do the impossible. We (I include myself here) had to work with customers who don't know what they want, only give very fuzzy requirements (Praxis's customers, from their list, are different kind of animals, and they probably know better than most of the customers we had to work with), and even if we lay out the whole detailed plan in front of them, they still don't know what they want.
That is why I always have been of the opinion that is essential for the software team to co-develop the process, and not merely be the receivers of a set of requirements. Of course, that requires a substantial effort from both sides, and early involvement. It is usually difficult to achieve.
6. Customers (even custom-built projects customers) are a bunch of cheap folks, they would go to the least priced, no matter what. Praxis's customers are willing to pay 50% more for quality work, how many of your customers are willing to?
Well, this is probably not going to acceptable for a new version of Tetris, but it is different for air traffic control, or clinical diagnostic systems, or stock exchange software systems,... There are a lot of applications that really require high-reliability software.
Speaking as a customer, the real problem, IMHO, is that customers have no way to measure the quality of a software development team. Is the more expensive offer really better, or is it just more expensive? Even customers who are aware of reliability issues, usually cannot judge whether the use of tool X will really produce better software. And in fact the promise of the use of tool X by itself does not guarantuee better software -- the programmers might be sloppy nevertheless. So customers rely on word-of-mouth, gut feeling, and perhaps a basic grasp of what is considered fashionable methodology. They may do an audit, which will tell them mainly whether the paperwork is in good order.
If Praxis is able to charge 50% more and still find customers, that doesn't mean that they are 50% better, nor that the customers of Praxis understand software development methodologies. It only means that the reputation of Praxis is such that customers are willing to pay for the brand. Very much in the same way customers are willing to pay more for Mercedes, without knowing anything about automotive engineering.
From my understanding of this, this is not something you would be able to use in a conventional microscope. Perhaps one might use it in a confocal laser scanning system, but these things cost as much as a house...
I can imagine that people will try to integrate this with all kinds of advanced equipment; probably it is just a matter of time before we see publications on a 4-Pi STED microscope with negative index of refraction lenses. AFAIK the best setups ofthis kind are now limited to about 40nm resolution.
But all these nifty things are unlikely to leave the physics lab any time soon. (Although Leica sells a commercial "conventional" 4-Pi microscope; I haven't dared to ask for the price...)
On the other hand, there could be fantastic applications for such a system, especially in biology. This is resolution comparable to that can be achieved by cryo-TEM (transmission electron microscopy), but it could by feasible at room temperature. Viruses, for example, are below optical resolution for conventional microscopes, but could be reasonably well imaged by a system with 1 nm resolution.
Patents should apply to technology that requires years of research and/or lots of money and/or lots of people to develop (i.e. when there is definite financial risk to a company doing the R&D but unable to recover if the patent isn't awarded).
Your proposal would sweep independent inventors off the market. If this would be the standard, every single patent would be held by large corporations that can make substantial investments, for independent inventors with their own patents would have no other choice than to sell out.
Also, who is going to be the judge of this? The patent office? That would become a bureaucratic and legal nightmare, much worse than we have now.
Another aspect of the patent litmus test is to question whether the patent is ACTUALLY a unique innovation, or whether countless other people have the same idea and simply don't have the resources or time to go through the patent process.
In principle this provision is already present in patent law; to be patentable, an invention must not be obvious to the mythical person skilled in the art. The point is how this is legally defined. American courts, for reasons no doubt known to themselves, have consistently judged that nothing can be considered known or obvious if it isn't written down on paper. (This belief in the magic of the written word is very American.) This has drastically eroded the obviousness test, and that is the problem.
Also, why not insist that if the innovation has merit to benefit mankind, then the patent will only be awarded if it becomes public domain. I.e. a process to create medicine to save the world from AIDS or Cancer cannot be licensed or impose royalties on to those companies willing to make the product a reality.
Again, your proposal would largely eliminate smaller-scale innovation. There are a lot of small biotech or pharmaceutical companies that do advanced research, often with a high risk of failure, in the knowledge that they don't have the vast resources that are required to actually get a medicine approved and bring it on the market. They reckon that if they are successful, they can license it to a bigger player, who does have the resources for development, clinical trials, approval and marketing.
Your proposal would eliminate any pharmaceutical company that is too small to go it alone all the way; probably that would be any company with fewer than 500 employees or a year budget lower than $500 million. It would also create a virtually unsurmountable barrier for new startups, for you will find few investors that are willing to furnish this kind of money, knowing that the success rate for drug approval is only 20%. The net effect would be to reserve the market entirely to "Big Pharma." I have no prejudices against Big Pharma, I currently work for one of them, but as far as innovation is concerned this would be a Bad Idea.
Finally, a patent should only be awarded to a company or individual willing to make the innovation a reality.
What's the legal standard for willingness? Is it required to have already realized the invention? If not, is willingness then distinct from ability? If I am willing to realize the invention, but am unable to do so, and Big Corp. is able to built it, does Big Corp. then have the right to take my inventorship away from me? If I am willing to realize my idea for a starship capable of transgalactic travel, but cannot do it because nobody has invented the faster-than-light stardrive yet, do I have a patent?
Someone should patent the patent process, this will end this stupid industry once and for all.
Let us not forget why we have patents. We have patents because the alternative is secrecy; and that is even worse.
Things we need, IMHO, is:
A more demanding definition of the obviousness test. The pe
The goal of that philosophy is to drive the systems towards that ideal state. If you start dealing with every system as individual, then you simply run out of men and time trying to manage every system individually.
Your thinking is still IT-centric. But businesses do not exist to support their IT department; the IT department exists to provide optimal support to the business. If the operations do not allow standardisation to be achieved, so be it --- and the support still has to be there.
If allowed to run uncontrolled, the IT urge towards centralisation and standardisation will actually result in duplication of efforts: The formal IT department then only takes care of the standardised systems, because that is all it prepared itself to do, all it can do, and all it wants to do. Besides that, we will have other departments buying their own hardware, set up their own maintenance systems, and even set up parallel computer networks to ensure connectivity between non-standard systems, because that is the only way they can operate. And then, no doubt, the wheel will turn full circle again, spinning off a new departemental structure at every turn.
If that sounds far-fetched: We are already half-way there.
There is a reason why Unix scales far better than Windows. You don't need to manage individual desktops.
Yes and no. For years my primary working account was on Unix. While the user management of these systems was easier, the conflicting demands users put on a single system were always a problem. It was unavoidable that the computing-intensive teams purchased their own systems, both to take some of the load of the central machines, and to have optimised hardware.
When PC processing power became good enough to rival or better our DEC servers, the work shifted steadily to local PC hardware running Linux or Windows, and the central machines were kept as file and mail servers, or for the occasional use of software that had not been ported. It probably was more work to administer, but the increased flexibility was worth it, and upgrading or expanding became much easier, less expensive and less painful.
Personally, I regard the new, more organic structure of the IT systems, decentralized, more flexible, and far more capable of growth and renewal, as a definite advance. Yes, they may be less easily controllable; and that was one of the initial objections to the internet, too.
Oh, and you wouldn't need more powerful PCs.
You should not, but in practice my experience is that you do. Systems managed by a central IT group tend to be notably less performant, and their performance decreases steadily with number of maintenance cycles and new IT management systems that are introduced.
On the other hand, data would go onto the servers and end users would use thin clients (or easily replaced PCs with no local data). This allows for IT to service more users while maintaining far fewer real systems.
Obviously a good idea for IT, but what is in it for the users?
In practice network performance is not good enough for demanding applications, and network connectivity at home or in some distant hotel is of course much worse. So users often work on local disk, and tend to use the central file servers as safe repositories for data that they want to share with others or should be securely stored and back-upped.
There are also numerous places were a thin client is not an option, for example nearly every PC that needs to control another instrument. Specialized application software is often available only for one or two operating systems, and subject to expensive licensing if you want to run it from a server; which would be foolish if there are only one or two users of it anyway.
In which case, you either need a change of platform, or more people.
But the plain fact is no organization with a budget can afford the amount and particularly quality of computer support that end users demand.
Well, I agree that no central IT department is going to be able to provide this, but is that really the right way to do it? Knowledge is best located where it is needed, in the user group.
For our own projects, we don't try to provide the first line support ourselves. From the start of the project, we involve one or more of the target users as business representative. They get a say not only in defining the requirements, but also in evaluating possible external solutions, verifying the design, testing the pre-production systems, and scheduling releases. They also get thorough training.
Afterwards, its the representative user who provides training and first-line assistance for his or her peers, and user feedback for the development team. The users get training from someone who thoroughly understands the process, in language they understand; informal, but often much better than most IT people or engineers could provide. Of course, if they can't solve a problem, they will come to us.
It means that the manager of the business unit has to allow highly-qualified people to spend part of their time on projects that perhaps elsewhere, would be entirely engineering or IT business. However, the general consensus is that it is worth it.
I have read through some of the material at http://www.infrastructures.org/. I think that to a considerable extent, this is what our IT management group has already in place. Of the second bullet point list on the home page, I think they have about 80%.
It definitely has its strong points, but in practice, it is less ideal than it seems. Perhaps it makes life easier for the IT department, at least in theory it should, but it often fails to do this for the users.
I can see several reasons for this mismatch between theory and practice.
A first one, which is quite possible to overcome if there is enough management support, is that a much higher investment in infrastructure would be necessary to realize the potential of this ideal also for the users. We would need higher-end PCs, much more spacious file servers, and far better performing networks than we have now. It is hard the quantify the burden imposed by a centralized approach, but in my experience it is quite high, and you would need to take at least one step up in all hardware to compensate for it.
But IMHO the biggest problem is more fundamental. As a management philosophy, it assumes that all systems are more or less equivalent, have the similar configurations and the same tasks. This is quite possible to achieve if we think of IT systems as a separate world, not interacting with other systems; so that they can grow unconstrained to their ideal configuration. IT systems that are growing in some gentle Garden of Eden.
But in many real-world environments the IT patch is a sloping, rocky, irregular piece of ground. The IT systems there are interacting with external systems and parties, and constrained by this interaction. They have to adapt to the requirements of the process, which are often enough imposed from outside IT or even from outside the company. It usually is inevitable that there will be a mix of different hardware configurations, operating systems, software packages; systems that are often dedicated to a special purpose with a lack of alternative solutions. Even the personal computing needs of two users sharing the same office may be too different to be met by similar systems.
To function adequately, the IT management systems need to be much more flexible than ours are now. And they also need to be flexible to grow. The remote management systems of our IT department are powerful; but they still cannot cope with Windows XP.
Did _anyone_ bother to talk to IT about this? Or is your IT department so busy fighting fires that they don't have the time? How often has IT been given the option of actually participating in the decision making process?
It depends. The people who actually do the work in the IT department are flexible enough, and most of them know their business; if we seek a solution directly with them it usually works out. We need to give a very precise definition of the problem, because they often don't understand the purpose of a system -- they just maintain it.
If we seek an agreement with IT management, we are stonewalled with the rulebook, turf fights and even outright refusal to enter a discussion, until upper management takes an interest and overrules them.
The best solution we have found is to take the ownership of systems that are not to office standard, out of the hands of IT. If users want service on such a system, they have to come to us; we will pass a formal request to IT if that is appropriate, and else we do it ourselves. Of course you get fights on who owns the cable between an IT box and a non-IT box.
Actually, to set the standards, they would have to understand the business.
Ah, but that is the problem. IT sets standards without understanding the business, because it is isolated from it, and deals only with IT issues. To get a working system, you need to dissolve that barrier, and force IT people to be involved in the business.
Did you even read the GP? The guy told you why all sysadmins (in the US, anyway) are now forced to do all this crap; the auditors are forcing us to do it because of GLBA, SarBox, and HIPAA. We no longer have a choice.
Allow me to be somewhat skeptical. First, I am not entirely a stranger to regulation, and in my experience a common sense approach, combined with a search for the best solution, will in general succeed in providing a solution that is both acceptable to the authorities and workable. When IT people cite "compliance" is the sole justification for an action, I see that as evidence that (1) they do not actually have any good reason to do it; and (2) that they have not considered other goals and requirements in their choice of action.
After all sysadmins do not have the sole task of complying with regulations. They also have to provide users with systems that are suitable for the tasks that need to be done. If they comply with all regulations, but drive users insane with unworkable IT systems, they have still failed in their job. And if installing additional security systems requires more powerful computers and faster networks, then IT will have to factor that into its decisions, and if they still decide to go ahead with it, take the consequences on its budget.
Instead, we often see that IT announces a change for reasons of "compliance", and the user groups end up paying for it, either in loss of time or in purchase of extra hardware. Frankly, this attitude is only too typical for supporting departments: They shift hidden costs (less efficiency, higher administration, compensating investments) onto the back of the central groups. And the hidden cost of poorly functioning IT systems is very high, it can be as much as 10% of total wage costs.
The cost of maintaining unique hardware and software configuration is very high.
Everything is relative. For high-tech equipment, produced in small runs for specialized tasks, the cost of the associated computer and its maintenance is usually peanuts compared to the cost of keeping the rest of the system running. And even in relative terms, as a fraction of purchasing cost, you would typically pay three times as much for the maintenance of the non-IT systems.
So why don't you add that to your requirements list, and convey it to the IT department? Then let them discuss the tradeoffs between their goals and yours, until you come to a reasonable compromise.
Sounds very reasonable, but doesn't work very well in practice, if only because IT usually doesn't show much interest in other people's requirements -- certainly our team has never asked for them. But worse is that IT infrastructure groups are culturally inflexible, very much attached to rulebooks and standard procedures, while R&D is about seeking new solutions for new problems.
And to call a spade a spade, if these people where capable of grasping complex technical problems that stretch way outside the IT business, they probably would not be working in an IT service group. It isn't a particularly pleasant or rewarding job; much annoyance and very little gratitude.
To add insult to injury: The knowledge base of "real" IT engineers often seems too narrow to allow them to become creative. They understand IT, but It is never a goal in itself, but has to serve a purpose. A good system analyst and designer often has a very different background and has specialized in the IT side of it later. I think the concept of IT training itself is in need of reform.
This may involve switching software, and the costs involved in training.
In a pure IT world, that might work, but in our workplace the choice is often tied to many other choices, and involves much more than just switching software and retraining. And usually there are far fewer alternatives than the IT people assume.
Perhaps it would be an interesting experiment to have people responsible for their own systems. IT will just set the standards, and vet your systems regularly for compliance. If you aren't compliant, you are fined and shouted at.
I can easily see that that would not work at all. IT would still be busy setting standards without being directly involved in, or even understanding, the business. Only they would no longer do any real work. (Power without responsibility: The prerogative of the eunuch.) Therefore, at best they would be ignored and despised.
What we need to do is dismember IT as a department, leaving only the most essential tasks there, and integrate the IT people with the other teams. That way decisions, both on standards and on implementation, are whenever possible made by people who are in close contact with the company processes, and both the processes and the IT support will be better for it.
Actually, that was no big news, for the Soviet warplans have been known for years. It is just that journalists haven't noticed, or have already forgotten.
The plan was for a "pre-emptive strike" in case war was in the offing. It would executed as a "nuclear blitzkrieg". About 200 targets in Western Europe would be destroyed with tactical nuclear weapons, including communications centers and ports. The large WarPac mechanized forces would then advance; IIRC they expected to reach the Rhine in two weeks and the Pyrenees in six. (Tank crews are relatively well protected against radiation, if the air is properly filtered.)
I once talked to a researcher from Poland. He told me that during his army service, he had received training using a "nuclear simulator" which consisted out of a kind of cardboard doll-house and a flashlight. After the bomb fell, they were supposed to go out and spray the cows with water to remove the fall-out from their skin, and then move them to another field. He was a phycisist, and understood very well how ridiculous this was.
Sounds like typical modern marketing. Perhaps "Intel Inside" wasn't very meaningful, but it was a good slogan, that conveyed the feeling that Intel was a quality label. "Leap Ahead" is just awful, bland, undistinctive.
$2.5 billion on marketing, and there is a fair chance that when customers see "Leap Ahead" on a PC after that, they will think it is AMD's slogan, or that Leap is some new Chinese chip manufacturer.
Nil novi sub sole in the world of marketing. Have you noticed how in recent years, just about every small airliner has been renamed the Regional Jet?
If people would ask me the #1 reason to look for another job: The IT department.
Diverse and interesting work, nice colleagues, bosses who value my work highly, and a good salary... but, that IT department.
Every morning the thought of having to switch on that damn PC and struggle against it for the whole day... Need help on a complex Excel function? Press F1, then go for a cup of coffee.
Need to visit a supplier and give a presentation? Be prepared to apologize, repeatedly, until your machine has finally become functional. And yes, their IT manager will helpfully tell you that you should talk to your IT manager about system performance.
And the hardware of that laptop is decent enough. Just overloaded with bells, whistles, and security systems by IT, to the point where it barely worked.
End result? I have often enough taken work home to do it on my own PC, after hours. Nothing critical, certainly no patient data involved, but probably against the regulations. I owned a system with decent performance and the necessary software, which IT could not deliver for me on a reasonable time scale (although it was downloadable). And doing some work in my own time was far less annoying than having to do it on IT-installed systems.
Frankly, people in large companies often do not just think of the IT people as "bad guys", they think of them as hopeless. If they have an IT problem, their reaction is not: "Aargh, we will have to talk to those bastards in IT again." Their reaction is: "Well, it is an IT problem, so nothing will be done about it, and therefore we will just have to live with it. Asking IT for help is no use anyway."
If you think I sound harsh: Actually I often enough find myself defending the IT people against the criticisms of my colleagues, which are even harsher (and often less than fair).
I fully agree with the "typical user". I have yet to discover a large, centralized IT infrastructure departement that provides an adequate service, not to mention a good one.
Such departements is actually behave very much like worms. They infiltrate all systems and consume computer resources at a high rate, denying them to the people for whose use these systems actually are, with detrimental results to the business. A serious worm attack may cost a company a full working day; that is bad but after all it is only 0.5% or so of yearly productivity. Working on computers installed and maintained by a large IT infrastucture departement typically results in the loss about 20 minutes per day for all users; i.e. about 4% of productivity. And that is not taking into account all the administrative paperwork they require, or the health damage from computer-anger induced stress.
The fundamental reason for this, I suppose, is that the metrics IT uses as a measure of success tend to be completely unconnected with the goals of the business they have to support. I have no problem with security being high on the list of priorities; but usually performance appears to be near the bottom of that list --- if it is on it at all. And it is an unfortunate characteristic of IT infrastructure departements that they do not have to do any demanding work with the systems they install and manage; typically they use e-mail and some administrative software, but no heavy applications. In contrast, the departements that suffer the most (and complain the most) tend to be the ones that do: Programming, computer modelling, statistical analysis, datawarehousing.
Closely related to this is the tendency to standardisation, of hardware and software, that is exhibited by IT departements. That is just about tolerable in an office environment, although it results in a software environment that is a monoculture and very vulnerable to infection. (And usually at least a full generation behind the state of the art.) In an industrial or R&D environment the loss of flexibility that this entails is a major source of trouble, but an IT infrastructure group won't see this because it doesn't live in the same world. Characteristically, IT will allow only a few computer configurations, none of which is up to the job for a particular application (if only because the boards simply won't fit in), and one OS, which is not suitable either. IT will balk at spending an extra $2,000 for a more powerful PC, even though it is needed for the exploitation of an investment of $500,000.
Now, I admit that in any IT group there will be sensible people with whom a solution can be doctored out; unfortunately they are rarely encouraged by the culture of such a departement. The first problem is that such a team lives by regulations and often regards the rulebook as sufficient justification to do something, even if this blantantly conflicts with common sense. The second problem is that large teams encourage specialisation and task-sharing. It sounds innocent, but it actually means the responsibility for ordering, installing, delivering and connecting a PC will be split over at least four people, and at least eight for a server. Hence, the larger your IT group, the more you have to run around in circles to get the solution you need.
Of course it gets even worse when such large departements actually get involved in defining and executing software projects. They are almost guarantueed to organize a team that is too large, too distant from the reality of the processes it has to support, and conservative rather than creative. The typical result is a spectacular failure, a useless system delivered at a cost of millions of dollars.
Oh yes, I admit that there needs to be a central IT infrastructure group: For maintaining networks and servers, there is no other option. But such groups should be given power strictly on a need-to-have basis. All IT work that does not need to be done by a central group should be decentralized, in small teams that should
India has the know-how and infrastructure to produce drugs, and (equally important) to set up all the necessary administration to prove that they manufacture a quality product. (The approval of a new drug requires a file of a quarter of million pages or so; a copy of course needs considerably less, but the administrative burden still is nothing to laugh at.)
In central Africa that is not so evident; they lack the money, many educated people left their country, and the widespread corruption erodes the credibility of local manufacturers.
However, there is production of generic drugs in South-Africa, and an Indian company has started a join-venture in Uganda that should become operational in the middle of next year.
You are oversimplifying. Employees of pharmaceutical companies are human too, and leading AIDS researchers can hardly avoid being aware of the situation in Africa.
As far as I can see, most pharmaceutical companies are willing to supply antiretroviral treatment to patients in Africa at close to production cost, or license production at similar terms. Ethically it obviously the right thing to do. On the balance sheet there is no loss of market share because these patients could not afford to buy the drugs anyway. And crucially, if companies provide an affordable supply of HIV drugs they may make no profit, but still retain control and ownership. From a business perspective, this is far better than allowing someone else to produce them.
The biggest worry of the industry is the erosion of intellectual property by uncontrolled production of copies in the third world. In the pharmaceutical business, knowledge is money, and intellectual property determines the value of a company. Another concern is that drugs delivered to or produced in the third world at bottom prices could filter back to the rich countries and undermine their market there. It is one thing to give drugs to the poor, and quite another to give drugs to the rich. Someone needs to pay, or the companies will indeed fold.
The best way for pharmaceutical companies to prevent these things from happening is to take action themselves or actively cooperate with the efforts of others. And besides, the cost of supplying drugs to patients who cannot afford them is partially met by government funds, non-profit organisations and gifts from donors.
As disastrous as their situation is, AIDS patients in Africa at least have treatment options, and that is mainly because their disease is not only a third world disease. For if there were no patients in North America and Europe, there probably would be no drugs at all, or only very limited treatment options.
I think this is a more fundamental problem: How do we develop drugs or vaccines for typical tropical diseases? The patients cannot provide a return on investment. The half a billion dollars or so that are now required to develop a new drug are can be afforded by Western goverments, but their voters don't care.
I found a sample on the US customs and border protection site. The exact wording is:
Have you ever been or are you now involved in espionage or sabotage; or in terrorist activities; or genocide; or between 1933 and 1945 where you involved, in any way, in persecutions associated with Nazi Germany or its allies?
This by no means about Americans going about "their own business". What is involves is a finite and in fact scarce resource to which the USA or the citizens of the USA cannot claim exclusive ownership, to wit, the ability of the planet's ecosystem to absorb CO2 and other greenhouse gases. A resource of which they are using a disproportionally large share.
The logical way to approach this is as follows. First we estimate, as well as we can, the total capacity of the planet to absorb CO2 emissions. The estimate of the UK government is, I believe, that this is about 40% of the current emission level. Then we divide this by the number of people on the planet, and assign every person an equal share, as there is no imagineable reason why some people should be entitled to a larger share of the atmosphere than others. Finally, we organize a market for it: If you want to pollute more than your share, you will have to pay others to assign you a part of their share.
Of course, such a system would require the USA to reduce its greenhouse gas emissions by about 90% or so, or pay on a large scale for emission rights. Either way would work.
US reluctance to do something measurable about the greenhouse effect is more than a nuisance. To many nations it does, in effect, represent a Clear and Present Danger; for global climate change is one of the largest threats vulnerable nations face in the 21st century. In my opinion they would be fully justified in regarding US inaction over this as a valid casus belli and acting accordingly.
As for Britain staying out of the Euro, I have long reached the conclusion that Britain can no longer have a place within the EU if the EU wants to evolve into an effective organisation. The systematic institutional sabotage from London can no longer be tolerated, and the attitude of British politicians to the Euro -- which is, basically, that they will get in whenever the UK economy is on its knees and needs a boost -- is cowardly and deplorable. It would be much better if Britain was just the 51st state of the USA.
Slashdot Mirror
Warning: I am not a virologist! The following is my best understanding of the issue, given for what it is worth. It may be wrong.
As far as I know, the way in which HIV interacts with the immune system is far from fully understood. To enter cells, HIV needs the CD4 receptor, but it also needs a co-receptor, and this can be CCR5 or CXCR4 (and possibly others). So HIV strains are labeled X4-tropic, R5-tropic, or dual, depending on their binding ability. An X4 strain targets different immune system cells than an R5 does, and with different effects. The X4 strains are very destructive.
In the early periods of infection, before AIDS develops, R5 viruses dominate. In the minority of people that have CCR5 receptors with mutations, the virus doesn't get a hold and they can remain free from disease for a long time. However, if R5 viruses are present in large numbers for a sufficient time, they evolve into the X4 viruses that are associated with the late stages of AIDS. To the best of my knowledge, it is still very unclear whether X4 strains can replicate only after R5 strains have damaged the immune system, whether the immune system actually selects for X4 viruses by becoming more effective on R5 strains, or whether X4 simply evolves after the virus has taken out all the R5 target cells.
The point is that mutations both in the genetic sequence of HIV itself, and of the receptors in the patient's cells, can be conclusively linked to infection, replication, and disease progression. Whether an infected person will develops AIDS and how long this will take is clearly dependent, not just on the presence of HIV, but also on the properties of the virus and on the properties of the receptors the virus uses. That indicates that HIV is far more than a marker virus.
HHV-8 on the other hand, is not predictive for AIDS, although it is for KS. The presence of this virus is far more likely in HIV infected people, perhaps only because it is easily suppressed by a healthy immune system, and perhaps because some of the proteins HIV codes for to assist its own lifecycle, are also useful for HHV-8.
The relation between HIV and SIV is rather more than an assumption or description: We have quantifiable evidence, in the form of the genetic sequences of isolates. Cladograms derived from these cannot really prove that one virus evolved from another (indeed a radical cladist would be opposed to the very notion that a cladogram can show ancestry) but they do indicate which viruses share common ancestors, what the likely nature of that ancestor was, how different SIV/HIV strains are associated with different primate hosts, and (with the many caveats of molecular biology) approximately when viruses jumped species.
The results indicate that SIV and HIV viruses are very closely related. Both HIV-1 and HIV-2 seem to have made the species jump several times, i.e. there are HIV-1 viruses that are more closely related to SIV strains than to other HIV viruses; and the same for HIV-2.
If HIV would have evolved from a harmless human virus, the cladogram would look very different. There would be a common ancestor human virus, separating the HIV tree from the SIV tree, and other human viruses (other descendants from the harmless ancestor) would sit on the same branch.
And if SIV would have developed from HIV, an HIV-like ancestor would be at the "root" of the tree, instead of an SIV-like ancestor. This is not the case. There is a common SIV-like ancestor, from which have originated several SIV viruses that have made the ju
On the Western blot test: The virus has parts that can be allowed to be highly variable without seriously affecting its activity, and parts that need to be conserved because otherwise it would be deficient and longer replicate. On an intact, infective virus the parts exposed to the outer world tend to be highly variable ones, while the conserved ones are kept buried inside.
Immunological tests are done on viruses that are broken up and no longer infective: Not only is this safer, but it allows the individual proteins to bind to their target sites, which is obviously impossible if they are bundled together in the virus. Nevertheless, the designers of the tests do have to take into account the variability of the virus, and AFAIK HIV testing kits are specific for regions.
There is not a shred of a rational reason to doubt that HIV causes AIDS, as it has been very convincingly demonstrated that inhibitors of HIV enzymes delay progression to AIDS and can suppress the disease symptions. That the early tests on AZT were not so convincing is irrelevant; we now know that if patients are given only AZT, the virus will become resistant to it in a matter of weeks.
That other viruses can also suppress the immune system is not surprising -- such a capability is obviously beneficial to a virus and would evolve naturally. HIV has an substantial and little understood arsenal of immune-suppressing tricks. And BTW immuno-deficiency this is by no means its only harmful effect, it also causes damage to the nervous system and the brain, in ways yet unclear.
As for the idea that HIV may have evolved from a less dangerous human virus: This is not impossible in theory, but there is strong evidence that HIV originates from SIV, and no evidence for another origin. Also, the co-evolution of a virus with its host tends to make it less and not more harmful to the host; this is the trend that was observed for syphilis and has recently been reported for HIV as well. It is not in the interest of a disease to kill its host.
You cannot use X-ray crystallography on the whole HIV particle, if only because there is too much variation in size and shape between individual viruses. You can never grow a regularly ordered crystal of it.
Cryo-electron tomography does not offer the resolution of X-Ray crystallography, but it can be used on single particles without the need to grow crystals, and it is also quite suitable for the study of particles the size of viruses. It also provides images that are fairly close to the body-temperature "biological condition".
X-Ray crystallography is a great technique, but its problem is that there are many proteins that don't crystallize properly. Some critical HIV proteins are notoriously hard to do and people have been working on them for years... And the tricks that are then used to get crystals, such as cutting out specific parts of proteins and/or adding stabilizing substances, result in reconstructions that are less than lifelike.
A method that has been used in the past with good results is to combine results from the two methods by fitting the X-Ray data in the CET model.
The biggest advance of the study is that it illuminates how the maturation process of the virus works.
HIV contains an enzyme, known as HIV protease, with related functionality to the proteases found in "biological" washing powders: It cuts other proteins in pieces. In HIV one of its functions is to cut a protein called gag, which helps the virus to assemble and leave a cell, into two others, known as matrix and capsid. The matrix supports the outer membrane of the virus, while the capsid surrounds the critical part of the virus that enters an infected cells, i.e. its genome and some other enzymes. The gag and matrix proteins form round shapes, but capsid assembles to a conical structure.
This maturation process (probably and mostly) happens after newly made viral particles leave cells, but before they can infect other cells. Apparently, if I understand the paper correctly, the capsid assembles from one end the virus and just stops to grow and seals when it reaches the other end.
Maturation is a potentially interesting drug target. But medical possibilities aside, the gag protein has interesting applications in biotechnology, as it forms a self-assembling nanostructure. You can already get commercially grown gag nanoparticles. The building blocks of HIV are potenial building blocks for the next generation of computers, strange as it may seem...
Frankly, the Conservatives have only themselves to blame.
Nobody forced them to associate with people who advocate Intelligent Design. Nobody forced them to reject the evidence for human-induced climate change out of hand. Nobody forced them to enter the ethical debate on stem cell research with fallacious arguments about the number of available cell lines. Nobody forced them to loan heaps of money to finance their current spending and at the same time make cuts on long-term investment. Nobody forced them to annoy military historians by going public with badly chosen and misleading analogies.
If highly educated people tend to be liberal, that is in no small part because modern conservatives have failed to provide an intellectually satisfying alternative. There is no rule that says that you have to be left-leaning to be intelligent, but conservatives have increasingly adopted views and positions that are simply very hard to accept for people with some insight and education. These days, you don't have to be stupid to be a conservative -- but it certainly helps.
How did this happen? Historically, there was no real shortage of bright, conservative thinkers. I don't know what set this trend in motion, but clearly it is self-reinforcing. When the conservatives began to profile themselves as the anti-intellectual, populist party of the gut feeling, they became increasingly unattractive to critical thinkers; and this allowed conservatism to become even more emotional and less intellectual, starting a vicious circle.
The way forward for Conservatives is to stop moaning about Liberial bias in media and academia, and clean up their own act. The Conservative case can often be presented much more satisfactorily than they bother to do now. Intellectual honesty, consistency and factual accuracy are not sins.
Well, as a great Republican once said "You may fool all the people some of the time, you can even fool some of the people all of the time, but you cannot fool all of the people all the time."
In this day and age, people who you can fool all of the time are called Republicans. And there are millions of them.
During WWII, US and British officials indeed opened letters and snooped into communications on a large scale. But the crucial difference is that they had the legal authority to do it, granted through the proper constitutional channels. Censorship regulations allowed government officials to open letters and read cable messages; there 1200 British censors in a hotel in Bermuda monitoring transatlantic communications.
Even within the USA, censors listened in to cable communications; they also opened millions of letters and labelled them as such. Regulation of communication went as far as banning all messages ordering the delivery of flowers, because such messages were seen as offering too many possibilties for secret communication. Indeed it was illegal to send any cable message that the censors would not be able to easily understand.
The current NSA listening operation is a very different matter. It is clearly illegal act, as the president has no authority to grant himself additional powers, certainly not if there are already laws that regulate these. There is no point in the illegality, as the regulations are flexible enough, and no purpose, for FBI agents have stated that little useful information is coming from it. It is just an exercise in the unbridled authoritarianism that characterizes this White House.
In the mind of George W. Bush, the US constitution has apparently been replaced by one simple line: Because of the war I have declared, I am allowed to do whatever I want.
Let us not exaggerate the problem. There is no such thing as an "authoritative" source; while some are indeed (much) better than others, all sources have their problems and faults. Articles in peer-reviewed journals are not necessarily free of error or reliable, as the recent problems around Dr. Hwang Woo-Suk clearly illustrates. And that particular work was published in Nature.
One of the fundamental qualities a student should develop is a critical sense towards published materials, no matter how highly recommended, and a tendency to think things over for himself. If handled with sufficient wisdom, Wikipedia may indeed be useful to the researcher, because it is a very accessible quick reference. However, he would be stupid to stop at only one reference.
Access to high-quality journals is not always easy. We are not all so fortunate to have good scientific libraries next door, or a large bunch of institutional subscriptions to e-journals. And if you have to order publications from other libraries, you may have to wait for weeks and/or pay a hefty price for them. I suppose China might be as bad as any other place.
1. Why aren't schools teaching this methodoly thoroughly?
From what I have seen -- as an outsider -- of programming education, it was so heavily theoretical that students simply didn't have the opportunity to generate many bugs, and therefore teachers were not confronted by them. Teaching was untainted by the practicalities and problems of real programming, so "obviously" there was no need to discuss methods to deal with them.
2. Someone developed a nice methodology, with a nice toolset and programming language, and got greedy and made it too expensive to acquire.
Perhaps, but formal, mathematical tools do not appeal to many people. Perhaps you would hope programmers to be different, but they are not; such formal rigour is congenial only to a minority. Most people prefer their logic to be fuzzier, more "humanities" and less "hard science". And QA departments, who love formal rigour, tend to focus exclusively on the user interfaces, not the internals of software, and to be fairly clueless anyway.
3. Programmers are asked to do the impossible. We (I include myself here) had to work with customers who don't know what they want, only give very fuzzy requirements (Praxis's customers, from their list, are different kind of animals, and they probably know better than most of the customers we had to work with), and even if we lay out the whole detailed plan in front of them, they still don't know what they want.
That is why I always have been of the opinion that is essential for the software team to co-develop the process, and not merely be the receivers of a set of requirements. Of course, that requires a substantial effort from both sides, and early involvement. It is usually difficult to achieve.
6. Customers (even custom-built projects customers) are a bunch of cheap folks, they would go to the least priced, no matter what. Praxis's customers are willing to pay 50% more for quality work, how many of your customers are willing to?
Well, this is probably not going to acceptable for a new version of Tetris, but it is different for air traffic control, or clinical diagnostic systems, or stock exchange software systems, ... There are a lot of applications that really require high-reliability software.
Speaking as a customer, the real problem, IMHO, is that customers have no way to measure the quality of a software development team. Is the more expensive offer really better, or is it just more expensive? Even customers who are aware of reliability issues, usually cannot judge whether the use of tool X will really produce better software. And in fact the promise of the use of tool X by itself does not guarantuee better software -- the programmers might be sloppy nevertheless. So customers rely on word-of-mouth, gut feeling, and perhaps a basic grasp of what is considered fashionable methodology. They may do an audit, which will tell them mainly whether the paperwork is in good order.
If Praxis is able to charge 50% more and still find customers, that doesn't mean that they are 50% better, nor that the customers of Praxis understand software development methodologies. It only means that the reputation of Praxis is such that customers are willing to pay for the brand. Very much in the same way customers are willing to pay more for Mercedes, without knowing anything about automotive engineering.
From my understanding of this, this is not something you would be able to use in a conventional microscope. Perhaps one might use it in a confocal laser scanning system, but these things cost as much as a house...
I can imagine that people will try to integrate this with all kinds of advanced equipment; probably it is just a matter of time before we see publications on a 4-Pi STED microscope with negative index of refraction lenses. AFAIK the best setups ofthis kind are now limited to about 40nm resolution.
But all these nifty things are unlikely to leave the physics lab any time soon. (Although Leica sells a commercial "conventional" 4-Pi microscope; I haven't dared to ask for the price...)
On the other hand, there could be fantastic applications for such a system, especially in biology. This is resolution comparable to that can be achieved by cryo-TEM (transmission electron microscopy), but it could by feasible at room temperature. Viruses, for example, are below optical resolution for conventional microscopes, but could be reasonably well imaged by a system with 1 nm resolution.
Your proposal would sweep independent inventors off the market. If this would be the standard, every single patent would be held by large corporations that can make substantial investments, for independent inventors with their own patents would have no other choice than to sell out.
Also, who is going to be the judge of this? The patent office? That would become a bureaucratic and legal nightmare, much worse than we have now.
In principle this provision is already present in patent law; to be patentable, an invention must not be obvious to the mythical person skilled in the art. The point is how this is legally defined. American courts, for reasons no doubt known to themselves, have consistently judged that nothing can be considered known or obvious if it isn't written down on paper. (This belief in the magic of the written word is very American.) This has drastically eroded the obviousness test, and that is the problem.
Again, your proposal would largely eliminate smaller-scale innovation. There are a lot of small biotech or pharmaceutical companies that do advanced research, often with a high risk of failure, in the knowledge that they don't have the vast resources that are required to actually get a medicine approved and bring it on the market. They reckon that if they are successful, they can license it to a bigger player, who does have the resources for development, clinical trials, approval and marketing.
Your proposal would eliminate any pharmaceutical company that is too small to go it alone all the way; probably that would be any company with fewer than 500 employees or a year budget lower than $500 million. It would also create a virtually unsurmountable barrier for new startups, for you will find few investors that are willing to furnish this kind of money, knowing that the success rate for drug approval is only 20%. The net effect would be to reserve the market entirely to "Big Pharma." I have no prejudices against Big Pharma, I currently work for one of them, but as far as innovation is concerned this would be a Bad Idea.
What's the legal standard for willingness? Is it required to have already realized the invention? If not, is willingness then distinct from ability? If I am willing to realize the invention, but am unable to do so, and Big Corp. is able to built it, does Big Corp. then have the right to take my inventorship away from me? If I am willing to realize my idea for a starship capable of transgalactic travel, but cannot do it because nobody has invented the faster-than-light stardrive yet, do I have a patent?
Let us not forget why we have patents. We have patents because the alternative is secrecy; and that is even worse.
Things we need, IMHO, is:
Your thinking is still IT-centric. But businesses do not exist to support their IT department; the IT department exists to provide optimal support to the business. If the operations do not allow standardisation to be achieved, so be it --- and the support still has to be there.
If allowed to run uncontrolled, the IT urge towards centralisation and standardisation will actually result in duplication of efforts: The formal IT department then only takes care of the standardised systems, because that is all it prepared itself to do, all it can do, and all it wants to do. Besides that, we will have other departments buying their own hardware, set up their own maintenance systems, and even set up parallel computer networks to ensure connectivity between non-standard systems, because that is the only way they can operate. And then, no doubt, the wheel will turn full circle again, spinning off a new departemental structure at every turn.
If that sounds far-fetched: We are already half-way there.
Yes and no. For years my primary working account was on Unix. While the user management of these systems was easier, the conflicting demands users put on a single system were always a problem. It was unavoidable that the computing-intensive teams purchased their own systems, both to take some of the load of the central machines, and to have optimised hardware.
When PC processing power became good enough to rival or better our DEC servers, the work shifted steadily to local PC hardware running Linux or Windows, and the central machines were kept as file and mail servers, or for the occasional use of software that had not been ported. It probably was more work to administer, but the increased flexibility was worth it, and upgrading or expanding became much easier, less expensive and less painful.
Personally, I regard the new, more organic structure of the IT systems, decentralized, more flexible, and far more capable of growth and renewal, as a definite advance. Yes, they may be less easily controllable; and that was one of the initial objections to the internet, too.
You should not, but in practice my experience is that you do. Systems managed by a central IT group tend to be notably less performant, and their performance decreases steadily with number of maintenance cycles and new IT management systems that are introduced.
Obviously a good idea for IT, but what is in it for the users?
In practice network performance is not good enough for demanding applications, and network connectivity at home or in some distant hotel is of course much worse. So users often work on local disk, and tend to use the central file servers as safe repositories for data that they want to share with others or should be securely stored and back-upped.
There are also numerous places were a thin client is not an option, for example nearly every PC that needs to control another instrument. Specialized application software is often available only for one or two operating systems, and subject to expensive licensing if you want to run it from a server; which would be foolish if there are only one or two users of it anyway.
What we need, I think, is a system
Well, I agree that no central IT department is going to be able to provide this, but is that really the right way to do it? Knowledge is best located where it is needed, in the user group.
For our own projects, we don't try to provide the first line support ourselves. From the start of the project, we involve one or more of the target users as business representative. They get a say not only in defining the requirements, but also in evaluating possible external solutions, verifying the design, testing the pre-production systems, and scheduling releases. They also get thorough training.
Afterwards, its the representative user who provides training and first-line assistance for his or her peers, and user feedback for the development team. The users get training from someone who thoroughly understands the process, in language they understand; informal, but often much better than most IT people or engineers could provide. Of course, if they can't solve a problem, they will come to us.
It means that the manager of the business unit has to allow highly-qualified people to spend part of their time on projects that perhaps elsewhere, would be entirely engineering or IT business. However, the general consensus is that it is worth it.
I have read through some of the material at http://www.infrastructures.org/. I think that to a considerable extent, this is what our IT management group has already in place. Of the second bullet point list on the home page, I think they have about 80%.
It definitely has its strong points, but in practice, it is less ideal than it seems. Perhaps it makes life easier for the IT department, at least in theory it should, but it often fails to do this for the users.
I can see several reasons for this mismatch between theory and practice.
A first one, which is quite possible to overcome if there is enough management support, is that a much higher investment in infrastructure would be necessary to realize the potential of this ideal also for the users. We would need higher-end PCs, much more spacious file servers, and far better performing networks than we have now. It is hard the quantify the burden imposed by a centralized approach, but in my experience it is quite high, and you would need to take at least one step up in all hardware to compensate for it.
But IMHO the biggest problem is more fundamental. As a management philosophy, it assumes that all systems are more or less equivalent, have the similar configurations and the same tasks. This is quite possible to achieve if we think of IT systems as a separate world, not interacting with other systems; so that they can grow unconstrained to their ideal configuration. IT systems that are growing in some gentle Garden of Eden.
But in many real-world environments the IT patch is a sloping, rocky, irregular piece of ground. The IT systems there are interacting with external systems and parties, and constrained by this interaction. They have to adapt to the requirements of the process, which are often enough imposed from outside IT or even from outside the company. It usually is inevitable that there will be a mix of different hardware configurations, operating systems, software packages; systems that are often dedicated to a special purpose with a lack of alternative solutions. Even the personal computing needs of two users sharing the same office may be too different to be met by similar systems.
To function adequately, the IT management systems need to be much more flexible than ours are now. And they also need to be flexible to grow. The remote management systems of our IT department are powerful; but they still cannot cope with Windows XP.
It depends. The people who actually do the work in the IT department are flexible enough, and most of them know their business; if we seek a solution directly with them it usually works out. We need to give a very precise definition of the problem, because they often don't understand the purpose of a system -- they just maintain it.
If we seek an agreement with IT management, we are stonewalled with the rulebook, turf fights and even outright refusal to enter a discussion, until upper management takes an interest and overrules them.
The best solution we have found is to take the ownership of systems that are not to office standard, out of the hands of IT. If users want service on such a system, they have to come to us; we will pass a formal request to IT if that is appropriate, and else we do it ourselves. Of course you get fights on who owns the cable between an IT box and a non-IT box.
Ah, but that is the problem. IT sets standards without understanding the business, because it is isolated from it, and deals only with IT issues. To get a working system, you need to dissolve that barrier, and force IT people to be involved in the business.
Allow me to be somewhat skeptical. First, I am not entirely a stranger to regulation, and in my experience a common sense approach, combined with a search for the best solution, will in general succeed in providing a solution that is both acceptable to the authorities and workable. When IT people cite "compliance" is the sole justification for an action, I see that as evidence that (1) they do not actually have any good reason to do it; and (2) that they have not considered other goals and requirements in their choice of action.
After all sysadmins do not have the sole task of complying with regulations. They also have to provide users with systems that are suitable for the tasks that need to be done. If they comply with all regulations, but drive users insane with unworkable IT systems, they have still failed in their job. And if installing additional security systems requires more powerful computers and faster networks, then IT will have to factor that into its decisions, and if they still decide to go ahead with it, take the consequences on its budget.
Instead, we often see that IT announces a change for reasons of "compliance", and the user groups end up paying for it, either in loss of time or in purchase of extra hardware. Frankly, this attitude is only too typical for supporting departments: They shift hidden costs (less efficiency, higher administration, compensating investments) onto the back of the central groups. And the hidden cost of poorly functioning IT systems is very high, it can be as much as 10% of total wage costs.
The cost of maintaining unique hardware and software configuration is very high.
Everything is relative. For high-tech equipment, produced in small runs for specialized tasks, the cost of the associated computer and its maintenance is usually peanuts compared to the cost of keeping the rest of the system running. And even in relative terms, as a fraction of purchasing cost, you would typically pay three times as much for the maintenance of the non-IT systems.
So why don't you add that to your requirements list, and convey it to the IT department? Then let them discuss the tradeoffs between their goals and yours, until you come to a reasonable compromise.
Sounds very reasonable, but doesn't work very well in practice, if only because IT usually doesn't show much interest in other people's requirements -- certainly our team has never asked for them. But worse is that IT infrastructure groups are culturally inflexible, very much attached to rulebooks and standard procedures, while R&D is about seeking new solutions for new problems.
And to call a spade a spade, if these people where capable of grasping complex technical problems that stretch way outside the IT business, they probably would not be working in an IT service group. It isn't a particularly pleasant or rewarding job; much annoyance and very little gratitude.
To add insult to injury: The knowledge base of "real" IT engineers often seems too narrow to allow them to become creative. They understand IT, but It is never a goal in itself, but has to serve a purpose. A good system analyst and designer often has a very different background and has specialized in the IT side of it later. I think the concept of IT training itself is in need of reform.
This may involve switching software, and the costs involved in training.
In a pure IT world, that might work, but in our workplace the choice is often tied to many other choices, and involves much more than just switching software and retraining. And usually there are far fewer alternatives than the IT people assume.
Perhaps it would be an interesting experiment to have people responsible for their own systems. IT will just set the standards, and vet your systems regularly for compliance. If you aren't compliant, you are fined and shouted at.
I can easily see that that would not work at all. IT would still be busy setting standards without being directly involved in, or even understanding, the business. Only they would no longer do any real work. (Power without responsibility: The prerogative of the eunuch.) Therefore, at best they would be ignored and despised.
What we need to do is dismember IT as a department, leaving only the most essential tasks there, and integrate the IT people with the other teams. That way decisions, both on standards and on implementation, are whenever possible made by people who are in close contact with the company processes, and both the processes and the IT support will be better for it.
Actually, that was no big news, for the Soviet warplans have been known for years. It is just that journalists haven't noticed, or have already forgotten.
The plan was for a "pre-emptive strike" in case war was in the offing. It would executed as a "nuclear blitzkrieg". About 200 targets in Western Europe would be destroyed with tactical nuclear weapons, including communications centers and ports. The large WarPac mechanized forces would then advance; IIRC they expected to reach the Rhine in two weeks and the Pyrenees in six. (Tank crews are relatively well protected against radiation, if the air is properly filtered.)
I once talked to a researcher from Poland. He told me that during his army service, he had received training using a "nuclear simulator" which consisted out of a kind of cardboard doll-house and a flashlight. After the bomb fell, they were supposed to go out and spray the cows with water to remove the fall-out from their skin, and then move them to another field. He was a phycisist, and understood very well how ridiculous this was.
Sounds like typical modern marketing. Perhaps "Intel Inside" wasn't very meaningful, but it was a good slogan, that conveyed the feeling that Intel was a quality label. "Leap Ahead" is just awful, bland, undistinctive.
$2.5 billion on marketing, and there is a fair chance that when customers see "Leap Ahead" on a PC after that, they will think it is AMD's slogan, or that Leap is some new Chinese chip manufacturer.
Nil novi sub sole in the world of marketing. Have you noticed how in recent years, just about every small airliner has been renamed the Regional Jet?
If people would ask me the #1 reason to look for another job: The IT department.
Diverse and interesting work, nice colleagues, bosses who value my work highly, and a good salary... but, that IT department.
Every morning the thought of having to switch on that damn PC and struggle against it for the whole day... Need help on a complex Excel function? Press F1, then go for a cup of coffee.
Need to visit a supplier and give a presentation? Be prepared to apologize, repeatedly, until your machine has finally become functional. And yes, their IT manager will helpfully tell you that you should talk to your IT manager about system performance.
And the hardware of that laptop is decent enough. Just overloaded with bells, whistles, and security systems by IT, to the point where it barely worked.
End result? I have often enough taken work home to do it on my own PC, after hours. Nothing critical, certainly no patient data involved, but probably against the regulations. I owned a system with decent performance and the necessary software, which IT could not deliver for me on a reasonable time scale (although it was downloadable). And doing some work in my own time was far less annoying than having to do it on IT-installed systems.
Frankly, people in large companies often do not just think of the IT people as "bad guys", they think of them as hopeless. If they have an IT problem, their reaction is not: "Aargh, we will have to talk to those bastards in IT again." Their reaction is: "Well, it is an IT problem, so nothing will be done about it, and therefore we will just have to live with it. Asking IT for help is no use anyway."
If you think I sound harsh: Actually I often enough find myself defending the IT people against the criticisms of my colleagues, which are even harsher (and often less than fair).
I fully agree with the "typical user". I have yet to discover a large, centralized IT infrastructure departement that provides an adequate service, not to mention a good one.
Such departements is actually behave very much like worms. They infiltrate all systems and consume computer resources at a high rate, denying them to the people for whose use these systems actually are, with detrimental results to the business. A serious worm attack may cost a company a full working day; that is bad but after all it is only 0.5% or so of yearly productivity. Working on computers installed and maintained by a large IT infrastucture departement typically results in the loss about 20 minutes per day for all users; i.e. about 4% of productivity. And that is not taking into account all the administrative paperwork they require, or the health damage from computer-anger induced stress.
The fundamental reason for this, I suppose, is that the metrics IT uses as a measure of success tend to be completely unconnected with the goals of the business they have to support. I have no problem with security being high on the list of priorities; but usually performance appears to be near the bottom of that list --- if it is on it at all. And it is an unfortunate characteristic of IT infrastructure departements that they do not have to do any demanding work with the systems they install and manage; typically they use e-mail and some administrative software, but no heavy applications. In contrast, the departements that suffer the most (and complain the most) tend to be the ones that do: Programming, computer modelling, statistical analysis, datawarehousing.
Closely related to this is the tendency to standardisation, of hardware and software, that is exhibited by IT departements. That is just about tolerable in an office environment, although it results in a software environment that is a monoculture and very vulnerable to infection. (And usually at least a full generation behind the state of the art.) In an industrial or R&D environment the loss of flexibility that this entails is a major source of trouble, but an IT infrastructure group won't see this because it doesn't live in the same world. Characteristically, IT will allow only a few computer configurations, none of which is up to the job for a particular application (if only because the boards simply won't fit in), and one OS, which is not suitable either. IT will balk at spending an extra $2,000 for a more powerful PC, even though it is needed for the exploitation of an investment of $500,000.
Now, I admit that in any IT group there will be sensible people with whom a solution can be doctored out; unfortunately they are rarely encouraged by the culture of such a departement. The first problem is that such a team lives by regulations and often regards the rulebook as sufficient justification to do something, even if this blantantly conflicts with common sense. The second problem is that large teams encourage specialisation and task-sharing. It sounds innocent, but it actually means the responsibility for ordering, installing, delivering and connecting a PC will be split over at least four people, and at least eight for a server. Hence, the larger your IT group, the more you have to run around in circles to get the solution you need.
Of course it gets even worse when such large departements actually get involved in defining and executing software projects. They are almost guarantueed to organize a team that is too large, too distant from the reality of the processes it has to support, and conservative rather than creative. The typical result is a spectacular failure, a useless system delivered at a cost of millions of dollars.
Oh yes, I admit that there needs to be a central IT infrastructure group: For maintaining networks and servers, there is no other option. But such groups should be given power strictly on a need-to-have basis. All IT work that does not need to be done by a central group should be decentralized, in small teams that should
India has the know-how and infrastructure to produce drugs, and (equally important) to set up all the necessary administration to prove that they manufacture a quality product. (The approval of a new drug requires a file of a quarter of million pages or so; a copy of course needs considerably less, but the administrative burden still is nothing to laugh at.)
In central Africa that is not so evident; they lack the money, many educated people left their country, and the widespread corruption erodes the credibility of local manufacturers.
However, there is production of generic drugs in South-Africa, and an Indian company has started a join-venture in Uganda that should become operational in the middle of next year.
You are oversimplifying. Employees of pharmaceutical companies are human too, and leading AIDS researchers can hardly avoid being aware of the situation in Africa.
As far as I can see, most pharmaceutical companies are willing to supply antiretroviral treatment to patients in Africa at close to production cost, or license production at similar terms. Ethically it obviously the right thing to do. On the balance sheet there is no loss of market share because these patients could not afford to buy the drugs anyway. And crucially, if companies provide an affordable supply of HIV drugs they may make no profit, but still retain control and ownership. From a business perspective, this is far better than allowing someone else to produce them.
The biggest worry of the industry is the erosion of intellectual property by uncontrolled production of copies in the third world. In the pharmaceutical business, knowledge is money, and intellectual property determines the value of a company. Another concern is that drugs delivered to or produced in the third world at bottom prices could filter back to the rich countries and undermine their market there. It is one thing to give drugs to the poor, and quite another to give drugs to the rich. Someone needs to pay, or the companies will indeed fold.
The best way for pharmaceutical companies to prevent these things from happening is to take action themselves or actively cooperate with the efforts of others. And besides, the cost of supplying drugs to patients who cannot afford them is partially met by government funds, non-profit organisations and gifts from donors.
As disastrous as their situation is, AIDS patients in Africa at least have treatment options, and that is mainly because their disease is not only a third world disease. For if there were no patients in North America and Europe, there probably would be no drugs at all, or only very limited treatment options.
I think this is a more fundamental problem: How do we develop drugs or vaccines for typical tropical diseases? The patients cannot provide a return on investment. The half a billion dollars or so that are now required to develop a new drug are can be afforded by Western goverments, but their voters don't care.
I found a sample on the US customs and border protection site. The exact wording is:
Have you ever been or are you now involved in espionage or sabotage; or in terrorist activities; or genocide; or between 1933 and 1945 where you involved, in any way, in persecutions associated with Nazi Germany or its allies?
This by no means about Americans going about "their own business". What is involves is a finite and in fact scarce resource to which the USA or the citizens of the USA cannot claim exclusive ownership, to wit, the ability of the planet's ecosystem to absorb CO2 and other greenhouse gases. A resource of which they are using a disproportionally large share.
The logical way to approach this is as follows. First we estimate, as well as we can, the total capacity of the planet to absorb CO2 emissions. The estimate of the UK government is, I believe, that this is about 40% of the current emission level. Then we divide this by the number of people on the planet, and assign every person an equal share, as there is no imagineable reason why some people should be entitled to a larger share of the atmosphere than others. Finally, we organize a market for it: If you want to pollute more than your share, you will have to pay others to assign you a part of their share.
Of course, such a system would require the USA to reduce its greenhouse gas emissions by about 90% or so, or pay on a large scale for emission rights. Either way would work.
US reluctance to do something measurable about the greenhouse effect is more than a nuisance. To many nations it does, in effect, represent a Clear and Present Danger; for global climate change is one of the largest threats vulnerable nations face in the 21st century. In my opinion they would be fully justified in regarding US inaction over this as a valid casus belli and acting accordingly.
As for Britain staying out of the Euro, I have long reached the conclusion that Britain can no longer have a place within the EU if the EU wants to evolve into an effective organisation. The systematic institutional sabotage from London can no longer be tolerated, and the attitude of British politicians to the Euro -- which is, basically, that they will get in whenever the UK economy is on its knees and needs a boost -- is cowardly and deplorable. It would be much better if Britain was just the 51st state of the USA.