Showing posts with label #FreeGary. Show all posts
Showing posts with label #FreeGary. Show all posts

Wednesday, August 22, 2012

Gary McKinnon is no enemy of the state

Gary McKinnon
Gary McKinnon outside the Royal Courts of Justice in London. Photograph: John D Mchugh/AFP/Getty Images

A final decision on whether computer hacker Gary McKinnon is to be extradited to the United States is now imminent. Behind the scenes, a battle is apparently under way between politicians and officials over what the outcome should be. There may be much else to occupy the government at the moment, but it is vital that this matter of principle is not sidelined.

More than a decade has passed since a self-styled computer nerd, working out of a bedroom in north London, started trawling through the computer systems of Nasa and the US defence department in search of information about UFOs. He left behind some rude messages about the systems' sloppy security and was arrested by British police. In all that time, no evidence has been advanced by the US prosecuting authorities that any harm – beyond the cost of installing better computer security – has resulted from McKinnon's activities.

Had he been prosecuted in the UK, as he should have been at the time, the whole matter would have been forgotten. McKinnon, who has since been diagnosed with Asperger's syndrome, would have served a mild, possibly suspended, sentence. As it is, his case now presents the government with a test of ethics.

"Gary McKinnon has been hung out to dry by a British government desperate to appease its American counterparts" – the words of Nick Clegg, while still in opposition. "Gary McKinnon is a vulnerable young man and I see no compassion in sending him thousands of miles away from his home and loved ones to stand trial. If he has questions to answer, there is a clear argument to be made that he should answer them in a British court," is what David Cameron said before he became prime minister. Fine words. They should both now make clear to home secretary Theresa May that she would have their full and public backing, despite what her officials may tell her, if she announces that McKinnon is not to be hauled off to the US.

The failure to deal with the case has already taken its toll on him, and the latest psychiatric assessment, made in April this year, places him at "extreme" risk of suicide if extradited. "Gary has lost 10 years of his youth," his mother, Janis, said on Monday. "A young man who cycled, swam, composed music and sang, now sits in the dark with his cats and never wants to see or speak to anyone."

Cameron, to his credit, has raised the case with President Obama on at least two occasions. The latter indicated that he would be content with whatever decision the British government were to make. It has long been clear that there is little real clamour in the US for McKinnon to be sent there for trial. Whether that relaxed attitude would change if Mitt Romney was to win the presidential election in November is another matter. For this reason, it is important that the British government acts now.

McKinnon's MP, David Burrowes, has hit on a novel way to resolve the issue by attaching it to the diamond jubilee celebrations. He wants the Queen to consider using her prerogative of mercy to ensure justice is served. The government should consider that doing the right thing will have only favourable consequences for them. A decision to allow the extradition would haunt them all the way, through trials and imprisonment, to the next election. The case of Gary McKinnon is a clear instance of a vulnerable individual being targeted by an overwhelmingly powerful force. With this in mind, it is time for Theresa May to reassert the rights of the citizen and to stand up to the bullying threats from the other side of the Atlantic.

http://www.guardian.co.uk/commentisfree/2012/jun/04/gary-mckinnon-extradition...

Freegaryavi

Posted from DailyDDoSe

Tuesday, August 21, 2012

No Extradition for Gary McKinnon

The Hanged Man: Gary McKinnon from a Tarot Perspective

I have often thought of Gary McKinnon as a real-life representation of the twelfth card in the Tarot, ‘The Hanged Man’. Below are a couple of examples from two very well-known Tarot decks, the Rider Waite and the Morgan-Greer.

Take a look at these two cards. A man is hanging upside down; his face is relaxed; his posture, with his arms held behind his back could be that of someone just waiting, without a care in the world, if the man was standing up. 

It is clear that this is not a man who is being hung, as a form of execution, but rather a man who is suspended, waiting.

Gary McKinnon has been waiting for a decision on his fate for almost 10 years now. He was a young man when he was caught hacking into the Pentagon’s unsecured computers, and he is now 45 years old. During the past 10 years, he has been suspended in limbo, while the most prolonged, drawn-out, Bleak House-style legal proceedings have been under way. Because of his deteriorating mental health, Gary has made very few public appearances in recent times; he has given up control over his destiny and handed it over to his mother, Janis Sharp, who is the face of the campaign to grant him a U.K. trial

The Hanged Man is tied to a wooden frame which is made of Rods (also referred to as Wands, which are the suit of ‘action’); therefore, he is tied to the action that he cannot control. The clouds in the background of the Morgan Greer card represent the air, the high concepts of justice of liberty that are being discussed while the subject hangs, still.

The twelfth card in the Tarot is even more relevant to Gary McKinnon’s life when one looks at the cards that precede it and that follow. Card No. 11 is “Justice”; card no. 13 is “Death” (which, in the traditional Tarot de Marseille, is actually referred to as “The Arcane with No Name”). Justice initiated the process; in the name of ‘Justice’ Gary was arrested and in the name of ‘Justice’ the USA demanded his extradition; but even the ‘crime’ itself was triggered in a - probably misguided - pursuit of justice, as Gary was scanning the US defence computers in search of UFO technology that allegedly would solve the global shortage of fossil fuels.

“Death” is the end of this process, the end of hanging, a final conclusion. The end, in other words, is near. But what will “The End” mean for Gary McKinnon? What will be of this man when the final verdict is read out in court, when the final credits roll?

Even assuming a positive outcome - a U.K. trial, or a complete acquittal - there will be no walking into the sunset for Gary. His supporters will be celebrating, but he will have to re-adjust to standing up rather than hanging; his ankles will have been cut through to the flesh by the rope he has been hanging from for the last 10 years. Blood will rush from his head down to his feet. He will be unsteady on his legs. After ten years of being The Hanged Man, Gary McKinnon will have to learn how to walk all over again. 

Posted from DailyDDoSe

Saturday, June 23, 2012

Asperger's Syndrome: MedlinePlus

 

Asperger's syndrome (AS) is an autism spectrum disorder. It is milder than autism but shares some of its symptoms. It is more common in boys than girls.

An obsessive interest in a single subject is a major symptom of AS. Some children with AS have become experts on dinosaurs, makes and models of cars, even objects as seemingly odd as vacuum cleaners. Their expertise, high level of vocabulary and formal speech patterns make them seem like little professors.

Children with AS have trouble reading social cues and recognizing other people's feelings. They may have strange movements or mannerisms. All of these make it difficult for them to make friends. Problems with motor skills are also common in children with AS. They may be late learning to ride a bike or catch a ball, for example. Treatment focuses on the three main symptoms: poor communication skills, obsessive or repetitive routines, and physical clumsiness.

NIH: National Institute of Neurological Disorders and Stroke

 

