Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

GitLab удалил 300Гб данных

Собственно вот ссылка: www.theregister.co.uk/...​ta_loss/?mt=1485932441853

Вот отчет по ходу работы:
docs.google.com/...​CxIABGiryG7_z_6jHdVik/pub

Я сам переживал боль и исполнения «rm -rf» на корневой директории, но мне повезло, это был мой маленький инстанс :) После этого, команды удаления под sudo или без подтверждения не выполняю. Вопрос теперь, выживет ли стартап после такого эпического провала?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

GIT это культ параноидального репозитория с пятью обязательными приседаниями и словом ку на каждом обычном комите. Единственная в своем роде система, где флоу настолько запутали и сделали неочевидными (особенно для новичков), что пришлось внедрить целый пласт комманд, чтобы починить то что сломали «кривые руки» и это уже промолчим о десятках UI клиентов, основная роль которых просто скрыть тот треш с командной строкой. Да да, я знаю что я тупой, потому что не могу в себе найти силы читать инструкцию больше одной странички для обычной отвертки, которая почемуто оснащена трехцилиндровым бензиновым двигаелем и пультом управления позаимственного у шатла. Впрочем культ на то он и культ, стрелочник админ уже найден, ктото там недостаточно хорошо проникся обязательными ритуалами в системе через плечо.
PS: здесь будет море гнева бородачей :)

Это всё что нужно знать о любителях консольных утилит.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

удалять в терминале надо только под mc! и тогда такой херни не будет.

Под mc херня вероятнее, говорю по опыту.

Этого бы не случилось, если бы вместо баша использовали бы golang.

///bin/true; exec /usr/bin/env go run «$0» «$@»
В .go файле и можно использовать как скрипт. Типа ./hello.go

То есть написать на го утилиту и ранать ее вместо стандартного rm?

Первая ссылка в гугле привела сразу к launchpad.net/safe-rm

На замену гоу думаю они уже взяли ruby. Так что мимо все равно.

Вопрос теперь, выживет ли стартап после такого эпического провала?
Звичайно виживе. Ви походу не читали тред на HN та в них на багтрекері з обговоренням переїзду на bare metal. Врешті-решт через багатотижневі дебати CEO сказав — «в першу чергу ми позиціонуємо себе як hosted а не SaaS рішення, тому побудова власного DC тільки для того щоб покращити перформенс Gitlab.com — нераціональна».
Gitlab.com навіть не пропонує платного тарифу. Провал не такий вже й епічний — головне, а саме репозиторії — залишилися неушкодженими.

Проблема не в sudo, а в вечной спешке и недосыпах

И в сути линуксовых команд которые сделаны для быстрого фигак фигак и запустить. В итоге можно сделать совсем другое просто сделав небольшую опечатку.

Да, есть такое. Хотя в спешке (или если отвлекут) и в гуях нефиг делать ошибиться.

Я бы сказал дело не в том что это консоль. Если бы команды не были сокращены до беспредела и ясно было что они делают то ошибок было бы намного меньше. А в гуи конечно тоже можно ошибиться, особенно после многолетнего опыта установки программ когда жмешь кнопку быстрее чем прочтешь что там пишет))

Да, remove —force —recursive конечно «случайно» не напечатаешь, но тогда другая проблема — слишком замедляется работа, когда эти команды нужно печатать часто. Да и судя из статьи (цитату я приводил), админ действительно хотел выполнить именно rm -rf, просто не на том сервере. То есть вероятно попутал окно терминала

Не соглашусь, если дать пистолет ребенку, то что случится будет результатом спешки или недосыпа, или все дело в том, что ребенок в силу возраста не способен безопасно обращаться с оружием? Когда свободно даете sudo на проде кому-угодно, — думайте о ребенке и пистолете...

Я не думаю, что админ — это кто угодно. Также я не уверен что можно заниматься администрированием, не имея sudo. И собственно цитата из статьи:

Behind the scenes, a tired sysadmin, working late at night in the Netherlands, had accidentally deleted a directory on the wrong server during a frustrating database replication process

Парни фиксят в реальном времени: www.youtube.com/watch?v=nc0hPGerSd4 Горение пуканов и расчлененки одмена я не вижу. Вполне себе расслабленно обсуждают и чинят. Прекрассная многоходовочка для того, чтоб показать, что в GitLab работают не школьники, а адекватные специалисты, готовые решить любой косяк.

Прекрассная многоходовочка для того, чтоб показать, что в GitLab работают не школьники, а адекватные специалисты, готовые решить любой косяк.
Хороший админ всегда сидит без работы ©

Согласен, лучше бы парни стримили видео, как они спокойно пьют чай или рубят в доту по сети :))

Они в основном отвечают на вопросы зрителей.

Кто все эти люди? o_O

