Нужно. Если вы еще не считали, вот результат: вы можете получить прибыль либо если у вас халявная электроэнергия (для реальной прибыли нужны такие объемы халявы, которые называются «воровство») или вы купили спецоборудование за $5000. Спецоборудование станет неприбыльным через пол-года, но сначала за 4 месяца себя окупит.
Вывод: покупайте спецоборудование, системе Bitcoin нужны банки-участники! И именно аналогом банка вы становитесь, запуская такое оборудование — будете чеканить деньгу и к вам будут приходить (протоколом), чтоб проплатить денюжку (за комиссию). И вы так же будете повязаны в бизнесе и должны будете реинвестировать, или выйти из бизнеса (возможно, с прибылью, а не как банкрот).
Говорю не за себя, а за Сатоши: Ну и кто будет распараллеливать? Каждый второй будет красть у другого каждого второго? Не лучше ли честно считать блоки, в которых каждый первый тратится на цветы бабам и мороженное детям (т.е. транзакции идут постоянно, в отличии от экономики в панике, т.е. чьи деньги падают в цене).
По поводу «излишней» уже ответили, по поводу «специально усложняется» — сложность замков тоже «специально» усложняется. Предполагается, что это позволяет поддерживать безопасность на должном уровне. У криптовалют так же — как только кто-то изобретет способ считать хэши из воздухаASIC'а как через пару недель сложность убежала вперед. И если быть точным, то не «усложняется», а меняется адаптивно, т.е. может и понижаться — если все ASIC'и перегреются и сдохнут, то вскоре снова можно будет майнить видеокартами.
> Скорее это игра, а не работа.
Вся жизнь игра. Но это скорее соревнование. Банки предлагают депозиты под большие проценты. Люди ищут, где платят больше. Борьба видов. И в биткойнах то же самое. Остановите Землю, я сойду.
> Не так давно слыша историю, как один норвежец купил
Добро пожаловать в интернет, здесь всегда так. Кстати, тот студент, который развел всех (всех буратин) на milliondollarhomepage.com/, не набрехал — сайт все еще висит (скоро закроется — десять обещанных лет подходит к концу). (А сотни клонов вроде milliondollarhomepage.ru/ давно сдохли кстати).
Смущает. Рисуется картина вроде (Непроизносимая организация) попросила NSA о том, о чем нельзя даже подумать. NSA попросила FBI придумать красивую легенду (секретную), например вроде того, что ведем Super Mega Silk Road 2 feat. Al Qaeda, если сейчас прикрыть Bitcoin, все сольются и уедут на Багамы. FBI попросило граждан выполнить долг и развернуть на 180 градусов уже запущенную кампанию по прикрытию Bitcoin.
Память о e-gold еще свежа — да вот только осенью закончили прием заявлений на возврат вкладов сбербанка конфискованных средств, требовалось доказательство происхождения. Так что, так как Bitcoin, могут любить только свое ;-).
Это была ирония на вашу иронию. Просто вы дали три ссылки подряд, какой hg хороший, что можно было подумать, что про «на бумажке» тоже прям из какого-то man git скопировано ;-).
> То, что git никак не помечает, выпинан ли коммит куда-нибудь или нет
Вы явно что-то путаете. Это SVN никак не помечал (и то в 2.0 или около исправили), был ли коммит смержен, например при мерже одной и той же ветки дважды вылезут конфликты. git разумеется ведет историю merge'ей и все работает, как надо.
Это не относится к rebase, потому что rebase работает не на уровне истории основной ветки, а на уровне последовательности отдельных патчей в нашей ветке. Наши коммиты попросту применяются один за другим к *совершенно новой истории upstream'а*, и либо применяется, либо patch «видит», что он уже применен (тогда из нашей ветки этот патч уходит), либо есть конфликт (и пользователь исправляет). Автор этой статьи вот нашел, как подстроить конфликт, который patch git'а не заметил. Кулхацкер. Итог, при rebase'е нечего «записывать», кроме самих патчей, что git делает неплохо, но поскольку patch — штука эвристическая, то ошибиться может.
> а разве --interactive не добавляет corner cases в rebase?
Дай бог многим системам такого пользовательского интерфейса, как в git rebase --interactive. Все в вашем любимом текстовом редакторе, помощь перед глазами, все весьма очевидно — хочешь переставить коммиты — переставь строки в редакторе. Я никогда не пользуюсь git merge --squash — зачем мне помнить об этом corner case'е, если git rebase --interactive позволяет добиться и его эффекта, и многих других.
А почему «записывают на бумажке хэши» без пруфлинка? :-E
> Если «удобной и пригодной» == «один в один как в git»
Нет, это имеющей как можно более простой процесс применения и с возможно меньшим количество corner cases. Ну и en.wikipedia.org/wiki/Principle_of_least_astonishment. git в этом не идеален, конкретный пример я привел — когда должен был бы работать rebase --continue, «почему то» требуется rebase --skip (детали почему простым пользователям не интересны).
> Ну и да, rebase — детерминированная операция
Статья выше аргументирует, что нет.
Спасибо за ссылку на Phases, рад знать, что фичи hg развиваются. Уверен, что тот, кому нужно маркировать коммиты как public/draft/secret его сразу находит и использует. Увы, в mercurial достаточно своих некрасивостей и нурешений принципа least user surprise…
Nice! Не знаете, много ли пользователей hg включают и используют его? С одной стороны, логика не включения — это advanced'нутая фишка, и ее неразумное использование приводит к примерам, как в этой статье. С другой стороны, это advanced'нутая фишка, и требуется много глаз и рук, чтобы сделать ее реально пригодной и удобной в использовании.
Я помню как rebase в git был весьма нервотрепным делом. Собственно, и сейчас там есть неочевидные моменты (например, если какой-то патч уже в upstream'е, то может выйти конфликт, после резолюции которого будут нулевые изменения в рабочей копии, которые соответственно нельзя за'add'ить в индекс, а значит нельзя сделать rebase --continue; нужно знать, что в это момент нужно дать rebase --skip).
Ах, да, и еще, под «rebase в git» и «нет ни в какой другой системе», я понимаю так же и rebase --interactive, т.е. не просто перекинуть «свой» блок коммитов на (новый) верх «чужой ветки», а вообще легко и удобно переписывать историю.
Напишите в какой, я после того, как освоил git, за другими пристально не слежу, но быть в курсе эволюции всей области хочется.
Собственно, я по-моему слышал о rebase-плагине для bazaar, но плагин это не совсем то… Когда мне нужен будет rebase для bazaar (что иногда случается), я не побегу искать плагин, а матернусь и с'merge'у. (А merge'ы у bzr особо плохие по сравнению с git'ом, они фактически squash'ат по-умолчанию, докопаться по внутренней истории можно, но нужно давать дополнительные ключи в bzr log -p и т.д.; итог: по практичности далеко до git'а).
Собственно, фишка rebase'в том, чтобы оторваться от контекста и легко приложить патчи к чему угодно (обычно к HEAD'у чужой ветки, но возможностей куда больше). Работает конечно в пределах эвристичности patch'а и семантики кода, к которому прикладывается. Тут Yan169 прав, «это должен знать каждый» (и соответственно использовать — совсем не каждый и не всегда).
Вообще, цикл статей наводит на мысль, что обсуждается вопрос «А нужен ли git в советском союзе?» Правильный ответ: не нужен. Сначала перестройка, 85год, из RCS рождается CVS, пока вокруг все ходят с дискетками и диффать файлы можно только если два монитора стоят рядом. Потом внезапно — Subversion. О-ля-ля! Робкие попытки с Monotone, где каждый коммит — это фактически branch, и его нужно явно мержить, а если в репо оказались два несмерженных коммита, то закоммитать новое уже нельзя. Уже где-то слышится дуделки git'а, но мы то слышали (хоть и не пробовали), что он не усер-френдли, поэтому mercurial, и даже лично здоровались с человеком, который портает bazaar под венду. Потом вдруг сверху спускается git rebase, куча мата от необходимости править конфликты каждый раз — ведь алгоритм не такой robust'овый, как merge. Потом через полгодика, вместе с ключиком -i, приходит эйфория от осознания того, что больше не нужно коммитать говно-код и говно-каменты в общую ветку — их можно легко (по сравнению с «невозможно» других систем) исправить (или заставить исправить). Ну а потом все уже устаканивается и приходит понимание, что и merge --no-ff есть не зря.
Дерево? История с merge'ами — нудный и запутанный ациклический граф. Поэтому народ, который *царь* в своем репозитории и стремиться линеаризовывать историю. При демократии такой метод работает хуже — за всеми нажен merge да merge, а то какой-то несознательный гражданин написает на общественную клумбу.
Порадуемся за git, который является мультипарадигмической системой, позволяющей получить хоть код, чистый, аки горлица (в динамике, не в статике! — где каждый коммит компилится и без опечаток, как без опечаток и commit message), хоть командную работу при езде в поезде и полете в самолете. (Добиться и того и другого сразу однозначно не получится, даже git не поможет, тут нуден кнут и кандалы.)
Согласен с теми, кто написал, что былина интересная, как раз то чтение, которые приятно читать на Хабре под конец рабочего для, +.
Выводы из конкретного примера однако неоднозначные. Почему объектом критики выбран rebase?
Почему бы не «наехать» на:
— Алгоритм текствого diff'а/patch'а конкретного в git
— Алгоритм текствого diff'а/patch'а вообще
Алгоритм текстового diff'а — эвристика, а уж применение его как patch — эвристика в квадрате. Стоит удивляться и восхищаться, что при этом метод rebase был реализован *для специальных целей* и на практике работает весьма неплохо.
Учить «пионеров», не нюхавших CVSа, не юзать rebase направо и налево конечно стоит, но использовать для этого недостатки алгоритма diff — «не очень красиво» (хотя еще раз, былина получилась интересная). Для пущего эффекта, статью можно было бы озаглавить «Как я похакал diff» или вообще по-ализаровски: «В git найдена критическая уязвимость» ;-).
Команды rebase нет наверное ни в какой другой системе контроля версий. Это подчеркивает, насколько развит git и насколько у него большая community, что в нем реализованы *специальные* возможности для *специальных* целей, которые другим системам и не снились. Конечно же, Капитан подсказывает, что всем подряд использовать специальные возможности ни к чему.
Вывод: покупайте спецоборудование, системе Bitcoin нужны банки-участники! И именно аналогом банка вы становитесь, запуская такое оборудование — будете чеканить деньгу и к вам будут приходить (протоколом), чтоб проплатить денюжку (за комиссию). И вы так же будете повязаны в бизнесе и должны будете реинвестировать, или выйти из бизнеса (возможно, с прибылью, а не как банкрот).
blockchained.com/profit/ и т.п.
А вы держите деньги в сбербанке СССР ;-).
По поводу «излишней» уже ответили, по поводу «специально усложняется» — сложность замков тоже «специально» усложняется. Предполагается, что это позволяет поддерживать безопасность на должном уровне. У криптовалют так же — как только кто-то изобретет способ считать хэши из
воздухаASIC'а как через пару недель сложность убежала вперед. И если быть точным, то не «усложняется», а меняется адаптивно, т.е. может и понижаться — если все ASIC'и перегреются и сдохнут, то вскоре снова можно будет майнить видеокартами.> Скорее это игра, а не работа.
Вся жизнь игра. Но это скорее соревнование. Банки предлагают депозиты под большие проценты. Люди ищут, где платят больше. Борьба видов. И в биткойнах то же самое. Остановите Землю, я сойду.
Это как? Чтоб нельзя было сказать «Сударь, Ваша транзакция отвратна»?
> Заговариваюсь я что-то.
Есть такое.
Добро пожаловать в интернет, здесь всегда так. Кстати, тот студент, который развел всех (всех буратин) на milliondollarhomepage.com/, не набрехал — сайт все еще висит (скоро закроется — десять обещанных лет подходит к концу). (А сотни клонов вроде milliondollarhomepage.ru/ давно сдохли кстати).
Смущает. Рисуется картина вроде (Непроизносимая организация) попросила NSA о том, о чем нельзя даже подумать. NSA попросила FBI придумать красивую легенду (секретную), например вроде того, что ведем Super Mega Silk Road 2 feat. Al Qaeda, если сейчас прикрыть Bitcoin, все сольются и уедут на Багамы. FBI попросило граждан выполнить долг и развернуть на 180 градусов уже запущенную кампанию по прикрытию Bitcoin.
Память о e-gold еще свежа — да вот только осенью закончили прием заявлений на возврат
вкладов сбербанкаконфискованных средств, требовалось доказательство происхождения. Так что, так как Bitcoin, могут любить только свое ;-).Это была ирония на вашу иронию. Просто вы дали три ссылки подряд, какой hg хороший, что можно было подумать, что про «на бумажке» тоже прям из какого-то man git скопировано ;-).
> То, что git никак не помечает, выпинан ли коммит куда-нибудь или нет
Вы явно что-то путаете. Это SVN никак не помечал (и то в 2.0 или около исправили), был ли коммит смержен, например при мерже одной и той же ветки дважды вылезут конфликты. git разумеется ведет историю merge'ей и все работает, как надо.
Это не относится к rebase, потому что rebase работает не на уровне истории основной ветки, а на уровне последовательности отдельных патчей в нашей ветке. Наши коммиты попросту применяются один за другим к *совершенно новой истории upstream'а*, и либо применяется, либо patch «видит», что он уже применен (тогда из нашей ветки этот патч уходит), либо есть конфликт (и пользователь исправляет). Автор этой статьи вот нашел, как подстроить конфликт, который patch git'а не заметил. Кулхацкер. Итог, при rebase'е нечего «записывать», кроме самих патчей, что git делает неплохо, но поскольку patch — штука эвристическая, то ошибиться может.
> а разве --interactive не добавляет corner cases в rebase?
Дай бог многим системам такого пользовательского интерфейса, как в git rebase --interactive. Все в вашем любимом текстовом редакторе, помощь перед глазами, все весьма очевидно — хочешь переставить коммиты — переставь строки в редакторе. Я никогда не пользуюсь git merge --squash — зачем мне помнить об этом corner case'е, если git rebase --interactive позволяет добиться и его эффекта, и многих других.
> Если «удобной и пригодной» == «один в один как в git»
Нет, это имеющей как можно более простой процесс применения и с возможно меньшим количество corner cases. Ну и en.wikipedia.org/wiki/Principle_of_least_astonishment. git в этом не идеален, конкретный пример я привел — когда должен был бы работать rebase --continue, «почему то» требуется rebase --skip (детали почему простым пользователям не интересны).
> Ну и да, rebase — детерминированная операция
Статья выше аргументирует, что нет.
Спасибо за ссылку на Phases, рад знать, что фичи hg развиваются. Уверен, что тот, кому нужно маркировать коммиты как public/draft/secret его сразу находит и использует. Увы, в mercurial достаточно своих некрасивостей и нурешений принципа least user surprise…
Я помню как rebase в git был весьма нервотрепным делом. Собственно, и сейчас там есть неочевидные моменты (например, если какой-то патч уже в upstream'е, то может выйти конфликт, после резолюции которого будут нулевые изменения в рабочей копии, которые соответственно нельзя за'add'ить в индекс, а значит нельзя сделать rebase --continue; нужно знать, что в это момент нужно дать rebase --skip).
Собственно, я по-моему слышал о rebase-плагине для bazaar, но плагин это не совсем то… Когда мне нужен будет rebase для bazaar (что иногда случается), я не побегу искать плагин, а матернусь и с'merge'у. (А merge'ы у bzr особо плохие по сравнению с git'ом, они фактически squash'ат по-умолчанию, докопаться по внутренней истории можно, но нужно давать дополнительные ключи в bzr log -p и т.д.; итог: по практичности далеко до git'а).
А в колхозе git не нужен, нет.
Порадуемся за git, который является мультипарадигмической системой, позволяющей получить хоть код, чистый, аки горлица (в динамике, не в статике! — где каждый коммит компилится и без опечаток, как без опечаток и commit message), хоть командную работу при езде в поезде и полете в самолете. (Добиться и того и другого сразу однозначно не получится, даже git не поможет, тут нуден кнут и кандалы.)
Выводы из конкретного примера однако неоднозначные. Почему объектом критики выбран rebase?
Почему бы не «наехать» на:
— Алгоритм текствого diff'а/patch'а конкретного в git
— Алгоритм текствого diff'а/patch'а вообще
Алгоритм текстового diff'а — эвристика, а уж применение его как patch — эвристика в квадрате. Стоит удивляться и восхищаться, что при этом метод rebase был реализован *для специальных целей* и на практике работает весьма неплохо.
Учить «пионеров», не нюхавших CVSа, не юзать rebase направо и налево конечно стоит, но использовать для этого недостатки алгоритма diff — «не очень красиво» (хотя еще раз, былина получилась интересная). Для пущего эффекта, статью можно было бы озаглавить «Как я похакал diff» или вообще по-ализаровски: «В git найдена критическая уязвимость» ;-).