The top row in the table of contents box contains the following groups: Basics , Learn More , and Multimedia & Cool Tools .

For group Basics
For group Learn More
  • No links available
For group Multimedia & Cool Tools
  • No links available

 

The bottom row in the table of contents box contains the following groups: Research , Reference Shelf , and For You .

For group Research
For group Reference Shelf
For group For You

 

 

 

Tuesday, June 12, 2012

UK-US Extradition Agreement (2003) | Public International Law

UK-US Extradition Agreement (2003)

The Government of the United Kingdom of Great Britain and Northern Ireland and the Government of the United States of America, Recalling the Extradition Treaty between the Government of the United States of America and the Government of the United Kingdom of Great Britain and Northern Ireland signed at London, June 8, 19721, as amended by the Supplementary Treaty between the two States, signed at Washington, June 25, 19852; and Desiring to provide for more effective cooperation between the two States in the suppression of crime, and, for that purpose, to conclude a new treaty for the extradition of offenders;

Have agreed as follows:

ARTICLE 1

Obligation to Extradite

The Parties agree to extradite to each other, pursuant to the provisions of this Treaty, persons sought by the authorities in the Requesting State for trial or punishment for extraditable offenses.

ARTICLE 2

Extraditable Offenses

1. An offense shall be an extraditable offense if the conduct on which the offense is based is punishable under the laws in both States by deprivation of liberty for a period of one year or more or by a more severe penalty.

2. An offense shall also be an extraditable offense if it consists of an attempt or a conspiracy to commit, participation in the commission of, aiding or abetting, counseling or procuring the commission of, or being an accessory before or after the fact to any offense described in paragraph 1 of this Article.

3. For the purposes of this Article, an offense shall be an extraditable offense:

——————————————————————-

1. Treaty Series No. 16 (1977) Cmnd 6723 4

2. Treaty Series No. 6 (1988) Cm 294 (a) whether or not the laws in the Requesting and Requested States place the offense within the same category of offenses or describe the offense by the same terminology; or (b) whether or not the offense is one for which United States federal law requires the showing of such matters as interstate transportation, or use of the mails or of other facilities affecting interstate or foreign commerce, such matters being jurisdictional only.

4. If the offense has been committed outside the territory of the Requesting State, extradition shall be granted in accordance with the provisions of the Treaty if the laws in the Requested State provide for the punishment of such conduct committed outside its territory in similar circumstances. If the laws in the Requested State do not provide for the punishment of such conduct committed outside of its territory in similar circumstances, the executive authority of the Requested State, in its discretion, may grant extradition provided that all other requirements of this Treaty are met.

5. If extradition has been granted for an extraditable offense, it may also be granted for any other offense specified in the request if the latter offense is punishable by less than one year’s deprivation of liberty, provided that all other requirements for extradition are met.

ARTICLE 3

Nationality

Extradition shall not be refused based on the nationality of the person sought.

ARTICLE 4

Political and Military Offenses

1. Extradition shall not be granted if the offense for which extradition is requested is a political offense.

2. For the purposes of this Treaty, the following offenses shall not be considered political offenses:

(a) an offense for which both Parties have the obligation pursuant to a multilateral international agreement to extradite the person sought or to submit the case to their competent authorities for decision as to prosecution; 5

(b) a murder or other violent crime against the person of a Head of State of one of the Parties, or of a member of the Head of State’s family;

(c) murder, manslaughter, malicious wounding, or inflicting grievous bodily harm;

(d) an offense involving kidnaping, abduction, or any form of unlawful detention, including the taking of a hostage;

(e) placing or using, or threatening the placement or use of, an explosive, incendiary, or destructive device or firearm capable of endangering life, of causing grievous bodily harm, or of causing substantial property damage;

(f) possession of an explosive, incendiary, or destructive device capable of endangering life, of causing grievous bodily harm, or of causing substantial property damage;

(g) an attempt or a conspiracy to commit, participation in the commission of, aiding or abetting, counseling or procuring the commission of, or being an accessory before or after the fact to any of the foregoing offenses.

3. Notwithstanding the terms of paragraph 2 of this Article, extradition shall not be granted if the competent authority of the Requested State determines that the request was politically motivated. In the United States, the executive branch is the competent authority for the purposes of this Article.

4. The competent authority of the Requested State may refuse extradition for offenses under military law that are not offenses under ordinary criminal law. In the United States, the executive branch is the competent authority for the purposes of this Article.

ARTICLE 5

Prior Prosecution

1. Extradition shall not be granted when the person sought has been convicted or acquitted in the Requested State for the offense for which extradition is requested.

2. The Requested State may refuse extradition when the person sought has been convicted or acquitted in a third state in respect of the conduct for which extradition is requested.

3. Extradition shall not be precluded by the fact that the competent authorities of the Requested State: 6

(a) have decided not to prosecute the person sought for the acts for which extradition is requested;

(b) have decided to discontinue any criminal proceedings which have been instituted against the person sought for those acts; or

(c) are still investigating the person sought for the same acts for which extradition is sought.

ARTICLE 6

Statute of Limitations

The decision by the Requested State whether to grant the request for extradition shall be made without regard to any statute of limitations in either State.

ARTICLE 7

Capital Punishment

When the offense for which extradition is sought is punishable by death under the laws in the Requesting State and is not punishable by death under the laws in the Requested State, the executive authority in the Requested State may refuse extradition unless the Requesting State provides an assurance that the death penalty will not be imposed or, if imposed, will not be carried out.

ARTICLE 8

Extradition Procedures and Required Documents

1. All requests for extradition shall be submitted through the diplomatic channel.

2. All requests for extradition shall be supported by:

(a) as accurate a description as possible of the person sought, together with any other information that would help to establish identity and probable location;

(b) a statement of the facts of the offense(s);

(c) the relevant text of the law(s) describing the essential elements of the offense for which extradition is requested; 7

(d) the relevant text of the law(s) prescribing punishment for the offense for which extradition is requested; and

(e) documents, statements, or other types of information specified in paragraphs 3 or 4 of this Article, as applicable.

3. In addition to the requirements in paragraph 2 of this Article, a request for extradition of a person who is sought for prosecution shall be supported by:

(a) a copy of the warrant or order of arrest issued by a judge or other competent authority;

(b) a copy of the charging document, if any; and

(c) for requests to the United States, such information as would provide a reasonable basis to believe that the person sought committed the offense for which extradition is requested.

4. In addition to the requirements in paragraph 2 of this Article, a request for extradition relating to a person who has been convicted of the offense for which extradition is sought shall be supported by:

(a) information that the person sought is the person to whom the finding of guilt refers;

(b) a copy of the judgment or memorandum of conviction or, if a copy is not available, a statement by a judicial authority that the person has been convicted;