В видео они скорей в суппорте сидят. Я просто сужу по нашим админам, они реально нихрена не делают, слоняются без дела, стебутся над суппортерами и прочее, но когда две недели назад упало два 10Gbit линка, основной и бакапный (в том месте где они оба сходятся) копнул трактор замёрзшую землю вместе с кабелями — удача неимоверная, так они всю ночь разворачивали тарелку на крыше в 15 градусный мороз, чтобы обеспечить связью офис на утро, почти двое суток без сна пока не починили всё и не разобрали тарелку назад. Ну а последующие две недели у них лица как на этом фото: www.korova.ru/.../pics/0200/admin_spit.jpg . В прошлом году заадминили джиру насмерть, суммарно проработали где-то месяц из 12 %)

Это всё что нужно знать о любителях консольных утилит.

Виновата, как обычно, невестка.

Интересно если бы все удалила программа написанная на Java, то это было бы все? что нужно знать про Java программистов? ))

На Java сложнее похерачить все, там один символ не меняет полностью функционал. Кроме того проверки проще сделать, логи, ексепшены и так далее. А да, а еще в Java человеческие названия а не хрен догадайся что.

Да ну? что мне мешает сделать так: Runtime.getRuntime().exec("rm -rf /"); Имхо говнокода на java не меньше чем на php, bash или js. Так что я бы не был так оптимистичен.

Ну если такое написать то конечно. Я вообще, что джава более безопасная, там сложнее наговнокодить и это факт. А

Имхо говнокода на java не меньше чем на php, bash или js. Так что я бы не был так оптимистичен.
это обычное пустословие. Тоже имхо.

Ну это мой личный опыт, возможно мне просто везет. Хотя слышать про безопасность, из мира где большая часть проектов это дикое закрытое легаси, немного смешно. И вечные баги банковских систем написанные на этой безопасной платформе с потерей со счетов тысяч и даже миллионов долларов мое подозрение только подтверждают.

Зачем снова манипулировать? Ясно что как ошибки так и говнокод можно сделать на любом языке. Но это не отменяет факта что на некоторых языках это сделать труднее(и наоборот проще). Одна айдишка для джавы и компилятор уделывают все эти скриптовые языки. Уже +1000 к написанию безбажного кода. Это давно известный факт но тем не менее любители скриптования все еще пытаются спорить непонятно о чем. Скриптовые языки имеют единственный плюс — на них быстрее написать код. И наговнокодить тоже.

Я посмотрю как выбудете админить сервер через IDE и компилятор :)

Мы говорили о написании программ, в том числе тех которые что то там с файлами делают. По поводу администрирования сервера то я выше уже описал в чем проблема, которая позволяет все слить в унитаз очень легко.

Ну есть опыт админения через uucp по диалапу. Письма, тело которых подписано PGP и выполняется после проверки подписи шеллом, в письмах соответственно толстые шелловые скрипты, here-documents и sharʼовые архивы (кто не знает — рекомендую погуглить для расширения кругозора), включая бинарники для выкладки для локального запуска. Вызвать cc собрать что-то локально тоже было.

Проблем с этим особых нет, кроме того, что терпения требуется побольше, чем на рыбалке, особенно когда та сторона долго не звонит забирать почту. Всё делается очень медленно, аккуратно и по мелким шагам. Когда я читал Панкееву, находил очень много общего :)

Хотя бы тот факт, что придётся почитать доки к Рантайму, к секьюрити, и разумеется потрахаться с правами доступа. Вы всерьёз считаете что у Java-машины окажутся права root? Тогда вот эти розги для вас.

Если есть вероятность что это может случится, это обязательно случится.

ps: что бы в shell ковыряться тоже надо доки почитать. Тут просто кому как проще. Лично мне с джавой было проще чем с linux shell.

pps: ну и если бы я был java программистом, то при надобности написать консольную утилиту без знания bash/sh я бы попробовал сделать это на java. И да, иногда бы запускал бы ее от рута если нужны права супер пользователя.

Нихрена, чтобы в шелл поковыряться обычно никакой гениальности не хватит. Документация или кратк.сестр.тал, или вообще никакой, или огромные простыни мануалов (где самое важное разумеется не напишут). И как часто бывает, в реале проги работают не так, как написано в мануале, просто потому что автор «покращил» версию, а переписывать мануал лень.

