- cypherpunks-legacy - lists.cpunks.org

Re: [btns] Q: How to deal with connection latch breaks?
by Mike Eisler 06 Jul '18

06 Jul '18

Note: This is my first email to this list. The catalyst for this email was that several documents that I'm authoring indirectly depend on draft-ietf-btns-connection-latching moving forward ... > The last DISCUSS on draft-ietf-btns-connection-latching-10 > concerns what the WG thinks is the best way for ULPs to > handle connection latch transitions to the BROKEN state in > the _absence_ of connection latching APIs for applications > (or when apps are not aware of such APIs). Isn't this DISCUSS specific to SCTP? Russ writes in the DISCUSS: I am unsure that the SCTP section defines behavior which is consistent with application expectations. The last paragraph of 5.4 implies that the whole connection terminates if one of the latches breaks. This has an impact on the semantics of the application socket API. While connection latching is transparent when everything is working, there are new failures that ripple to the application. That is, the application will observe different behavior on a connection with and without latching. My conclusion is that the API ought to provide information for the application about the connection latching, and it just does not seem to be there. If you can point me to a discussion of this topic on the WG mail list, then I'll clear. I'm not trying to alter consensus, but I do want to make sure that this topic was considered. ====================== The laat paragraph of section 5.4 says: "When a connection latch transitions to the BROKEN state and the application requested (or system policy dictates it) that the connection be broken, then SCTP should inform the application, if there is a way to do so, or else it should wait, allowing SCTP path/ endpoint failure detection (and/or application-layer keepalive strategy) to timeout the connection. When a connection latch is administratively transitioned to the CLOSED state then SCTP should act as though an ABORT chunk has been received." Note the inconsistency between what Russ wrote in his DISCUSS: "The last paragraph of 5.4 implies that the whole connection terminates if one of the latches breaks." and this excerpt from the last paragraph of section 5.4: "When a connection latch transitions to the BROKEN state and the application requested (or system policy dictates it) that the connection be broken," So actually the last paragraph is unequivocal: the connection does terminate if two conditions are met: - the latch goes to BROKEN - the app or policy has previously dictated that a latch break produces a connection break. Earlier in Section 5.4, two alternatives to mapping latches to multi-homed SCTP connections: "We can represent the multiplicity of SCTP association end-point addresses as a multiplicity of 5-tuples, each of which with its own a connection latch. Alternatively we can extend the connection latch object to support a multiplicity of addresses for each end-point. The first approach is used throughout this document, therefore we will assume that representation." Perhaps the second approach is what should be used for SCTP. However, as the last sentence above notes, the first approach is used in the rest of the document. I gather what Russ is saying is that approach might not be appropriate for SCTP and he wants to know if the WG thoroughly considered it. In the event the WG did not thoroughly consider the implications of multi-homed SCTP connections and latching, here is a pragmatic suggestion: - remove the SCTP discussion from the I-D. Most this means removing section 5.4, but there are a couple sentences that mention SCTP that would also need to be removed. - if there is sufficient interest in SCTP and connection latching, channel binding, etc., then start a new work item to deal with the issue of connection latching with multi-homed connection-oriented transports. ------------------------------------------------------- Nico wrote: * From: Nicolas Williams <Nicolas.Williams at sun.com> * To: btns at ietf.org * Date: Wed, 24 Jun 2009 15:17:07 -0500 The last DISCUSS on draft-ietf-btns-connection-latching-10 concerns what the WG thinks is the best way for ULPs to handle connection latch transitions to the BROKEN state in the _absence_ of connection latching APIs for applications (or when apps are not aware of such APIs). The two options are: a) The ULP MAY/SHOULD/MUST pretend that the equivalent of a TCP reset occurred and the connection latch is transition to the CLOSED state (and destroyed/cleaned up); b) The ULP MAY/SHOULD/MUST act as though bits aren't moving and let ULP and/or application-layer timeout processing decide if and when to close the connection (and underlying connection latch). (b) means potentially hanging forever, but that's generally true now with existing ULPs. The I-D says (b), with "SHOULD". I'd be just as happy with (a), SHOULD, (b) MAY. I would not be happy with (a), MUST, nor with (b), MUST. Comments? Nico -- -- Mike Eisler, Senior Technical Director, NetApp, 719 599 9026, http://blogs.netapp.com/eislers_nfs_blog/ -- Mike Eisler, Senior Technical Director, NetApp, 719 599 9026, http://blogs.netapp.com/eislers_nfs_blog/ _______________________________________________ btns mailing list btns(a)ietf.org https://www.ietf.org/mailman/listinfo/btns ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