(c) a copy of the sentence imposed, if the person sought has been sentenced, and a statement establishing to what extent the sentence has been carried out; and

(d) in the case of a person who has been convicted in absentia, information regarding the circumstances under which the person was voluntarily absent from the proceedings.

ARTICLE 9

Authentication of Documents

The documents that support an extradition request shall be deemed to be authentic and shall be received in evidence in extradition proceedings without further proof if:

(a) regarding a request from the United States 8

(i) they are authenticated by the oath of a witness, or

(ii) they purport to be signed by a judge, magistrate, or officer of the United States and they purport to be certified by being sealed with the official seal of the Secretary of State of the United States;

(b) regarding a request from the United Kingdom, they are certified by the principal diplomatic or principal consular officer of the United States resident in the United Kingdom, as provided by the extradition laws of the United States;

(c) regarding a request from a territory of the United Kingdom, they are certified either by the principal diplomatic or principal consular officer of the United States responsible for that territory; or

(d) regarding a request from either Party, they are certified or authenticated in any other manner acceptable under the law in the Requested State.

ARTICLE 10

Additional Information

If the Requested State requires additional information to enable a decision to be taken on the request for extradition, the Requesting State shall respond to the request within such time as the Requested State requires.

ARTICLE 11

Translation

All documents submitted under this Treaty by the Requesting State shall be in English or accompanied by a translation into English.

ARTICLE 12

Provisional Arrest

1. In an urgent situation, the Requesting State may request the provisional arrest of the person sought pending presentation of the request for extradition. A request for provisional arrest may be transmitted through the diplomatic channel or directly between the United States Department of Justice and such competent authority as the United Kingdom may designate for the purposes of this Article.

2. The application for provisional arrest shall contain: 9

(a) a description of the person sought;

(b) the location of the person sought, if known;

(c) a brief statement of the facts of the case including, if possible, the date and location of the offense(s);

(d) a description of the law(s) violated;

(e) a statement of the existence of a warrant or order of arrest or a finding of guilt or judgment of conviction against the person sought; and

(f) a statement that the supporting documents for the person sought will follow within the time specified in this Treaty.

3. The Requesting State shall be notified without delay of the disposition of its request for provisional arrest and the reasons for any inability to proceed with the request.

4. A person who is provisionally arrested may be discharged from custody upon the expiration of sixty (60) days from the date of provisional arrest pursuant to this Treaty if the executive authority of the Requested State has not received the formal request for extradition and the documents supporting the extradition request as required in Article 8.

For this purpose, receipt of the formal request for extradition and supporting documents by the Embassy of the Requested State in the Requesting State shall constitute receipt by the executive authority of the Requested State.

5. The fact that the person sought has been discharged from custody pursuant to paragraph 4 of this Article shall not prejudice the subsequent re-arrest and extradition of that person if the extradition request and supporting documents are delivered at a later date.

ARTICLE 13

Decision and Surrender

1. The Requested State shall promptly notify the Requesting State of its decision on the request for extradition. Such notification should be transmitted directly to the competent authority designated by the Requesting State to receive such notification and through the diplomatic channel.

2. If the request is denied in whole or in part, the Requested State shall provide reasons for the denial. The Requested State shall provide copies of pertinent judicial decisions upon request.

3. If the request for extradition is granted, the authorities of the Requesting and Requested States shall agree on the time and place for the surrender of the person sought. 10

4. If the person sought is not removed from the territory of the Requested State within the time period prescribed by the law of that State, that person may be discharged from custody, and the Requested State, in its discretion, may subsequently refuse extradition for the same offense(s).

ARTICLE 14

Temporary and Deferred Surrender

1. If the extradition request is granted for a person who is being proceeded against or is serving a sentence in the Requested State, the Requested State may temporarily surrender the person sought to the Requesting State for the purpose of prosecution. If the Requested State requests, the Requesting State shall keep the person so surrendered in custody and shall return that person to the Requested State after the conclusion of the proceedings against that person, in accordance with conditions to be determined by mutual agreement of the States.

2. The Requested State may postpone the extradition proceedings against a person who is being prosecuted or who is serving a sentence in that State. The postponement may continue until the prosecution of the person sought has been concluded or until such person has served any sentence imposed.

ARTICLE 15

Requests for Extradition Made by Several States If the Requested State receives requests from two or more States for the extradition of the same person, either for the same offense or for different offenses, the executive authority of the Requested State shall determine to which State, if any, it will surrender the person. In making its decision, the Requested State shall consider all relevant factors, including but not limited to:

(a) whether the requests were made pursuant to a treaty;

(b) the place where each offense was committed;

(c) the gravity of the offenses;

(d) the possibility of any subsequent extradition between the respective Requesting States; and 11

(e) the chronological order in which the requests were received from the respective Requesting States.

ARTICLE 16

Seizure and Surrender of Property

1. To the extent permitted under its law, the Requested State may seize and surrender to the Requesting State all items in whatever form, and assets, including proceeds, that are connected with the offense in respect of which extradition is granted. The items and assets mentioned in this Article may be surrendered even when the extradition cannot be effected due to the death, disappearance, or escape of the person sought.

2. The Requested State may condition the surrender of the items upon satisfactory assurances from the Requesting State that the property will be returned to the Requested State as soon as practicable. The Requested State may also defer the surrender of such items if they are needed as evidence in the Requested State.

ARTICLE 17

Waiver of Extradition

If the person sought waives extradition and agrees to be surrendered to the Requesting State, the Requested State may surrender the person as expeditiously as possible without further proceedings.

ARTICLE 18

Rule of Specialty

1. A person extradited under this Treaty may not be detained, tried, or punished in the Requesting State except for:

(a) any offense for which extradition was granted, or a differently denominated offense based on the same facts as the offense on which extradition was 12 granted, provided such offense is extraditable, or is a lesser included offense;

(b) any offense committed after the extradition of the person; or

(c) any offense for which the executive authority of the Requested State waives the rule of specialty and thereby consents to the person’s detention, trial, or punishment. For the purpose of this subparagraph:

(i) the executive authority of the Requested State may require the submission of the documentation called for in Article 8; and

(ii) the person extradited may be detained by the Requesting State for 90 days, or for such longer period of time as the Requested State may authorize, while the request for consent is being processed.

2. A person extradited under this Treaty may not be the subject of onward extradition or surrender for any offense committed prior to extradition to the Requesting State unless the Requested State consents.

3. Paragraphs 1 and 2 of this Article shall not prevent the detention, trial, or punishment of an extradited person, or the extradition of the person to a third State, if the person:

(a) leaves the territory of the Requesting State after extradition and voluntarily returns to it; or

(b) does not leave the territory of the Requesting State within 20 days of the day on which that person is free to leave.