И коль скоро суперменов у нас нет, то юные подаваны тупо копипастят готовые решение откуда угодно кроме документации [где их нет не только лишь всегда]. Шансы угадать по ключам -п -ж -ппц -?%№%(*** что конкретно делает команда — никаких, даже после выполнения нужно очень постараться чтобы узнать результаты.

А ну, палец вверх, кто из вас писал тесты к своим консольным утилитам? [мой поднят, если чё]

Когда от перестановки аргументов файлы перепишутся друг в друга строго в противоположном направлении — никакие человеческие имена не помогут.
А сделать функциональный тест вокруг шеллового скрипта даже проще, чем вокруг Java-бинарника.

Проблема шелла не в «человеческих именах» — ошибки типа написать rm вместо mv я не видел за много лет ни разу. И даже опыты, где требовали писать полностью delete вместо rm или как-то похоже, не показали уменьшения количества ошибок.
Проблема в том, что каждое опасное действие конструируется на ходу, и на это конструирование уходят интеллектуальные ресурсы, мешая подумать о смысле, который стоит за ними. Тут любой цейтнот начинает действовать резко в минус.

Некоторые говорят про смысл парного программирования. Но для администрирования это в разы ценнее. Ещё помогает проговаривание вслух вместе с checklistʼом проверок на опасные действия, начиная с банальности, тот ли хост.

Если бы те же команды давались через GUI, даже простенький MidnightCommander, то память одновременно бы следила за соответствие других шаблонов восприятия. А вот в консоли ты на 100% уверен в своей правоте, пока не ткнул Enter.

User Experience нужен не чтобы потешить самолюбие. А чтобы хомо сапиенс в принципе мог работать с программой. Вы не поверите, как много отличного кода полягло невостребованным, просто потому что для человека, с его оперативной памятью ≈17 слов, очень тяжело меняться под программу. Но именно этого и требуют авторы CLI.

Да, программистам кажется естественным писать нечто вроде
cp -rf $htdocs_source $htdocs_dest 2>&1
Но почему-то революционным оказался язык, в котором пишут
SELECT id,name FROM things ORDER BY id
(хотя и там пришлось допиливать и допиливать под юзера, шаблонная память которого не возражает запуску UPDATE без условия)

Я считаю, давно пришло время вменяемых языков, без дебилоидных сокращений, без одному чёрту понятных регулярных выражений, без звёздочек и чёрточек с полузакрытыми скобочками. Сколько десятков лет нужно, чтобы понять: все языки программирования непонятны машине. Их изначальная цель — быть понятными человеку. И никакое «сокращение кода» не оправдывает перечёркивание этой единственной цели.

Это природа человека: даже в самом новом контенте требуется 90% узнаваемых шаблонов. Если их нет, восприятие тупо идёт в автогенерацию мусора и вызывает отторжение. Так уж позаботилась эволюция. Вы даже можете считать что человека создал Бог, но он явно не научил его что можно жрать, а что нет — этому человек обучается сам. И с кодом разумеется то же самое: либо он удобоваримый, либо удел безбашенных экстремалов.

По той же причине не взлетает функциональное программирование. Оно утратило преимущество ООП: держать узнаваемые шаблоны в одном месте, сокращать затраты на восприятие и вероятность ошибок. Для вас покажется дикостью, что львиная доля ООП не нуждается в тестах 95%+ кода. Просто нет необходимости. Тестировать нужно связи ООП, но если нужен тест ООП, то по логике он должен быть написан внутри объекта. Вы будете смеяться, но если почитаете хорошо документированное ООП, это именно то, что вы там найдёте: тесты и примеры. Прямо в том же файле.

Большая. Как минимум, отсутствие прав у юных подаванов на Master. И да, читая DROP DATABASE поневоле перепроверишь, а то ли ты дропаешь. А когда пишешь строку краказяблов, следишь больше за синтаксисом, чем за общим смыслом.

Все верно, основная проблема это человек. От него надо стараться избавляться. Если бы к продакшену не было доступа ни у кого кроме человека который имеет права нажимает одну кнопку «обновить продакшен», и перед обновлением автоматически делались бы настоящие бекапы с проверкой. Или даже просто выкатывалась новая версияь без удаления старой. То и проблемы бы не было. Надо взять за правило, что человек всегда лажает, тогда таких ситуаций станет меньше.

Нет, в таких случаях делают копию продакшена и разбираются там. А ковыряют продакшен только психи )

Именно по этому ни у кого из дев тимы не должно быть доступа к продакшену.

Если на стене висит ружье, то в конце концов в кого-то будут стрелять.
Если открыто несколько окон то в конце концов напишешь не в то окно.
Тут элементарная безответственность.

ЗЫ: именно для этого надо гуишное окно в котором ты большими буквами должен написать, что готов ответить яйцами за определенные действия

Если бы те же команды давались через GUI, даже простенький MidnightCommander, то память одновременно бы следила за соответствие других шаблонов восприятия.

Когда жмёшь F8 на каталоге, это не работает. Более того, в mc обычно не видишь hostname, он в тёмном углу воспринятия и в единственном месте. Поэтому тут эффект обратный — mc мешает.

cp -rf $htdocs_source $htdocs_dest 2>&1

А нахрена 2>&1 у cp? ;) Кривые у вас примерчики.

(хотя и там пришлось допиливать и допиливать под юзера, шаблонная память которого не возражает запуску UPDATE без условия)

Вот именно. Я так пару раз уже ошибался, и удивляюсь, почему там не требуют обязательного where.

Их изначальная цель — быть понятными человеку.

Верно. Но излишнее многословие начинает этому мешать. И вы близки к тому, чтобы перегнуть в противоположную сторону.

Это природа человека: даже в самом новом контенте требуется 90% узнаваемых шаблонов.

Именно что тут сила привычки. А значит, инерции.

Про ФП пропущу, тема слишком объёмная.