bounty for errors in _Translucent Databases_
by Peter Wayner 06 Jul '18

06 Jul '18

To: All readers of Translucent Databases. I'm starting work on the second edition of _Translucent Databases_. To help eliminate errors, I'm quadrupling the bounty for error reports to $20 per error. I may also pay for suggestions for improving it, but that's harder to codify. For info on the book, see this website: http://www.wayner.org/books/td/ The only rules are designed to prevent people from using this offer to print money: only the first person to report each error gets $20. I reserve the right to relax this rule to pay multiple people who don't seem to be colluding. I get to decide what constitutes an technical error and how big an error might be. For instance, if I screwed up and listing pi=3.41592..., I get to decide that this is only one error. It's not an infinite set of errors because the first digit after the decimal point is not 4, the second digit is not 1, the third digit is not 5, etc. Also, non-technical errors don't qualify, although I'm grateful to get them. To see previously reported errors: http://www.wayner.org/books/td/errors.php I promise to try to apply these rules as generously as possible. -Peter --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Re: [btns] Q: How to deal with connection latch breaks?
by Mike Eisler 06 Jul '18

06 Jul '18

Note: This is my first email to this list. The catalyst for this email was that several documents that I'm authoring indirectly depend on draft-ietf-btns-connection-latching moving forward ... > The last DISCUSS on draft-ietf-btns-connection-latching-10 > concerns what the WG thinks is the best way for ULPs to > handle connection latch transitions to the BROKEN state in > the _absence_ of connection latching APIs for applications > (or when apps are not aware of such APIs). Isn't this DISCUSS specific to SCTP? Russ writes in the DISCUSS: I am unsure that the SCTP section defines behavior which is consistent with application expectations. The last paragraph of 5.4 implies that the whole connection terminates if one of the latches breaks. This has an impact on the semantics of the application socket API. While connection latching is transparent when everything is working, there are new failures that ripple to the application. That is, the application will observe different behavior on a connection with and without latching. My conclusion is that the API ought to provide information for the application about the connection latching, and it just does not seem to be there. If you can point me to a discussion of this topic on the WG mail list, then I'll clear. I'm not trying to alter consensus, but I do want to make sure that this topic was considered. ====================== The laat paragraph of section 5.4 says: "When a connection latch transitions to the BROKEN state and the application requested (or system policy dictates it) that the connection be broken, then SCTP should inform the application, if there is a way to do so, or else it should wait, allowing SCTP path/ endpoint failure detection (and/or application-layer keepalive strategy) to timeout the connection. When a connection latch is administratively transitioned to the CLOSED state then SCTP should act as though an ABORT chunk has been received." Note the inconsistency between what Russ wrote in his DISCUSS: "The last paragraph of 5.4 implies that the whole connection terminates if one of the latches breaks." and this excerpt from the last paragraph of section 5.4: "When a connection latch transitions to the BROKEN state and the application requested (or system policy dictates it) that the connection be broken," So actually the last paragraph is unequivocal: the connection does terminate if two conditions are met: - the latch goes to BROKEN - the app or policy has previously dictated that a latch break produces a connection break. Earlier in Section 5.4, two alternatives to mapping latches to multi-homed SCTP connections: "We can represent the multiplicity of SCTP association end-point addresses as a multiplicity of 5-tuples, each of which with its own a connection latch. Alternatively we can extend the connection latch object to support a multiplicity of addresses for each end-point. The first approach is used throughout this document, therefore we will assume that representation." Perhaps the second approach is what should be used for SCTP. However, as the last sentence above notes, the first approach is used in the rest of the document. I gather what Russ is saying is that approach might not be appropriate for SCTP and he wants to know if the WG thoroughly considered it. In the event the WG did not thoroughly consider the implications of multi-homed SCTP connections and latching, here is a pragmatic suggestion: - remove the SCTP discussion from the I-D. Most this means removing section 5.4, but there are a couple sentences that mention SCTP that would also need to be removed. - if there is sufficient interest in SCTP and connection latching, channel binding, etc., then start a new work item to deal with the issue of connection latching with multi-homed connection-oriented transports. ------------------------------------------------------- Nico wrote: * From: Nicolas Williams <Nicolas.Williams at sun.com> * To: btns at ietf.org * Date: Wed, 24 Jun 2009 15:17:07 -0500 The last DISCUSS on draft-ietf-btns-connection-latching-10 concerns what the WG thinks is the best way for ULPs to handle connection latch transitions to the BROKEN state in the _absence_ of connection latching APIs for applications (or when apps are not aware of such APIs). The two options are: a) The ULP MAY/SHOULD/MUST pretend that the equivalent of a TCP reset occurred and the connection latch is transition to the CLOSED state (and destroyed/cleaned up); b) The ULP MAY/SHOULD/MUST act as though bits aren't moving and let ULP and/or application-layer timeout processing decide if and when to close the connection (and underlying connection latch). (b) means potentially hanging forever, but that's generally true now with existing ULPs. The I-D says (b), with "SHOULD". I'd be just as happy with (a), SHOULD, (b) MAY. I would not be happy with (a), MUST, nor with (b), MUST. Comments? Nico -- -- Mike Eisler, Senior Technical Director, NetApp, 719 599 9026, http://blogs.netapp.com/eislers_nfs_blog/ -- Mike Eisler, Senior Technical Director, NetApp, 719 599 9026, http://blogs.netapp.com/eislers_nfs_blog/ _______________________________________________ btns mailing list btns(a)ietf.org https://www.ietf.org/mailman/listinfo/btns ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