4. If the person sought waives extradition pursuant to Article 17, the specialty provisions in this Article shall not apply.

ARTICLE 19

Transit

1. Either State may authorize transportation through its territory of a person surrendered to the other State by a third State or from the other State to a third State. A request for transit shall contain a description of the person being transported and a brief statement of the facts of the case. A person in transit shall be detained in custody during the period of transit.

2. Authorization is not required when air transportation is used by one State and no landing is scheduled on the territory of the other State. If an unscheduled landing does occur, the State in which the unscheduled landing occurs may require a request for transit pursuant to paragraph 1 of this Article, and it may detain the person until the request for 13 transit is received and the transit is effected, as long as the request is received within 96 hours of the unscheduled landing.

ARTICLE 20

Representation and Expenses

1. The Requested State shall advise, assist, and appear on behalf of, the Requesting State in any proceedings in the courts of the Requested State arising out of a request for extradition or make all necessary arrangements for the same.

2. The Requesting State shall pay all the expenses related to the translation of extradition documents and the transportation of the person surrendered. The Requested State shall pay all other expenses incurred in that State in connection with the extradition proceedings.

3. Neither State shall make any pecuniary claim against the other State arising out of the arrest, detention, examination, or surrender of persons under this Treaty.

ARTICLE 21

Consultation

The Parties may consult with each other in connection with the processing of individual cases and in furtherance of efficient implementation of this Treaty.

ARTICLE 22

Application

1. This Treaty shall apply to offenses committed before as well as after the date it enters into force.

2. This Treaty shall apply:

(a) in relation to the United Kingdom: to Great Britain and Northern Ireland, the Channel Islands, the Isle of Man; and to any territory for whose international relations the United Kingdom is responsible and to which this agreement has been extended by agreement of the Parties; and

(b) to the United States of America.

3. The application of this Treaty to any territory in respect of which extension has been made in accordance with paragraph 2 of this Article may be terminated by either State giving six months’ written notice to the other through the diplomatic channel. 14

4. A request by the United States for the extradition of an offender who is found in any of the territories to which this Treaty applies in accordance with paragraph 2 of this Article may be made to the Governor or other competent authority of that territory, who may take the decision himself or refer the matter to the Government of the United Kingdom for its decision. A request on the part of any of the territories to which this Treaty applies in accordance with paragraph 2 of this Article for the extradition of an offender who is found in the United States of America may be made to the Government of the United States by the Governor or other competent authority of that territory.

ARTICLE 23

Ratification and Entry into Force

1. This Treaty shall be subject to ratification; the instruments of ratification shall be exchanged as soon as possible.

2. This Treaty shall enter into force upon the exchange of the instruments of ratification.

3. Upon the entry into force of this Treaty, the Extradition Treaty signed at London on June 8, 1972, and the Supplementary Treaty signed at Washington on June 25, 1985, (together, “the prior Treaty”) shall cease to have any effect as between the United States and the United Kingdom, except as otherwise provided below.  The prior Treaty shall apply to any extradition proceedings in which the extradition documents have already been submitted to the courts of the Requested State at the time this Treaty enters into force, except that Article 18 of this Treaty shall apply to persons found extraditable under the prior Treaty.

4. The prior Treaty shall also apply to any territory to which it has been extended in accordance with Article II of that Treaty, until such time as the provisions of this Treaty have been extended to such a territory under Article 22(2).

ARTICLE 24

Termination

Either State may terminate this Treaty at any time by giving written notice to the other State through the diplomatic channel, and the termination shall be effective six months after the date of receipt of such notice. 15

IN WITNESS WHEREOF, the undersigned, being duly authorized by their respective Governments, have signed this Treaty.

DONE at Washington, in duplicate, this 31st day of March, 2003.

FOR THE GOVERNMENT OF THE UNITED KINGDOM OF GREAT BRITAIN AND NORTHERN IRELAND:  DAVID BLUNKETT

FOR THE GOVERNMENT OF THE UNITED STATES OF AMERICA: JOHN ASHCROFT

http://www.dipublico.com.ar/english/uk-us-extradition-agreement-2003/

Posted via email from DailyDDoSe

Tensions Ahead Over U.S.–U.K. Extradition Treaty [EMBEDDED PDF]

UK_USA_extradition.pdf Download this file
It’s a common-sense idea that criminals should not be able to escape justice in one country simply by fleeing to another. In this Internet age, it’s also common sense that citizens of one country should not be able commit crimes electronically in another without fear of punishment. This is the problem that extradition is intended to solve.

Of course, it’s also true that all democratic nations have the obligation to protect the rights of their citizens and uphold their national sovereignty. Thus, any system of extradition must balance the national obligation not to become a safe haven for criminals with the vital importance of sovereignty.

The current extradition treaty between the U.S. and Britain, signed in 2003, has become controversial in Britain because, it is alleged, the treaty is biased in favor of the United States. The controversy has centered on the case of Gary McKinnon, a British national accused of hacking into U.S. government computers to confirm his belief that Washington was withholding information that proves, among other things, the existence of unidentified flying objects, the U.S.’s refusal to publicize the anti-gravity technology it acquired from the UFOs, and a 9/11 conspiracy. The British government has asked Sir Scott Baker, a senior judge, to conduct a review of the treaty, a review that is due to conclude this coming summer. 

Last year, Heritage published a study of the treaty that concluded that, while extradition from Britain was too easy, this was not the fault of the U.S.–U.K. treaty. Rather, it was because the Labour government of Tony Blair wanted to make it easy to extradite individuals from Britain. Blair’s government therefore created low standards for extradition and applied them to many countries, including the U.S. The U.S.–U.K. treaty is compatible with higher standards if Britain chooses to apply them. In a paper published yesterday by the Foreign Policy Centre in London, Andrew Southam, a former extradition case officer at Britain’s Home Office, agrees that criticisms of the treaty are misconceived.

Southam also makes a series of well-considered recommendations for British policy going forward, including the need to work with the U.S. and other democratic countries to review the handling of complex crimes committed over the Internet and the need to monitor best practices in extradition, as both the U.S. and Australia have done.

Most important, though, is his final recommendation: The Baker review was a response to public pressure. If its findings agree with those of Heritage and Southam, British ministers need to make the case for the U.S.–U.K. treaty. The Labour ministers who negotiated it have done a disservice to U.S.–U.K. relations by badmouthing their own work. David Cameron’s government should make a calm, clear statement that the treaty works, and both sides should demonstrate a willingness to uphold its provisions conscientiously.

Posted in American Leadership

 

Posted via email from DailyDDoSe

Tensions Ahead Over U.S.–U.K. Extradition Treaty