Я так пару раз уже ошибался, и удивляюсь, почему там не требуют обязательного where.
В mysql есть —i-am-dummy опция. Еще помогает правило заворачивать (деструктивные)операции в транзакцию + писать where до написания самого update/delete стейтмента.

Ну вот в итоге я так update и пишу — начиная с where :) Специфика mysql хорошая, но не всегда — приходится ещё и другие движки тиранить.

upd: еще в дополнение, для случаев частого ручного администрирования, — можно использовать delayed replication (e.g. mysql)

К сожалению, эта опция не спасает — индусы понаписали фреймворков, которые с этой галкой отказываются пахать, даже кеша вычистить не в состоянии.

Ну давай, нажми F8 на root-каталоге. Сам знаешь куда пошлёт тя умный пингвин?

Один частный случай с «защитой» (и то не сработает, если этот корень будет от подчинённого контейнера, примонтированного диска или скопирован через mount —bind) против 100500 реальных случаев удаления не той копии условного /var/db/mysql (не на том сервере, оригинал вместо бэкапа и т.д.)

Если бы те же команды давались через GUI, даже простенький MidnightCommander, то память одновременно бы следила за соответствие других шаблонов восприятия. А вот в консоли ты на 100% уверен в своей правоте, пока не ткнул Enter.
так может они на самом деле все через GUI делали... просто промахнулись мышкой и кликнули не на ту кнопку)))
«Дядя, ты хочешь удалить это?»
«Дядя, ты действительно хочешь удалить это?»
«Дядя, подумай еще раз, что ты хочешь действительно это сделать?»
ну это уже какой-то слишком параноидальный гуй — 10 раз одно и то же уточнять)) такой и до белого колена довести может своими сплывающими окошками. хD
Как в Винде сделано.
А вообще параноидальность на серверах необходима ибо любой человек может запросто ошибиться в одном из десятка ключиков в CLI.
1. Ну, у меня винда не такая параноидальная)

2. большинство серверов как бы под юниксами насколько знаю)

3. в нормальных CLI должна реализовываться система предупреждений (в текстовом виде, ясен пень) типа «такая-то хрень будет удалена, продолжить (y/n)?». Тобишь хорошая консоль, как и хороший гуй должны давать одинаковую надежность при прочих равных условиях.

А если кто-то по своей невнимательности или криворукости выбрал не правильый пункт менюшки или ввел неправильную команду — то это еще не значит, что гуй или консольная утилита кривая)

И только в ИТ считается нормальным подобные вещи делать как бог на душу положит.
ну так элита ж)))

ну у меня такое подозрение, что таки второе)

Удивляет, что при вроде как большей ответственности зп существенно меньше программистов :)

Знать надо меньше, работать легче(если не учитывать ту же ответственность). Хотя какая она ответственность? Максимум уволят же, как и в другом месте. А проблемы разгребать будет новый админ.

П.С. если бы зп меряли только ответственностью то водители маршруток бы получали в разы больше программистов.

У меня случай был смешной. Стоял я как-то раз помначкара на губе и ближе к сдаче в караулку зашел начгуб и завёл задушевную беседу. Не помню о чём там была речь, но он обранил фразу: «... на хитрую ж..у есть х.. с резьбой». Я не удержался от соблазна показать свою эрудированость и добавил: «На х.. с резьбой есть ж... с лабиринтом»! И тогда начгуб не отрывая взгляда в пустоту добавил: «А на ж... с лабиринтом есть х... с программным управлением»...

Ну после такого стечения обстоятельств от судьбы было уже не отвертеться ).

ПКМ — свойства — предыдущие версии

Я слышал что на виндовс серверах все в гуи. Интересно как там оно.

Воу воу. Интересненько. У майкрософта похоже тотальная революция. Ну наверно правильно, в консоли быстрее. Кстати что то мне подсказывает что там у них команды имеют понятные названия без упоротых сокращений как в линуксе, так? Хотя, погодите, я надеюсь там не заюзан Pascal case?)) Жать шифт на каждое слово тот еще треш. С другой стороны винда не case sensitive и навернека можно не жать его?

Ну это для привлечения тех кто на линуксе сидит. Маркетинг ©

Реально оно работает в обратную сторону — облегчает на Windows разработку под Linux для тех, кто привык к Windows. Тут MS умудряется активно рыть сама себе могилу.
Ранее она делала строго наоборот — когда OS/2 запускала программы Windows, а Windows не запускала программы OS/2, все писали под Windows, и OS/2 стала не нужна. Видимо, те уроки забылись.

PowerShell же, команд лайн.

Там свой совершенно адский язык, для задач, на которые направляют юниксовый шелл, мало пригоден. Я бы его поставил ближе к REPL Перла или Питона, чем к sh.

Там свой совершенно адский язык
Зато тру объекты, вместо этого вашего обезличенного текста =)

Для тру объектов я возьму что-то поудобнее, типа ipython, а не этот гибрид бульдога с осьминогом.

Точно также, заходишь в папку system32 в проводнике под админом и удаляешь там все ненавистные dll.