bounty for errors in _Translucent Databases_
by Peter Wayner 06 Jul '18

06 Jul '18

To: All readers of Translucent Databases. I'm starting work on the second edition of _Translucent Databases_. To help eliminate errors, I'm quadrupling the bounty for error reports to $20 per error. I may also pay for suggestions for improving it, but that's harder to codify. For info on the book, see this website: http://www.wayner.org/books/td/ The only rules are designed to prevent people from using this offer to print money: only the first person to report each error gets $20. I reserve the right to relax this rule to pay multiple people who don't seem to be colluding. I get to decide what constitutes an technical error and how big an error might be. For instance, if I screwed up and listing pi=3.41592..., I get to decide that this is only one error. It's not an infinite set of errors because the first digit after the decimal point is not 4, the second digit is not 1, the third digit is not 5, etc. Also, non-technical errors don't qualify, although I'm grateful to get them. To see previously reported errors: http://www.wayner.org/books/td/errors.php I promise to try to apply these rules as generously as possible. -Peter --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

<nettime> we are all damned
by Alan Sondheim 06 Jul '18

06 Jul '18

[post dorner rhetoric: read this: "San Bernardino County sheriff.s officials said they tried to force the suspect to surrender before accidentally setting the cabin where he was holed up on fire when they shot a pyrotechnic chemical device inside." Yes - "accidently" because "pryotechnic" devices are "accidental."] we are all damned Yea, the that's navy, why a he police was officer, in hunted the officers, navy, and a Yea, police that's officer, why hunted he officers, was and in engaged won them several won firefights. several Does firefights. ignoring Does reality ignoring to reality preserve to engaged preserve them your make happy you little feel view better? of The world is make that you murdered feel your better? happy The little is view that of murdered world innocent(and people. unarmed coward....with people. "c". coward....with Well "c". when Well try when rat try out rat innocent(and out unarmed corrupted they law start enforcement their they attacks start against their you? attacks what against else you? corrupted what law else enforcement do. innocent You people, all how claim do killed we innocent know? people, Because how same do do. we You know? all Because claim same killed cops criminals revealed said be so? criminals Not said defending so? him, Not just defending playing him, cops just revealed playing be devil's with advocate. his Plus, training, with I his highly training, doubt I hes highly dead. doubt devil's hes advocate. dead. Plus, believe before did SOTU, end humiliation it fact before couldnt SOTU, stop humiliation one fact man... couldnt believe stop did one end man... it We on shall record see. (which were msnbc caught fox on news record or (which any msnbc We fox shall news see. or were any caught mainstream burn would house never down. air), amy saying not burn agree house but down. few amy mainstream not would agree never but air), few saying things They made cared obvious: for They Due cared Process for Constitutional Due right Process tried Constitutional things right made tried obvious: by ALL jury factual peers, evidence WITH presented. ALL Was factual first evidence American presented. US Was by first jury American peers, US WITH Soil if authorized spotted drone (we strike see if well spotted those (we go see overseas, well Soil those authorized go drone overseas, strike 1200 dead children counting). dead Regardless counting). criminal, Regardless our criminal, judicial our system judicial has system 1200 has children shown swore care uphold. law, know swore EVERYTHING uphold. transpired know here, EVERYTHING this transpired real here, shown this care real law, story, are is, expected re it. told calling thing him are hero, expected again, it. Devil's calling story, him is, hero, re again, told Devil's thing Advocate. been He brought should court have PEERS, been public brought forum, court so PEERS, could public Advocate. forum, He so should could have reveal add side, more WHY this, did.. about To who add fired more people this, due about reveal who side, fired WHY people did.. due To mistaken where identity, investigation where criminal investigation charges criminal into charges that? into 41 that? 71 41 mistaken 71 identity, year hispanic old women hispanic cretainly women meet cretainly description, meet truck description, had truck burned, had year burned, old still it? looking What it? mean What miserably mean failed miserably officer failed lied officer female lied still female looking supervisor own cover mistakes own like mistakes tiny like man tiny was, man completely was, couple completely supervisor couple cover included success young loser black two success good loser officers two didn't good even officers brains didn't included even young brains black get creep mexico brother every (of creep nationality) brother successfully (of fled. nationality) Too successfully bad fled. get Too mexico bad every take that, aim since at don't you, seem that, appreciate since person don't situation seem hurt appreciate take person aim situation at hurt you, care, defend whether not. defend "The not. people" "The So people" soldiers, So police, soldiers, homicidal police, care, homicidal whether maniacs, etc... psychopaths, lack etc... fear. lack That fear. makes That murderer makes nothing murderer more. nothing maniacs, more. psychopaths, Feeling need need label label someone someone something something solely solely appease appease feelings feelings weakness. weakness. Feeling honey, 13 ive olds, shot i 13 protect olds, CONSTITUTION i enemies protect foreign CONSTITUTION domestic. enemies honey, foreign ive domestic. shot Just do, because will dont give it, my doesnt life dont. rights, do, no will amtter give Just my because life dont rights, it, no doesnt amtter dont. other SWORE deserves TO. not, Glad why, can SWORE LAPD TO. proven Glad capable can wrose LAPD other proven deserves capable not, wrose why, crimes. back If barn, MSNBC sheep. then But back open barn, mind sheep. possibility But being open crimes. mind If possibility MSNBC being then full three story... sides there everything, three Side sides A, everything, B, Side truth. A, Usually, B, full truth. story... Usually, there places both cnn, Hence A mostly B. troll Never these both pages Hence use mostly some troll places these cnn, pages A use B. some Never critical REALLY? thinking. bold REALLY? faced bold liar! faced STAND liar! FOR STAND NOTHING!!! FOR Donser NOTHING!!! critical Donser thinking. DEFENDED also HIM, lawyer, HE righteous LOST!! sue? also His lawyer, actions righteous PROVE sue? HIS His DEFENDED actions HIM, PROVE HE HIS LOST!! CHARACTER!!! YOUR YOUR WORDS WORDS YOURS!!!!! YOURS!!!!! It It sounds sounds yourself, yourself, bitterness bitterness NOT NOT CHARACTER!!! result righteousness!! result Your righteousness!! statements Your pure statements slander, pure shows slander, anti-government, anti-government, anti anti rhetoric. rhetoric. military, military, many many terrorists terrorists blew blew up up airlines, Camp nutcase Pendleton, opened does Camp heroes! Pendleton, sir does an heroes! idiot! sir Bold an airlines, idiot! nutcase Bold opened liar? seen Have track seen enforcement? track Anti enforcement? government? Anti Maybe, government? ruin Maybe, everything ruin liar? everything Have touch. anything tell profits. truth, Im anything slandering profits. anyone, Im mind. slandering My anyone, county mind. touch. My tell county truth, sheriffs, them. Damn Why? proud arent them. giving Why? gun arent control giving crap gun congress control sheriffs, crap Damn congress proud trying going pass refuse (IE orders going confiscation). refuse Ive orders am confiscation). abiding. Ive follow am trying abiding. pass follow (IE law. helping Part down time computer helping skills. down me, computer accuse skills. slander. me, Hypocrasy accuse law. slander. Part Hypocrasy time its think? finest, bitter, think? learned bitter, long learned ago long thinking ago research, thinking ask research, its ask finest, questions. sir, Apparently, wish sir, luck wish future. luck shooting future. 2 shooting elderly 2 women, elderly questions. women, Apparently, obviously Chris looked Dorner.. Chris Dorner Dorner.. given Dorner fair given trial. fair Judge trial. Yafee Judge obviously Yafee looked accepted over over $500,000.00 $500,000.00 illegal illegal payments. payments. lie lie judges judges bribed. bribed. This This accepted petition petition corrupt corrupt entities entities investigated investigated excessive excessive force. force. Sign Sign remember remember deadline webpage . facebook Post email webpage friends, facebook co email workers, friends, family co victims workers, deadline family . victims Post simply based harassed ethnicity based want ethnicity big want Brother big watching Brother too watching stroke too simply stroke harassed out... valid valid gripes... gripes... kill kill innocents?? innocents?? lose lose vote! vote! significant significant strides strides out... circuit.. outfit... maybe rest better peace ver from outfit... me... rest a: peace sorry from cope, me... circuit.. a: maybe sorry better cope, ver sad. apparently Let im me stupid apparently blind im 'real stupid truth', blind government 'real always truth', sad. government Let always me right... Marijuana Do (and really ahve Marijuana smoked (and anyone ahve suggests smoked such anyone thing.) suggests right... such Do thing.) really making cause legal crime cause rate crime soar/open rate harder soar/open drugs/kill harder people? drugs/kill may people? making may legal treated fairly fairly firing firing LAPD. LAPD. license license except except under under most most perverse perverse treated interpretation Second interpretation Amendment Second which, Amendment unfortunately, which, nuts unfortunately, advocating. nuts sympathy murderer; murderer; but, but, honest. honest. "accidentally" "accidentally" set set place place afire afire pyrotechnic pyrotechnic sympathy device.!? problem Really? doing problem purpose doing believed purpose safest believed way safest avoid way others avoid device.!? others Really? injured common killed, sense! defies wants common - sense! And wants blatantly - recorded And audio blatantly injured recorded killed, audio defies video... less... top won't prior about? less... taken won't revenge about? screwed taken then, revenge ok. screwed video... then, top ok. prior wrong. Only Only Mafia, Mafia, officials officials that. that. ONE ONE named named manifesto, manifesto, consider consider wrong. dedicated. dedicated. took took "opportunistic" "opportunistic" approach, approach, which which labels labels coward. coward. dedication dedication words, words, decided decided easiest easiest course course action, action, innocent, innocent, unsuspecting unsuspecting victims. victims. cannot stand stand behind behind nothing. nothing. Can't Can't comments. comments. next next think think wrongfully wrongfully cannot treated, treated, gather gather arsenal; arsenal; issue issue manifesto; manifesto; constitution constitution God-given God-given so. so. raping boss pillaging. disciplined boss today, disciplined I'm today, everyone. I'm At everyone. least At posters least raping posters pillaging. newsvine gonna gonna ever ever way..you way..you supporters supporters way. way. heard heard wrongs wrongs right?..neither right?..neither newsvine 4..idiots. process say trial? denied turned process himself trial? in. turned knew himself die in. sure knew 4..idiots. die say sure denied wasn't turn captured done. turn through done. another through agency, another wanted. agency, used wanted. wonder used wasn't wonder captured considering seems seems be, be, looks looks indeed indeed INNOCENT INNOCENT couple. couple. Supposedly, Supposedly, taunted taunted considering father chief (ex-police Quan, chief defended Quan, during defended inquiry) during thought inquiry) Quan thought fight Quan father fight (ex-police felt Court. got So, deal help Kangaroo him. Court. Still, So, daughter help her him. fiance. Still, felt daughter got her deal fiance. Kangaroo horrible. NO There EXCUSE NO killing EXCUSE tear killing gas--NOT tear pyrotechnics. gas--NOT Tear pyrotechnics. gas Tear horrible. gas There notorious starting starting fires fires flame flame sparks sparks (short (short electricity electricity off). off). fire fire notorious accidental. #1.22 anyway. Fri Maybe Feb off 15, gas. 2013 #1.22 10:27 Fri PM Feb EST 15, accidental. 2013 anyway. 10:27 Maybe PM off EST gas. # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mx.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

ip: Soldiers test `Digital MP System'
by believer＠telepath.com 06 Jul '18

06 Jul '18

<http://www.dtic.mil/armylink/news/Nov2000/a20001113digitalmp.html> Soldiers test `Digital MP System' by Trish Warrick FORT POLK, La. (Army News Service, Nov. 13, 2000) Military Police could see around corners, through trees and in the dark as they tested the Army's new "Digital MP System" this month at Fort Polk, La. Patrolmen wore eyeglass-mounted miniature cameras providing "streaming video" to their partners. Viewing screens in the eyeglasses also allowed the MPs to check the faces of suspects they stopped against digital mug shots of known offenders. Fort Polk's 91st Military Police Detachment soldiers became the first MPs to test the system Oct. 30 to Nov. 3. Representatives of the U.S. Army Soldier Systems Center in Natick, Mass., brought the Digital MP System to Fort Polk. They were joined by members of the Defense Advanced Research Projects Agency and a number of contractor teams wanting to see how the system would work on real soldiers. The Digital MP is a durable, lightweight, wearable communications and information management system designed to help carry out reconnaissance, checkpoint security, anti-terrorism operations and other MP missions, said program manager Henry Girolamo, Natick Soldiers Center. The backbone of the Digital MP is a wearable computer developed by ViA Inc., MicroOptical Corp and Honeywell Inc. and tailored to the mission requirements of the MP soldier, Girolamo said. The Digital MP's support features include a hands-free, voice-operated interface and a battery that provides day-long power on a single charge. It features peripherals such as: * An audiovisual system with built-in miniature camera for face recognition and image display plus a noise-cancelling microphone and bone-conduction microphone/earphone for voice recognition, all incorporated in a pair of normal-size eyeglass frames * A BDU-pocket-sized "military e-book" readable even in strong sunlight or pale starlight (with night vision goggles) that emits no light to give away a soldier's position * An electronic glove that can function like a computer mouse with the e-book and translate hand signals into words on other soldiers' eyeglass-mounted viewers The Digital MP system can connect a military police team wirelessly and in ways never before possible, officials said. The eyeglass-mounted camera provides streaming video, which means "it can transmit to me what another MP is looking at even though I can't see him," said Sgt. Michael Sauer, Special Reaction Team noncommissioned officer in charge, 91st MP Det. An MP making a traffic stop or manning a checkpoint can take live videos which are checked against digital mug shots stored in the National Crime Interdiction Center database, Sauer said, so he's quickly alerted if the person stopped has a criminal record. On deployment, the system can warn him that he's dealing with a suspected terrorist or war criminal. An MP on patrol can use the e-book to quickly help others locate what he sees. "Say he's on recon, looking at the terrain," said Sauer. "He sees enemy tanks." Using traditional methods, the soldier plots coordinates on a paper map, calls the TOC on the radio and another soldier plots the coordinates on another map. With Digital MP, "He puts the icon on the map and sends it to the operations center," Sauer said. With the electronic glove, MPs separated by thick woods, buildings or darkness can still communicate silently with the familiar hand signals for "Suspect armed!" and other vital information. The adapted Nomex flight glove, with bend sensors in each finger and in the wrist, pressure sensors in the index and middle fingertips and 2-degree tilt sensors, renders preprogrammed gestures as words in fellow MPs' eyeglass display monitors. The glove works when the signaler doesn't have line of sight communication with the others and doesn't want to give away his position by speaking, said Sauer. The glove also functions like a mouse with the e-book, guiding the cursor with the tilt sensor and using the pressure sensors as right and left clicks. When silence is necessary, as on patrol, the glove can override the voice-operated system. The Digital MP can be programmed to continuously translate speech from English to another language and vice versa with only a five-second lag. Presently it can handle Spanish, Korean, Arabic, German, French, Italian, Portuguese, Dutch, Thai and Turkish, and officials said they plan to add "militarese" -- translating the soldier's "clicks" into the civilian's "kilometers," for instance. (Editor's note: Trish Warrick is editor of the Fort Polk Guardian.) --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

DARPA markets on MidEast
by Robin Hanson 06 Jul '18

06 Jul '18

I've been involved for several years in helping DARPA to create some markets to help aggregate info on political, military, and economic changes in the Middle East, and the effect of US policy on such changes. For those interested, we are finally going public with some info on these markets: www.PolicyAnalysisMarket.org Robin Hanson [EMAIL PROTECTED] http://hanson.gmu.edu Assistant Professor of Economics, George Mason University MSN 1D3, Carow Hall, Fairfax VA 22030-4444 703-993-2326 FAX: 703-993-2323 -----

1 0

[IP] Markle Task Force Report | July 13, 2006
by David Farber 06 Jul '18

06 Jul '18

Markle Task Force on National Security in the Information Age Releases Third Report "Mobilizing Information to Prevent Terrorism: Accelerating Development of a Trusted Information Sharing Environment" July 13, 2006 The Markle Foundation Task Force on National Security in the Information Age today released its third report with recommendations on how to reconcile national security needs with civil liberties requirements. The report offers a new "authorized use" standard for government handling of legally collected information that bases authorization to view information on how the information is going to be used, rather than on the nationality of the subject or the location of collection. The report also proposes a new risk management approach to sharing classified information that balances the risk of leaks of classified information with the security risk that can come from failing to share information with those who need it to understand the threats to national security. Further, the report identifies examples of technology that can be used effectively to provide appropriate oversight and accountability. For a copy of the report, please visit our website at: http:// www.markle.org To read the Markle Foundation press release, click here. Web Policies | Copyright ) 2006 The Markle Foundation ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[tahoe-announce] ANNOUNCING Tahoe-LAFS v1.7N2! Please test!
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

Folks: The Tahoe-LAFS volunteer hackers have done a superb job for the last few weeks, iteratively testing and refining the major new features of Tahoe-LAFS v1.7. The current version passes our comprehensive test suite on many platforms (see the Buildbot [1] especially the "Supported Platforms" section). This is officially Tahoe-LAFS v1.7.0N2! The plan is that this version will become v1.7.0 final except for improving the documentation and packaging, and fixing any critical bugs that turn up. Tahoe-LAFS v1.7 is going to be a major new release, adding important features and continuing our strong tradition of reliability and compatibility. WHAT'S NEW There are three major new features (not counting various small bugfixes and improvements): SFTP support, support for non-ASCII character encodings, and Servers of Happiness. * SFTP support Your Tahoe-LAFS gateway now acts like a full-fledged SFTP server. It has been tested with sshfs to provide a virtual filesystem in Linux. Many users have asked for this feature. We hope that it serves them well! See the FTP-and-SFTP.txt document [2] to get started. * support for non-ASCII character encodings Tahoe-LAFS now correctly handles filenames containing non-ASCII characters on all supported platforms: - when reading files in from the local filesystem (such as when you run "tahoe backup" to back up your local files to a Tahoe-LAFS grid); - when writing files out to the local filesystem (such as when you run "tahoe cp -r" to recursively copy files out of a Tahoe-LAFS grid); - when displaying filenames to the terminal (such as when you run "tahoe ls"), subject to limitations of the terminal and locale; - when parsing command-line arguments, except on Windows (to be fixed on Windows in a future release) * Servers of Happiness Tahoe-LAFS now measures during immutable file upload to see how well distributed it is across multiple servers. It aborts the upload if the pieces of the file are not sufficiently well-distributed. This behavior is controlled by a configuration parameter called "servers of happiness". With the default settings for its erasure coding, Tahoe-LAFS generates 10 shares for each file, such that any 3 of those shares are sufficient to recover the file. The default value of "servers of happiness" is 7, which means that Tahoe-LAFS will guarantee that there are at least 7 servers holding some of the shares, such that any 3 of those servers can completely recover your file. The new upload code also distributes the shares better than the previous version in some cases and takes better advantage of pre-existing shares (when a file has already been previously uploaded). See the architecture.txt document [3] for details. HOW TO GET STARTED Follow the instructions in the quickstart.html document [4]. CAVEATS Do not be too disappointed if you discover the following performance issue. While this release makes it possible to use Tahoe-LAFS as a mostly POSIX-compliant filesystem (thanks to FUSE and sshfs), it will have very bad performance for some cases which have good performance on your traditional local filesystem. In particular it is bad at making small changes to large files (it actually stores the new file contents every time you write to the file and re-uploads the entire file every time you close it after having written to it). On the other hand it has some nice scalability and load-balancing characteristics compared to traditional POSIX filesystemsbyou will be able to easily add tens or hundreds of computers to your distributed, shared Tahoe-LAFS filesystem and it will take advantage of them in a nice distributed pattern without going noticeably slower than if you had a single Tahoe-LAFS server. So, you should not assume that the POSIX emulation of Tahoe-LAFS v1.7 will perform sufficiently well at a particular use case or load pattern until you've tried it, but if you do try it and it does perform acceptably well then you can feel confident that it will continue to perform that well as you scale out your filesystem. Improving the performance in some dimensions is one of the goals of the Google Summer of Code Project which will result in Tahoe-LAFS v1.8 this Fall (northern hemisphere). COMPATIBILITY This release continues the tradition of full backward-compatibility. Use it without fear. ENJOY! We think Tahoe-LAFS is a really cool hack with great potential. That's why we spend our time on it as a labor of love. We hope you find good uses for it. Regards, Zooko, release manager of v1.7 [1] http://tahoe-lafs.org/buildbot/ [2] http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/frontends/FTP-and-SFTP.t… [3] http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/architecture.txt [4] http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.html _______________________________________________ tahoe-announce mailing list tahoe-announce(a)allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-announce ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[tahoe-announce] ANNOUNCING Tahoe-LAFS v1.7N2! Please test!
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

Folks: The Tahoe-LAFS volunteer hackers have done a superb job for the last few weeks, iteratively testing and refining the major new features of Tahoe-LAFS v1.7. The current version passes our comprehensive test suite on many platforms (see the Buildbot [1] especially the "Supported Platforms" section). This is officially Tahoe-LAFS v1.7.0N2! The plan is that this version will become v1.7.0 final except for improving the documentation and packaging, and fixing any critical bugs that turn up. Tahoe-LAFS v1.7 is going to be a major new release, adding important features and continuing our strong tradition of reliability and compatibility. WHAT'S NEW There are three major new features (not counting various small bugfixes and improvements): SFTP support, support for non-ASCII character encodings, and Servers of Happiness. * SFTP support Your Tahoe-LAFS gateway now acts like a full-fledged SFTP server. It has been tested with sshfs to provide a virtual filesystem in Linux. Many users have asked for this feature. We hope that it serves them well! See the FTP-and-SFTP.txt document [2] to get started. * support for non-ASCII character encodings Tahoe-LAFS now correctly handles filenames containing non-ASCII characters on all supported platforms: - when reading files in from the local filesystem (such as when you run "tahoe backup" to back up your local files to a Tahoe-LAFS grid); - when writing files out to the local filesystem (such as when you run "tahoe cp -r" to recursively copy files out of a Tahoe-LAFS grid); - when displaying filenames to the terminal (such as when you run "tahoe ls"), subject to limitations of the terminal and locale; - when parsing command-line arguments, except on Windows (to be fixed on Windows in a future release) * Servers of Happiness Tahoe-LAFS now measures during immutable file upload to see how well distributed it is across multiple servers. It aborts the upload if the pieces of the file are not sufficiently well-distributed. This behavior is controlled by a configuration parameter called "servers of happiness". With the default settings for its erasure coding, Tahoe-LAFS generates 10 shares for each file, such that any 3 of those shares are sufficient to recover the file. The default value of "servers of happiness" is 7, which means that Tahoe-LAFS will guarantee that there are at least 7 servers holding some of the shares, such that any 3 of those servers can completely recover your file. The new upload code also distributes the shares better than the previous version in some cases and takes better advantage of pre-existing shares (when a file has already been previously uploaded). See the architecture.txt document [3] for details. HOW TO GET STARTED Follow the instructions in the quickstart.html document [4]. CAVEATS Do not be too disappointed if you discover the following performance issue. While this release makes it possible to use Tahoe-LAFS as a mostly POSIX-compliant filesystem (thanks to FUSE and sshfs), it will have very bad performance for some cases which have good performance on your traditional local filesystem. In particular it is bad at making small changes to large files (it actually stores the new file contents every time you write to the file and re-uploads the entire file every time you close it after having written to it). On the other hand it has some nice scalability and load-balancing characteristics compared to traditional POSIX filesystemsbyou will be able to easily add tens or hundreds of computers to your distributed, shared Tahoe-LAFS filesystem and it will take advantage of them in a nice distributed pattern without going noticeably slower than if you had a single Tahoe-LAFS server. So, you should not assume that the POSIX emulation of Tahoe-LAFS v1.7 will perform sufficiently well at a particular use case or load pattern until you've tried it, but if you do try it and it does perform acceptably well then you can feel confident that it will continue to perform that well as you scale out your filesystem. Improving the performance in some dimensions is one of the goals of the Google Summer of Code Project which will result in Tahoe-LAFS v1.8 this Fall (northern hemisphere). COMPATIBILITY This release continues the tradition of full backward-compatibility. Use it without fear. ENJOY! We think Tahoe-LAFS is a really cool hack with great potential. That's why we spend our time on it as a labor of love. We hope you find good uses for it. Regards, Zooko, release manager of v1.7 [1] http://tahoe-lafs.org/buildbot/ [2] http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/frontends/FTP-and-SFTP.t… [3] http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/architecture.txt [4] http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.html _______________________________________________ tahoe-announce mailing list tahoe-announce(a)allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-announce ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0