It’s a common-sense idea that criminals should not be able to escape justice in one country simply by fleeing to another. In this Internet age, it’s also common sense that citizens of one country should not be able commit crimes electronically in another without fear of punishment. This is the problem that extradition is intended to solve.

Of course, it’s also true that all democratic nations have the obligation to protect the rights of their citizens and uphold their national sovereignty. Thus, any system of extradition must balance the national obligation not to become a safe haven for criminals with the vital importance of sovereignty.

The current extradition treaty between the U.S. and Britain, signed in 2003, has become controversial in Britain because, it is alleged, the treaty is biased in favor of the United States. The controversy has centered on the case of Gary McKinnon, a British national accused of hacking into U.S. government computers to confirm his belief that Washington was withholding information that proves, among other things, the existence of unidentified flying objects, the U.S.’s refusal to publicize the anti-gravity technology it acquired from the UFOs, and a 9/11 conspiracy. The British government has asked Sir Scott Baker, a senior judge, to conduct a review of the treaty, a review that is due to conclude this coming summer.

Last year, Heritage published a study of the treaty that concluded that, while extradition from Britain was too easy, this was not the fault of the U.S.–U.K. treaty. Rather, it was because the Labour government of Tony Blair wanted to make it easy to extradite individuals from Britain. Blair’s government therefore created low standards for extradition and applied them to many countries, including the U.S. The U.S.–U.K. treaty is compatible with higher standards if Britain chooses to apply them. In a paper published yesterday by the Foreign Policy Centre in London, Andrew Southam, a former extradition case officer at Britain’s Home Office, agrees that criticisms of the treaty are misconceived.

Southam also makes a series of well-considered recommendations for British policy going forward, including the need to work with the U.S. and other democratic countries to review the handling of complex crimes committed over the Internet and the need to monitor best practices in extradition, as both the U.S. and Australia have done.

Most important, though, is his final recommendation: The Baker review was a response to public pressure. If its findings agree with those of Heritage and Southam, British ministers need to make the case for the U.S.–U.K. treaty. The Labour ministers who negotiated it have done a disservice to U.S.–U.K. relations by badmouthing their own work. David Cameron’s government should make a calm, clear statement that the treaty works, and both sides should demonstrate a willingness to uphold its provisions conscientiously.

Posted in American Leadership

Posted via email from DailyDDoSe

Sunday, April 15, 2012

Project Camelot: Interview with @JanisSharp: #FreeGary #McKinnon

Uploaded by jagbodhi on May 17, 2010

On my recent trip to London I was fortunate to get the chance to meet Janis Sharp, Gary McKinnon's mother, a powerhouse who has been very actively working to stop the extradition of her son to the U.S. She has been surprisingly successful in generating a grass roots movement of support that includes such luminaries as Sting, Bob Geldof and Chrissie Hynde. As many people know, Gary McKinnon is also an accomplished and talented musician. Through Janis's efforts a new renditon of the well known protest song "Chicago" by Graham Nash has been released and is available on the Free Gary website for download.

A short summary of the case from the Free Gary website:

"...seven years since his initial arrest !). Gary was indicted by a US court in November 2002, accused of "hacking" into over 90 US Military computer systems from here in the UK. The unjust treatment of British citizens (and others) when facing the might of the US Military "justice" system, which practices detention without trial in Guantanamo Bay and elsewhere, and stands accused of making use of torture by allied regimes ("extraordinary rendition") is an ongoing scandal. It cannot be excused even by a "war on terror". It seems only just that Gary should face any charges in a British court, and to serve any sentence, if he is found guilty, in a British prison.

While it is obviously crucial that Gary not be extradited, as many will know, who have followed Project Camelot since the beginning, I interviewed Gary back in 2006. I encourage you to watch the original interview with Gary "Hacking the Pentagon" which really shows his personality and brings forward what he found using a dial-up modem several years ago; records within NASA and the Pentagon that detailed non-terrestrial officers, fleet-to-fleet off- world transfers... in essence evidence of the existence of the secret space program and the true advances in technology and space travel code name: Solar Warden.

Kerry Lynn Cassidy
http://projectcamelotportal.com
http://projectcamelotproductions.com
May 2010

Website in support of Gary McKinnon:
http://freegary.org.uk/
Category:

People & Blogs
Tags:

Gary McKinnon
secret space program
ufos
ets
aliens
fleet to fleet transfers
off-world
nonterrestrial officers
outer space
hackers
pentagon
nasa
UK
janis
kerry cassidy
project camelot
illuminati

License:

Standard YouTube License

Posted via email from DailyDDoSe

Project Camelot Interviews #FreeGary #McKinnon

Sunday, December 11, 2011

Great Hackers

Great Hackers

Want to start a startup? Get funded by Y Combinator.

July 2004

(This essay is derived from a talk at Oscon 2004.)


Edisons --> A few months ago I finished a new book, and in reviews I keep noticing words like "provocative'' and "controversial.'' To say nothing of "idiotic.''

I didn't mean to make the book controversial. I was trying to make it efficient. I didn't want to waste people's time telling them things they already knew. It's more efficient just to give them the diffs. But I suppose that's bound to yield an alarming book.

Edisons

There's no controversy about which idea is most controversial: the suggestion that variation in wealth might not be as big a problem as we think.

I didn't say in the book that variation in wealth was in itself a good thing. I said in some situations it might be a sign of good things. A throbbing headache is not a good thing, but it can be a sign of a good thing-- for example, that you're recovering consciousness after being hit on the head.