Я слышал что на виндовс серверах все в гуи.
В такие длинные [г]уи положенные на пользователя.
Давай квест: у винды есть раздел восстановления. Который разумеется не работает после первого же серьёзного обновления, говорит «система повреждена» [угадайте, кем, подскажу: мелкое, мягкое]. Теоретически, винда должна обновлять этот раздел сама, а также иметь возможность создать новый в 1-2 клика, и разумеется подключить его к загрузке.

А теперь просто погугли, как это сделать на самом деле. Лично у меня это не получилось ни разу. Зато «умных» мануалов — вагон и маленькая тележка.

Учитывая цену ошибки, очень рекомендую хостить проекты там где их есть.

GIT это культ параноидального репозитория с пятью обязательными приседаниями и словом ку на каждом обычном комите. Единственная в своем роде система, где флоу настолько запутали и сделали неочевидными (особенно для новичков), что пришлось внедрить целый пласт комманд, чтобы починить то что сломали «кривые руки» и это уже промолчим о десятках UI клиентов, основная роль которых просто скрыть тот треш с командной строкой. Да да, я знаю что я тупой, потому что не могу в себе найти силы читать инструкцию больше одной странички для обычной отвертки, которая почемуто оснащена трехцилиндровым бензиновым двигаелем и пультом управления позаимственного у шатла. Впрочем культ на то он и культ, стрелочник админ уже найден, ктото там недостаточно хорошо проникся обязательными ритуалами в системе через плечо.
PS: здесь будет море гнева бородачей :)

Флоу банальный. Трэша нет. Бороды у меня нет. Можете сливаться.

На самом деле это не проблема только гита, его флоу или чегото еще. Это менеджерская проблема, проблема что нет человека который возьмет и педантично все посчитает в конкретном проекте и в итоге посчитает улучшение KPI каждого сотрудника и аргументирует качество кода до и после. Я както составлял табличку с шагами, было 3 шага в старой системе на коммит, стало 13. Так вот если правильно подойти к вопросу нужно завести журнальчик. Первая колонка любая простая система контроля версий (Меркуриал, SVN, TFS и тд), вторая колонка GIT, а третья колонка особенности коммита — был например конфликт, заняло столько решение этого конфликта, а если бы комитили в другой системе без конфликта то были бы такие риски для проекта. В конце месяца сесть и хладнокровно посчитать, минута в минуту, сколько было оверхеда и какие риски сняли «правильные» флоу. Тут ведь математика простая, по принципу Парето, за 20% усилий достичь 80% результата, а не наоборот.

Вот и считали. В простом случае, грубо говоря, 3 шага против 3. А в сложных — у гита меньше всего, у других типичных DSCM больше, но ненамного, у централизованных — или 100500, или невозможно в принципе.

Какие три шага, интересно.
Я использую UI SourceTree, вроде бы должно быть даже проще чем в командной строке, но, считаем
1. Checkout ветки девелоп
2. Pool ветки девелоп
3. Create Feature branch
=> 4. Переключились на студию, поменяли лейбу в коде
5. Переключились в SourceTree
6. Stage файла который поменялся
7. Commit в локальный бранч
8. Push в ремоут бранч
9. Удалить локальный бранч (опционально)
10. Переключится в гитлаб
11. Создать мержреквест
12. Заревьювить мержреквест
13. Заацептить мержреквест, смержить
14. Запустить билдить ветку девелоп (можно настроить автоматом, по таймеру)
15. Удалить ремоут бранч (опционально, можно потом скопом их удалять)

И это если все пошло гладко ...
А если не гладко, то к бедной лейбе, изменение которой заняло 10 секунд, добавятся еще шаги на минут 10-15, уже в командной строке

И в этот момент какой-то гибрид гомосексуалиста с начальником звонит тебе «поговорить» на полчаса где-то между п1 и п15. Угадай потом где. И в тот момент когда казалось бы распутал.... он перезванивает!

PS. А у тебя база 300гиг именно тогда на обcлуживании, а не какой-то скромный мёрж.

От саме тому це треба робити в консолі, де є історія дій і що за чим відбувалось, а не в графічних інтерфейсах, де живуть теперішнім моментом.

Что-то я никак не могу понять, какие именно процессы ты сравниваеш. Например, зачем каждый раз checkout на develop?
Почему merge request тут требуется, а в случае другого средства не требовалось бы? Если там всё поступает напрямую в общую ветку (а то и в транк), не надо писать про merge request тут.
Почему раздельно stage и commit, если сравнивается ситуация одного и того же изменения, когда в другом средстве тебе просто не позволяют их сделать раздельно?
Так нечестно, сравнивай одинаковыми подходами и процессами.

GitLab прибили postgresql data directory если чё.

p.s. www.youtube.com/watch?v=Jb4prVsXkZU UI шаттла с 14-й минуты

Но это по крайней мере GUI, зрительная память задействована, и РАЗУМЕЕТСЯ проведены десятки тренировок, учений. Представь себе то же самое, но в CLI, которое исполнится менее чем за секунду. Рассчёт может быть только на то, что тот механизм в который подаёшь команду, сам знает что делать.

