tmsr - Search: embrace extend

asciilifeform in 2010-12 'surely usg will muster king's horses and king's men' days , did not expect it to look like gavin, expected moar microshit-style 'embrace&extend', e.g. 'ibm bitcoin client' or sumsuch

a111: Logged on 2015-01-10 06:25 asciilifeform: mats: gcc... a) i dont get it... << what's the hard concept here? rms wishes to avoid gcc turning into a sweet and defenceless piece of candy for the 'embrace & extend/extinguish' folks.

billymg: http://btcbase.org/log/2018-10-23#1865377 << BingoBoingo: nice. imo it's a great way to respond. "oh a CoC? why yes, great idea! in fact let's take it one step further" -- a sort of embrace, extend, extinguish strategy ☝︎

asciilifeform: BingoBoingo: usg is on an 'embrace & extend' tack. not simply the pot thing, either -- consider, 'uber', 'airbnb', etc through lens of 'attempts to make unemployed zeks, driven into piecework, to document income & pay tax'

asciilifeform: wanted to 'modernize', hipsterize, embrace an' extend, have-followers, komyoonity, 'governance', rubberchickenconferences

asciilifeform: and that folks who want to 'embrace and extend' phuctor are on their own.

asciilifeform: currently they have folks sawing in convergent directions, microshitians to 'linuxize', embrace, extend, e.g., the powershell derps; and poetterings to winblowiate linuxland, e.g., systemd.

asciilifeform: is there a particular reason we ought to be wasting any cycles on 'embrace & extend' fucktards ?

asciilifeform: embrace, extend, extinguish (tm) (r) (microshit)

asciilifeform: phf: it would be absolutely trivial to send blocks in a sane way to compatible clients. 'embrace & extend' protocol

asciilifeform: decimation: or if you meant some oddball 'embrace & extend' of the sync protocol - yeah, we'll probably get there eventually

assbot: Logged on 02-06-2015 21:52:56; ascii_field: http://log.bitcoin-assets.com/?date=02-06-2015#1151841 << embrace, extend, extinguish (TM) (R)

asciilifeform: once we have a reasonable 'embrace and extend' of sync mechanism - then yes

davout: http://log.bitcoin-assets.com/?date=23-04-2015#1108717 <<< as long as it is the embrace, extend, extinguish kind of embrace... ☝︎

asciilifeform: mircea_popescu: simple experiment shows that penalizing nodes sending out-of-order blocks - does very little. as pointed out. what we want is to 'embrace & extend' the block sync process in the sense of preferring friendly nodes for sync.

mircea_popescu: ben_vulpes: "why?" << this thing where you embrace extend and run into the wall a reasonable idea is for teh dogs.

mircea_popescu: just because google has been measurably more successful at embrace, extend and extinguish foss than say microsoft

asciilifeform: 'investing' << 'embrace, extend, extinguish'

mircea_popescu: the way "embrace, extend and extinguish" is dressed up in foundation/power ranger internal communication is, "to maximize bitcoin the ideal approach is to not define bitcoin any particular way". this neatly matches their refusal to specify the protocol, and its direct implication is

asciilifeform: mats: gcc... a) i dont get it... << what's the hard concept here? rms wishes to avoid gcc turning into a sweet and defenceless piece of candy for the 'embrace & extend/extinguish' folks. ☟︎

jurov: asciilifeform no tthey want to embrace and extend grub, too

decimation: well, you can clearly see the strategy of 'embrace, extend, extinguish'

decimation: eh. every new bureaucrat knows that they can 'embrace and extend' new territory by trying to 'get there first'

jurov: then they decided rather to embrace, extend &extinguish