Variation in wealth can be a sign of variation in productivity. (In a society of one, they're identical.) And that is almost certainly a good thing: if your society has no variation in productivity, it's probably not because everyone is Thomas Edison. It's probably because you have no Thomas Edisons.

In a low-tech society you don't see much variation in productivity. If you have a tribe of nomads collecting sticks for a fire, how much more productive is the best stick gatherer going to be than the worst? A factor of two? Whereas when you hand people a complex tool like a computer, the variation in what they can do with it is enormous.

That's not a new idea. Fred Brooks wrote about it in 1974, and the study he quoted was published in 1968. But I think he underestimated the variation between programmers. He wrote about productivity in lines of code: the best programmers can solve a given problem in a tenth the time. But what if the problem isn't given? In programming, as in many fields, the hard part isn't solving problems, but deciding what problems to solve. Imagination is hard to measure, but in practice it dominates the kind of productivity that's measured in lines of code.

Productivity varies in any field, but there are few in which it varies so much. The variation between programmers is so great that it becomes a difference in kind. I don't think this is something intrinsic to programming, though. In every field, technology magnifies differences in productivity. I think what's happening in programming is just that we have a lot of technological leverage. But in every field the lever is getting longer, so the variation we see is something that more and more fields will see as time goes on. And the success of companies, and countries, will depend increasingly on how they deal with it.

If variation in productivity increases with technology, then the contribution of the most productive individuals will not only be disproportionately large, but will actually grow with time. When you reach the point where 90% of a group's output is created by 1% of its members, you lose big if something (whether Viking raids, or central planning) drags their productivity down to the average.

If we want to get the most out of them, we need to understand these especially productive people. What motivates them? What do they need to do their jobs? How do you recognize them? How do you get them to come and work for you? And then of course there's the question, how do you become one?

More than Money

I know a handful of super-hackers, so I sat down and thought about what they have in common. Their defining quality is probably that they really love to program. Ordinary programmers write code to pay the bills. Great hackers think of it as something they do for fun, and which they're delighted to find people will pay them for.

Great programmers are sometimes said to be indifferent to money. This isn't quite true. It is true that all they really care about is doing interesting work. But if you make enough money, you get to work on whatever you want, and for that reason hackers are attracted by the idea of making really large amounts of money. But as long as they still have to show up for work every day, they care more about what they do there than how much they get paid for it.

Economically, this is a fact of the greatest importance, because it means you don't have to pay great hackers anything like what they're worth. A great programmer might be ten or a hundred times as productive as an ordinary one, but he'll consider himself lucky to get paid three times as much. As I'll explain later, this is partly because great hackers don't know how good they are. But it's also because money is not the main thing they want.

What do hackers want? Like all craftsmen, hackers like good tools. In fact, that's an understatement. Good hackers find it unbearable to use bad tools. They'll simply refuse to work on projects with the wrong infrastructure.

At a startup I once worked for, one of the things pinned up on our bulletin board was an ad from IBM. It was a picture of an AS400, and the headline read, I think, "hackers despise it.'' [1]

When you decide what infrastructure to use for a project, you're not just making a technical decision. You're also making a social decision, and this may be the more important of the two. For example, if your company wants to write some software, it might seem a prudent choice to write it in Java. But when you choose a language, you're also choosing a community. The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python. And the quality of your hackers probably matters more than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages.

Business types prefer the most popular languages because they view languages as standards. They don't want to bet the company on Betamax. The thing about languages, though, is that they're not just standards. If you have to move bits over a network, by all means use TCP/IP. But a programming language isn't just a format. A programming language is a medium of expression.

I've read that Java has just overtaken Cobol as the most popular language. As a standard, you couldn't wish for more. But as a medium of expression, you could do a lot better. Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero.

Great hackers also generally insist on using open source software. Not just because it's better, but because it gives them more control. Good hackers insist on control. This is part of what makes them good hackers: when something's broken, they need to fix it. You want them to feel this way about the software they're writing for you. You shouldn't be surprised when they feel the same way about the operating system.

A couple years ago a venture capitalist friend told me about a new startup he was involved with. It sounded promising. But the next time I talked to him, he said they'd decided to build their software on Windows NT, and had just hired a very experienced NT developer to be their chief technical officer. When I heard this, I thought, these guys are doomed. One, the CTO couldn't be a first rate hacker, because to become an eminent NT developer he would have had to use NT voluntarily, multiple times, and I couldn't imagine a great hacker doing that; and two, even if he was good, he'd have a hard time hiring anyone good to work for him if the project had to be built on NT. [2]

The Final Frontier

After software, the most important tool to a hacker is probably his office. Big companies think the function of office space is to express rank. But hackers use their offices for more than that: they use their office as a place to think in. And if you're a technology company, their thoughts are your product. So making hackers work in a noisy, distracting environment is like having a paint factory where the air is full of soot.

The cartoon strip Dilbert has a lot to say about cubicles, and with good reason. All the hackers I know despise them. The mere prospect of being interrupted is enough to prevent hackers from working on hard problems. If you want to get real work done in an office with cubicles, you have two options: work at home, or come in early or late or on a weekend, when no one else is there. Don't companies realize this is a sign that something is broken? An office environment is supposed to be something that helps you work, not something you work despite.

Companies like Cisco are proud that everyone there has a cubicle, even the CEO. But they're not so advanced as they think; obviously they still view office space as a badge of rank. Note too that Cisco is famous for doing very little product development in house. They get new technology by buying the startups that created it-- where presumably the hackers did have somewhere quiet to work.

One big company that understands what hackers need is Microsoft. I once saw a recruiting ad for Microsoft with a big picture of a door. Work for us, the premise was, and we'll give you a place to work where you can actually get work done. And you know, Microsoft is remarkable among big companies in that they are able to develop software in house. Not well, perhaps, but well enough.

If companies want hackers to be productive, they should look at what they do at home. At home, hackers can arrange things themselves so they can get the most done. And when they work at home, hackers don't work in noisy, open spaces; they work in rooms with doors. They work in cosy, neighborhoody places with people around and somewhere to walk when they need to mull something over, instead of in glass boxes set in acres of parking lots. They have a sofa they can take a nap on when they feel tired, instead of sitting in a coma at their desk, pretending to work. There's no crew of people with vacuum cleaners that roars through every evening during the prime hacking hours. There are no meetings or, God forbid, corporate retreats or team-building exercises. And when you look at what they're doing on that computer, you'll find it reinforces what I said earlier about tools. They may have to use Java and Windows at work, but at home, where they can choose for themselves, you're more likely to find them using Perl and Linux.

Indeed, these statistics about Cobol or Java being the most popular language can be misleading. What we ought to look at, if we want to know what tools are best, is what hackers choose when they can choose freely-- that is, in projects of their own. When you ask that question, you find that open source operating systems already have a dominant market share, and the number one language is probably Perl.

Interesting

Along with good tools, hackers want interesting projects. What makes a project interesting? Well, obviously overtly sexy applications like stealth planes or special effects software would be interesting to work on. But any application can be interesting if it poses novel technical challenges. So it's hard to predict which problems hackers will like, because some become interesting only when the people working on them discover a new kind of solution. Before ITA (who wrote the software inside Orbitz), the people working on airline fare searches probably thought it was one of the most boring applications imaginable. But ITA made it interesting by redefining the problem in a more ambitious way.

I think the same thing happened at Google. When Google was founded, the conventional wisdom among the so-called portals was that search was boring and unimportant. But the guys at Google didn't think search was boring, and that's why they do it so well.

This is an area where managers can make a difference. Like a parent saying to a child, I bet you can't clean up your whole room in ten minutes, a good manager can sometimes redefine a problem as a more interesting one. Steve Jobs seems to be particularly good at this, in part simply by having high standards. There were a lot of small, inexpensive computers before the Mac. He redefined the problem as: make one that's beautiful. And that probably drove the developers harder than any carrot or stick could.

They certainly delivered. When the Mac first appeared, you didn't even have to turn it on to know it would be good; you could tell from the case. A few weeks ago I was walking along the street in Cambridge, and in someone's trash I saw what appeared to be a Mac carrying case. I looked inside, and there was a Mac SE. I carried it home and plugged it in, and it booted. The happy Macintosh face, and then the finder. My God, it was so simple. It was just like ... Google.

Hackers like to work for people with high standards. But it's not enough just to be exacting. You have to insist on the right things. Which usually means that you have to be a hacker yourself. I've seen occasional articles about how to manage programmers. Really there should be two articles: one about what to do if you are yourself a programmer, and one about what to do if you're not. And the second could probably be condensed into two words: give up.

The problem is not so much the day to day management. Really good hackers are practically self-managing. The problem is, if you're not a hacker, you can't tell who the good hackers are. A similar problem explains why American cars are so ugly. I call it the design paradox. You might think that you could make your products beautiful just by hiring a great designer to design them. But if you yourself don't have good taste, how are you going to recognize a good designer? By definition you can't tell from his portfolio. And you can't go by the awards he's won or the jobs he's had, because in design, as in most fields, those tend to be driven by fashion and schmoozing, with actual ability a distant third. There's no way around it: you can't manage a process intended to produce beautiful things without knowing what beautiful is. American cars are ugly because American car companies are run by people with bad taste.

Many people in this country think of taste as something elusive, or even frivolous. It is neither. To drive design, a manager must be the most demanding user of a company's products. And if you have really good taste, you can, as Steve Jobs does, make satisfying you the kind of problem that good people like to work on.

Nasty Little Problems

It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.

The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. [3] So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers.

Of course some problems inherently have this character. And because of supply and demand, they pay especially well. So a company that found a way to get great hackers to work on tedious problems would be very successful. How would you do it?

One place this happens is in startups. At our startup we had Robert Morris working as a system administrator. That's like having the Rolling Stones play at a bar mitzvah. You can't hire that kind of talent. But people will do any amount of drudgery for companies of which they're the founders. [4]

Bigger companies solve the problem by partitioning the company. They get smart people to work for them by establishing a separate R&D department where employees don't have to work directly on customers' nasty little problems. [5] In this model, the research department functions like a mine. They produce new ideas; maybe the rest of the company will be able to use them.

You may not have to go to this extreme. Bottom-up programming suggests another way to partition the company: have the smart people work as toolmakers. If your company makes software to do x, have one group that builds tools for writing software of that type, and another that uses these tools to write the applications. This way you might be able to get smart people to write 99% of your code, but still keep them almost as insulated from users as they would be in a traditional research department. The toolmakers would have users, but they'd only be the company's own developers. [6]

If Microsoft used this approach, their software wouldn't be so full of security holes, because the less smart people writing the actual applications wouldn't be doing low-level stuff like allocating memory. Instead of writing Word directly in C, they'd be plugging together big Lego blocks of Word-language. (Duplo, I believe, is the technical term.)

Clumping

Along with interesting problems, what good hackers like is other good hackers. Great hackers tend to clump together-- sometimes spectacularly so, as at Xerox Parc. So you won't attract good hackers in linear proportion to how good an environment you create for them. The tendency to clump means it's more like the square of the environment. So it's winner take all. At any given time, there are only about ten or twenty places where hackers most want to work, and if you aren't one of them, you won't just have fewer great hackers, you'll have zero.

Having great hackers is not, by itself, enough to make a company successful. It works well for Google and ITA, which are two of the hot spots right now, but it didn't help Thinking Machines or Xerox. Sun had a good run for a while, but their business model is a down elevator. In that situation, even the best hackers can't save you.

I think, though, that all other things being equal, a company that can attract great hackers will have a huge advantage. There are people who would disagree with this. When we were making the rounds of venture capital firms in the 1990s, several told us that software companies didn't win by writing great software, but through brand, and dominating channels, and doing the right deals.

They really seemed to believe this, and I think I know why. I think what a lot of VCs are looking for, at least unconsciously, is the next Microsoft. And of course if Microsoft is your model, you shouldn't be looking for companies that hope to win by writing great software. But VCs are mistaken to look for the next Microsoft, because no startup can be the next Microsoft unless some other company is prepared to bend over at just the right moment and be the next IBM.

It's a mistake to use Microsoft as a model, because their whole culture derives from that one lucky break. Microsoft is a bad data point. If you throw them out, you find that good products do tend to win in the market. What VCs should be looking for is the next Apple, or the next Google.

I think Bill Gates knows this. What worries him about Google is not the power of their brand, but the fact that they have better hackers. [7]

Recognition

So who are the great hackers? How do you know when you meet one? That turns out to be very hard. Even hackers can't tell. I'm pretty sure now that my friend Trevor Blackwell is a great hacker. You may have read on Slashdot how he made his own Segway. The remarkable thing about this project was that he wrote all the software in one day (in Python, incidentally).

For Trevor, that's par for the course. But when I first met him, I thought he was a complete idiot. He was standing in Robert Morris's office babbling at him about something or other, and I remember standing behind him making frantic gestures at Robert to shoo this nut out of his office so we could go to lunch. Robert says he misjudged Trevor at first too. Apparently when Robert first met him, Trevor had just begun a new scheme that involved writing down everything about every aspect of his life on a stack of index cards, which he carried with him everywhere. He'd also just arrived from Canada, and had a strong Canadian accent and a mullet.

The problem is compounded by the fact that hackers, despite their reputation for social obliviousness, sometimes put a good deal of effort into seeming smart. When I was in grad school I used to hang around the MIT AI Lab occasionally. It was kind of intimidating at first. Everyone there spoke so fast. But after a while I learned the trick of speaking fast. You don't have to think any faster; just use twice as many words to say everything.

With this amount of noise in the signal, it's hard to tell good hackers when you meet them. I can't tell, even now. You also can't tell from their resumes. It seems like the only way to judge a hacker is to work with him on something.

And this is the reason that high-tech areas only happen around universities. The active ingredient here is not so much the professors as the students. Startups grow up around universities because universities bring together promising young people and make them work on the same projects. The smart ones learn who the other smart ones are, and together they cook up new projects of their own.

Because you can't tell a great hacker except by working with him, hackers themselves can't tell how good they are. This is true to a degree in most fields. I've found that people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.

But it's particularly hard for hackers to know how good they are, because it's hard to compare their work. This is easier in most other fields. In the hundred meters, you know in 10 seconds who's fastest. Even in math there seems to be a general consensus about which problems are hard to solve, and what constitutes a good solution. But hacking is like writing. Who can say which of two novels is better? Certainly not the authors.

With hackers, at least, other hackers can tell. That's because, unlike novelists, hackers collaborate on projects. When you get to hit a few difficult problems over the net at someone, you learn pretty quickly how hard they hit them back. But hackers can't watch themselves at work. So if you ask a great hacker how good he is, he's almost certain to reply, I don't know. He's not just being modest. He really doesn't know.

And none of us know, except about people we've actually worked with. Which puts us in a weird situation: we don't know who our heroes should be. The hackers who become famous tend to become famous by random accidents of PR. Occasionally I need to give an example of a great hacker, and I never know who to use. The first names that come to mind always tend to be people I know personally, but it seems lame to use them. So, I think, maybe I should say Richard Stallman, or Linus Torvalds, or Alan Kay, or someone famous like that. But I have no idea if these guys are great hackers. I've never worked with them on anything.

If there is a Michael Jordan of hacking, no one knows, including him.

Cultivation

Finally, the question the hackers have all been wondering about: how do you become a great hacker? I don't know if it's possible to make yourself into one. But it's certainly possible to do things that make you stupid, and if you can make yourself stupid, you can probably make yourself smart too.

The key to being a good hacker may be to work on what you like. When I think about the great hackers I know, one thing they have in common is the extreme difficulty of making them work on anything they don't want to. I don't know if this is cause or effect; it may be both.

To do something well you have to love it. So to the extent you can preserve hacking as something you love, you're likely to do it well. Try to keep the sense of wonder you had about programming at age 14. If you're worried that your current job is rotting your brain, it probably is.

The best hackers tend to be smart, of course, but that's true in a lot of fields. Is there some quality that's unique to hackers? I asked some friends, and the number one thing they mentioned was curiosity. I'd always supposed that all smart people were curious-- that curiosity was simply the first derivative of knowledge. But apparently hackers are particularly curious, especially about how things work. That makes sense, because programs are in effect giant descriptions of how things work.

Several friends mentioned hackers' ability to concentrate-- their ability, as one put it, to "tune out everything outside their own heads.'' I've certainly noticed this. And I've heard several hackers say that after drinking even half a beer they can't program at all. So maybe hacking does require some special ability to focus. Perhaps great hackers can load a large amount of context into their head, so that when they look at a line of code, they see not just that line but the whole program around it. John McPhee wrote that Bill Bradley's success as a basketball player was due partly to his extraordinary peripheral vision. "Perfect'' eyesight means about 47 degrees of vertical peripheral vision. Bill Bradley had 70; he could see the basket when he was looking at the floor. Maybe great hackers have some similar inborn ability. (I cheat by using a very dense language, which shrinks the court.)

This could explain the disconnect over cubicles. Maybe the people in charge of facilities, not having any concentration to shatter, have no idea that working in a cubicle feels to a hacker like having one's brain in a blender. (Whereas Bill, if the rumors of autism are true, knows all too well.)

One difference I've noticed between great hackers and smart people in general is that hackers are more politically incorrect. To the extent there is a secret handshake among good hackers, it's when they know one another well enough to express opinions that would get them stoned to death by the general public. And I can see why political incorrectness would be a useful quality in programming. Programs are very complex and, at least in the hands of good programmers, very fluid. In such situations it's helpful to have a habit of questioning assumptions.

Can you cultivate these qualities? I don't know. But you can at least not repress them. So here is my best shot at a recipe. If it is possible to make yourself into a great hacker, the way to do it may be to make the following deal with yourself: you never have to work on boring projects (unless your family will starve otherwise), and in return, you'll never allow yourself to do a half-assed job. All the great hackers I know seem to have made that deal, though perhaps none of them had any choice in the matter.

Notes


In early modern Europe, the most important quality may have been organization. The kind of brilliance that distinguished Isaac Newton had little practical effect. It would have more now.--> [1] In fairness, I have to say that IBM makes decent hardware. I wrote this on an IBM laptop.

[2] They did turn out to be doomed. They shut down a few months later.

[3] I think this is what people mean when they talk about the "meaning of life." On the face of it, this seems an odd idea. Life isn't an expression; how could it have meaning? But it can have a quality that feels a lot like meaning. In a project like a compiler, you have to solve a lot of problems, but the problems all fall into a pattern, as in a signal. Whereas when the problems you have to solve are random, they seem like noise.

[4] Einstein at one point worked designing refrigerators. (He had equity.)

[5] It's hard to say exactly what constitutes research in the computer world, but as a first approximation, it's software that doesn't have users.

I don't think it's publication that makes the best hackers want to work in research departments. I think it's mainly not having to have a three hour meeting with a product manager about problems integrating the Korean version of Word 13.27 with the talking paperclip.

[6] Something similar has been happening for a long time in the construction industry. When you had a house built a couple hundred years ago, the local builders built everything in it. But increasingly what builders do is assemble components designed and manufactured by someone else. This has, like the arrival of desktop publishing, given people the freedom to experiment in disastrous ways, but it is certainly more efficient.

[7] Google is much more dangerous to Microsoft than Netscape was. Probably more dangerous than any other company has ever been. Not least because they're determined to fight. On their job listing page, they say that one of their "core values'' is "Don't be evil.'' From a company selling soybean oil or mining equipment, such a statement would merely be eccentric. But I think all of us in the computer world recognize who that is a declaration of war on.

Thanks to Jessica Livingston, Robert Morris, and Sarah Harlin for reading earlier versions of this talk.


Audio of talk

The Python Paradox

Japanese Translation

Russian Translation

Italian Translation

Spanish Translation



not loaded
-->
If you liked this, you may also like Hackers & Painters.
0){R=R.substring(X,R.length)}else{return W}R=R.replace(new RegExp("([^a-zA-Z0-9$_])this([^a-zA-Z0-9$_])","g"),"$1xzq_this$2");var Z=T+";var rv = f( "+Y+",this);";var S="{var a0 = '"+Y+"';var ofb = '"+escape(R)+"' ;var f = new Function( a0, 'xzq_this', unescape(ofb));"+Z+"return rv;}";return new Function(Y,S)}else{return W}}return V}window.xzq_eh=function(){if(E||I){this.onload=L("xzq_onload(e)",K,this.onload,0);if(E&&typeof (this.onbeforeunload)!=O){this.onbeforeunload=L("xzq_dobeforeunload(e)",B,this.onbeforeunload,0)}}};window.xzq_s=function(){setTimeout("xzq_sr()",1)};var J=null;var M=null;var Q=navigator.appName;var H=navigator.appVersion;var G=navigator.userAgent;var A=parseInt(H);var D=Q.indexOf("Microsoft");var E=D!=-1&&A>=4;var I=(Q.indexOf("Netscape")!=-1||Q.indexOf("Opera")!=-1)&&A>=4;var O="undefined";var P=2000})();

http://www.paulgraham.com/gh.html

Posted via email from DailyDDoSe