Так вот, при написании GUI именно эти моменты и прорабатываются. Задумываешься — а что если дурак нажмёт? А как ему объяснить чего хочешь? А как написать и нарисовать ему так, чтобы он понял? Как не дать лишнего, но дать необходимое? Как разграничить права, например сделав разные интерфейсы?

PS. Да чтоб любителям CLI в Контр-страйк по консоли играть!

Так вот, при написании GUI именно эти моменты и прорабатываются.

«Ох уж эти мне сказки, ох уж эти мне сказочники»

Может, всё это и имело место. До года этак 2000-го. Того гуя уже нет. А в современном давно ничего не прорабатывают. Лезешь в критически важные настройки, тебе дают список из пунктов, ты выбираеш, тебе дали не тот пункт и система уже искривлена. И выбрать старый или нельзя, или забыл, какой там стоял из 20 похожих типа «Sparse mode with extremely low density» vs. «Ultra sparse mode with utterly low density».
Ты давно видел в диалогах «передовых» технологий вроде Win10 или Android кнопки OK и Cancel?

PS. Да чтоб любителям CLI в Контр-страйк по консоли играть!

Грамотные «любители CLI» хорошо различают, где какие технологии подходят и почему. Ты же со своими запредельными аналогиями смешишь.

Imago detected. You failed.

А есть альтернативы? Основные конкуренты это же еще больший трешь.

Mercurial, очевидно. Лучший из существующих ныне DVCS.

А как вы собрались мерять ?
Да, Гит может решать некоторые вещи более разумно. Кто же спорит. Можно написать что вот если прийдет ситуация Х то ее можно решить вот так. Проблема в том, что эта X может быть приходит раз в месяц, а может раз в полгода и имеет простые Y и Z воркеарунды. А вот приседать с Гитом прийдется каждый день и в обязательном порядке. И тут вилка. Что лучше, тешить себя надеждой что проблема Х решена в твоем проекте, или всетаки меньше приседать каждый день и комитить в 2 клика машинально ?

Я читал на сайте гита в доке что меркуриал сасет. Я уже не очень помню почему он сасет, но все мы знаем что создатели и фанаты технологий если пишут что другая технология гавно — то она гавно. Слились вы кароче.

Что лучше, тешить себя надеждой что проблема Х решена в твоем проекте, или всетаки меньше приседать каждый день и комитить в 2 клика машинально ?

Лучше приседать. Это ЗОЖ. Это правильно.

Ну вы же как то вывели вот это: «Лучший из существующих» по какой формуле?

Меркуриал не я вывел.
Но у меня есть опыт работы в двух проектах, в которых переходили на GIT с других систем — в обоих случаях это сопровождалось с определенными проблемами и дальнейшим оверхедом при работе.

Ну у меня был обратный опыт, когда приходилось пользоваться hg, то количество операций в консоле увеличивалось. По этому хотелось бы как то больше конкретики с примерами, может и правда показалось.

хоть вопрос и не мне, отвечу

А нравится больше 😁

А подробнее, потому что пользуюсь гитом, меркуриалом только для своих проектов, меркуриал понятен и логичен. А гит — как-то поболе требует тупо запоминать, и подглядывать в доку.

Более понятен и логичен кто? Архитектура или консольная тулза?

Консольная тулза, архитектура то ведь примерно одинакова (ну разве что у гита нет очередей патчей, постоянных веток и еще кучи полезных функций)

А что насчет selfhosted webui по аналогу gitlab и прочих?

hg serve + redmine устроит?

Ну если набор функций дотягивает то gitlab/github. То наверное да. Хотя Redmine конечно тот еще хлам.

да как-то все вместе. О, меркуриал какой-то более дружелюбный ☺

А eсли по фичам и автоматикe сравнивать, то гит конeчно покручe будeт. Особeнно для больших, разнородных команд, с сложными потоками движения изменений.

Но меркуриал все равно нравится больше потому что он какой-то... как бытовая техника! А гит — ну это какой-то агрегат в цехе, с поддтеками масла.

Если бы он у хостеров стоял, то я б небольшие команды убеждал бы перейти на меркуриал.
А так — приходится пользоваться гитом. Хотя и — из пушки по воробьям. Причем еще и ядро на ногу падает иногда.

У меня строго противоположное впечатление по своему опыту общения с этими двумя системами.

ну, я на примере верстальщиков видел.
Я им — будете работать с гитом теперь. Знаете?
Нууу, пробовали, но, как-то не очень.
Хорошо, говорю, давайте попробуйте меркуриал.

И опа, ой, как здорово, удобно. И не надо плодить каталоги, можно ж в нем все держать, в ветках!

Так в гите ж тоже можно было, улыбаюсь.
Ну да, там тоже... пробовали, но как-то... не получалось, что-то было трудно...

И не надо плодить каталоги, можно ж в нем все держать, в ветках!
Что-то я не уловил КАК они гитом пользовались? на каждую фичу git clone делали?

Facebook свого часу перейшов на mercurial бо гіт по перформенсу не справлявся.

Для решти 98% випадків різниці як такої нема, але в mercurial, як на мене, послідовніший cli

Не удивительно если держать в одном репозитории весом 50 терабайт?

Никто не отрицает пользы CLI, он прекрасно работает для автоматизации. Но сам факт, что ты знаешь те команды, которыми пользуешься часто. А там где раз в год от силы, а то и раз в никогда — вероятность ошибиться просто катастрофа, если умножить её на цену последствий. Уверяю, состряпать веб-морду на том же php стоит дешевле.

Я оце абажаю, 100500 варіантів робити одне й те саме (чи _майже_ одне й те саме) зі всякими неочевидними параметрами, до яких неможливо логічно і структурно додуматися.

І це КОЖНОГО разу, коли виходиш за рамки того, що робиш завжди, чи хочеш відкоректувати щось назад, то стоїть дилема — те то бровзати і пробувати усілякі merge, squash, reset, revert і т.д., чи банально зробити clone у сторонній каталог і руцями швидше перенести кілька файлів, чи кілька змін.

Скопіпащено з stackoverflow. Що роблять деякі команди — не перевіряв, тому, не треба мені пояснювати, що щось там зі списком не так.

git config --get remote.origin.url
git remote -v
git ls-remote --get-url
git reflog | tail -n 1
git branch
git checkout -b
git diff --name-only SHA1 SHA2
git diff --name-only HEAD~10 HEAD~5
git diff-tree --no-commit-id --name-only -r bd61ad98
git show --pretty="" --name-only bd61ad98
git show --stat --oneline HEAD
git show --stat --oneline b24f5fb
git show --stat --oneline HEAD^^..HEAD
git log --name-only
git diff --name-status <SHA1> <SHA2> | cut -f2
git whatchanged f31a441398fb7834fde24c5b0c2974182a431363

Напевне, при розробці git надихнулися списком схожих слів і наклєпали more than one way to do it
www.merriam-webster.com/thesaurus/git

На самом деле давайте не забывать, что пизде(выражать экспертное мнение) — не мешки ворочать, а поднять технологическую компанию в условиях, когда любой гигант может убить твой продукт просто подняв у себя в ДЦ еще пару тысяц сервачков — это еще надо уметь. Гугл терял данные, Амазон был погорельцем и тоже терял данные. Никого не распяли и в мешках не увозили. Я до сих пор держку в облаках данные, которые не самые критичные и значит глубоко в голове я готов к том, что они могут потеряться.

Меня больше интересует вопрос в том, КАК могло такое произойти? Неправильная архитектура репликации если она вообще была эта архитектура? Постоянный аврал и ни у кого не было времени проверить? Отстуствие тестирования?

Может же быть такое, что для экономии наняли молодого DevOps, на бумажке ему написали hdhdh01 — это наш прод, а hdhdh02 — это наш тест, давай работай, смотри не перепутай. Мне доводилось видеть такую кашу и это проблема тех, кто эту кашу заварил, а не тех, кто наделал фигни...

Залажаться можно в любом месте и любым образом.

Вот из моих реальных историй. Раз в сутки по крону ходил скрипт вида:


cd dir1
find ... -delete
cd
cd dir2
find . -atime +7 -ctime +7 -delete
cd

dir2 был что-то вроде /var/db/некая_прошлая_сущность/tmp/. Кто этот скрипт писал — ХЗ, кто-то до меня. Но dir2 удаляли уже со мной. cd dir2 не сработал и оно вычистило домашний рута. Невосстановимые потери — ключ к cvsup-master.freebsd.org (пришлось заказывать заново). Если бы перед этим было cd /, получился бы Бармин в чистом виде :)

Это все потому, что админы категорически не любят обрабатывать ошибки. Такие себе камикадзе ))

Достаточно хотя бы писать так: cd dir2 || exit 1
Ну и не запускать ничего от имени рута.

Или set -e в начале. Но всё это очевидное кэпство для тех, кто с опытом, но новость для тех, кто не проходил.

А полный путь скормить скрипту вместо cd — никак? Или так только глупые админы с маленьким ЧСВ делают?

Ну вот кому ещё тут повторить, что я не знаю, почему так написали? Становитесь в очередь.

Еще было забавно, когда на AIX у кастомера некий крон скрипт мимоходом прибивал jar-файлы нашей софтины. Случайно под маску попало.

поднять свой сервер с git, и там написать post push хук который будет после каждого пуша разливать в сервисы github, gitlab, bitbucket, s3, gcs, backkblaze, на флешку, и резать болванки )))

Вы в своем уме??? А как же на дискеты писать?? Как можно забыть обезопасить себя настолько?!

А если ядерная война?? Почему не пишем бекап на перфокарты?!

Если ядерная война — то скорее высекать на камне. Перфокарты из бумаги испортятся, из металлической плёнки пойдут в кузню как сырьё, а из какого-нибудь лавсана — в стены на утепление.
Идеально было бы придумать какой-нибудь полуразумный кристалл с питанием от человека, который держит его на себе, но до таких технологий нам ещё лет тысяча.

От EMP при ядерном взрыве не защитит прикрепление к телу :)

На самом деле вы правы, только не дискеты, а магнитная лента.

До речі, Гіт же розподілена система, повну копію коду з усією історією має:
1. Девелопер
2. Рев’ювер
3. Білд-сервер і ще хз хто.
Знайти найсвіжішу копію і запустити її хоч на офісному сервері, хоч на віндовс-шері тімліда, хоч на смартфоні директора, або на кавоварці — справа кількох десятків хвилин. Таким чином можна більш-менш комфортно дочекатися підняття серверів Гітлаб.

Іншими словами відповідь на ваше питання може звучати так: «Нахуа?»

Вы насчитали только 3. А у gitlab было 5 разных видов репликаций и бекапов. И это их не спасло.

Навіть один робочий бекап нескінченно кращий, ніж 5 поламаних.

Ну бекап у них был, судя по всему, просто 24-х часовой. Я к тому, что ни один из 3 выше изложенных пунктов не гарантирует 100% сохранность данных. Какие то куски, скорее всего да. Возможно из них удастся собрать все, а может и нет. Обычно локально ветки после мерджа удаляются, а бекмердж мог никто и не сделать с мастера. В индексе то оно остается вроде, но потом выковыривать оттуда будет еще то занятие.

В gitlab були бекапи не гіта, а БД.

Казнить админа нельзя помиловать

А теперь представим что в хранилище был код управления атомной станции.Представили?

По бесплатной подписке и в открытом доступе? Конечно, такое может быть

Ну, ключики доступа к амазоновским aws некоторые умудряются держать :D

И вы не успели его себе форкнуть, а теперь хренушки.

>This incident affected the database (including issues and merge requests) but not the git repo’s (repositories and wikis).

Код не постраждав.

Тут я, как очевидец, могу подтвердить, что сутки таки потерялись. Восстановили из локальных копий.

А есть фоточки админа? (ОСТОРОЖНО, ШОК, СЛАБОБЕРЕМЕННЫМ И НЕРВНЫМ ПРОСЬБА ОТОЙТИ ОТ ЭКРАНОВ!!!!!!111ОДИН!!!111ОДИН!!!)

Так похеревший админ вроде в Нидерландах, там паяльник в жопу не должны вставить, там же толерастия рулит.
Так, а может он из этих, дилдо-любителей? Только этого и ждёт %)

Я так и не понял, шутка это была или нет?

Это не шутка была, а печаль. И самое удручающее было то, что парни настроили резервное копирование в пять разных мест, но ни одно не работало нормально :)

So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.

Печалька. А как же программы по восстановлению данных?
Прочитал, вроде как восстановили с потерей последних 6 часов.

Вот хз какие такие «программы восстановления данных», вы ж это не серьёзно, да?

Сервера не их, тк Azure. Метаданные ФС, которые «программы восстановления» пытались искать по диску, у них снапшотились средствами LVM.

классика жанра:
бэкап есть только тогда, когда ты регулярно проверяешь, можно ли с него корректно восстановиться))

Как сиськоадмин со стажем разбил себе лицо фейспалмами — это что за такой «бэкап Шредингера»: толи он есть толи его нету ...

Прочитайте ссылки внимательнее — код они не похерили. Issues/MP только, репо и вики целые, так как отдельно лежат.

Сказали бы они другое публично? %)

Конечно, сказали бы. Они уже 60% данных вернули, когда буде 100 — все пойдут смотреть и все увидят, если бы они соврали про это, им капец. А так — еще выкрутятся.

Вот именно. Если бы сказали, что похерели код, то реакция была бы другой изначально и выкрутится не получилось бы, даже, если бы всё восстановили.

Да даже если бы код за последние сутки похерили, это коснулось бы дай бог чтобы 1% реп. А более ранние бэкапы у них были.

И у меня были бы локальные копии (ты забываешь, что это Git).

Конечно, это же лучшее место для хранения ключей к биткоин кошельку и ветпаспорта любимой кошки.

Как я писал выше. Скорее всего у тебя локально были бы только твои ветки, если ты не приучен их чистить после мерджа. И в лучшем случае актуальный мастер. Если ты успел сделать бекмердж до падения. В общем то все уцелело бы наверное, но работа твоей компании встала.

Скорее всего у тебя локально были бы только твои ветки, если ты не приучен их чистить после мерджа.

У каждого свои.
После чистки остаётся reflog с достаточным куском истории.

В общем то все уцелело бы наверное, но работа твоей компании встала.

Часа на три. Да, кому-то и это существенно.

Всё равно, поставленная под сомнение репутация стоит неизмеримо дороже, чем потерянный день работы или около того.

GitLab.com вже знову працює, проблема була лише з PostgreSQL базою даних, а там не зберігають git репозиторії, вони окремо. Теорії, що нам щось недоговорюють не виправдались.
Ми використовуємо цю систему, але не у cloud, а на власному приватному сервері.

Підписатись на коментарі