Линус и удалённая работа

medium.freecodecamp.com/...​x-c8d8ac30076d#.ynhd1lpun

Fact #4: The Linux Foundation pays Linus $10 million per year to continue his work on Linux. His net worth is $150 million.
Fact #5: Despite this the sums of money involved — and all the systems that rely on Linux — Linus works from home, alone, with his cat.

и это при том, что:

Fact #2: The Linux kernel is by far the most active open source project on Earth. Its accepts an average of 185 patches each day.

s.mail.ru/KycQ/mS2HbUv8b

На удалёнке сидят только верстальщики и индусы, которые делают клон гугла за 500$, ага конечно)

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

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

о, набежали фанаты «бесплатных» печенек в офисе, и свидетелей того что без надзирателя работы не будет

Я уже год как ушел с «офисов/надядю»
Что сказать — дома работать при жене и ребенке — не могу (
После 10 вечера — порой выходит что-то поделать

В итоге катаюсь по ковокингам (снимал комнату офис — имхо одному тоже не очень)
Плюсы ковокингов — все же люди социальные сушества.

Когда народ вроде как работает — и сам ютюб с котиками закрываешь
Дома даже когда нету жены-дитя — не могу работать =( То кофе варю то картошку жарю
Дома не работа, даже наверное громадный дом и личный кабинет не спасет, настрой не тот и атмосфера как для меня

С другой стороны — езда куда то через пол киева в офис избраной душегубки что бы отметится, тоже не выход.
ИМХО оптимальное — работа в ближайших ковокингах и +/- по графику
Вроде и офис — но без 25 пересадок и стояках в пробках

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

Я уже год как ушел с «офисов/надядю»
Что сказать — дома работать при жене и ребенке — не могу (
После 10 вечера — порой выходит что-то поделать

В итоге катаюсь по ковокингам (снимал комнату офис — имхо одному тоже не очень)
Плюсы ковокингов — все же люди социальные сушества.

Когда народ вроде как работает — и сам ютюб с котиками закрываешь
Дома даже когда нету жены-дитя — не могу работать =( То кофе варю то картошку жарю
Дома не работа, даже наверное громадный дом и личный кабинет не спасет, настрой не тот и атмосфера как для меня

С другой стороны — езда куда то через пол киева в офис избраной душегубки что бы отметится, тоже не выход.
ИМХО оптимальное — работа в ближайших ковокингах и +/- по графику
Вроде и офис — но без 25 пересадок и стояках в пробках

Тру стори.
Что всё-таки замотивирует работать, это Две удаленные работы.

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

Здається вже була історія як пан за двох джунів працював, але ви таки поділіться своєю істрією успіху.

А что рассказывать?)
Есть две удаленных работы за двух синьоров,иногда проклевывается третья, а учитывая, что заказчик «оттуда», можно спокойно делить рабочий день на две части незаметно.
И понятно, что в данном случае 8 часов рабочий день без бесконечных перекуров и бесцельного шатания с места на место.

Особенно, если аврал случится одновременно на двух работах (а по закону подлости именно так и будет :) )

Тогда, как говорится, только вперёд :)

даже перед релизами не бывает дедлайнов? 2 работы -это неплохо)
И кстати вопрос по теме -вы на дому работаете или в коворкингах?

Где это счастливое место где нет кондёра? 0-0

так в чем проблема? можешь — работай :)

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

vk.com/video159570_170873432

PS: Открой уже наконец для себя Scrum и последние методологии разработки где общение (не по скайпу, а стендапы, например) в ИТ конторах ставится во главу угла.

Идут в митинг рум и стоят? C кем? C менеджером из Штатов по скайпу?

Любая организация — кривая версия армии, даже доблестное махновское движение :)

так зе бест практіс якраз взяті із колишнього СРСР, тільки це не афішується

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

зато поблема зірки, забитої автобусом пропадає

це називається stand up мітінг :)

Я бы сказал что Линус сидит на нищебродской зарплате для таких проектов.
Для понимания, чтобы «заработать» свой первый миллиард ему прирйдется сидеть в таком режиме 100 лет и ничего не тратить.

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

Всё верно. Повезло что в начале его карьеры большинство сыроварен было закрыто.

Ну так Линус типичный outlier. Кстати он, что характерно, переехал в Штаты, и вроде бы работал несколько лет в какой-то местной компании.

Угу, жена, трое детей, спортивная машина :)

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

о, набежали фанаты «бесплатных» печенек в офисе, и свидетелей того что без надзирателя работы не будет

А что, Линукс это удачный проект? Lol! В более менее свежих ядрах выкосили даже поддержку COM мыши. А все дистрибутивы выглядят как попытка скрестить питона с носорогом. Причем если даже в винде можно найти откуда ноги растут, то в линуксе все упирается в пекеджи собранные непонятно как, непонятно для кого и имеющие десятки бекдоров. Толи дело, например, FreeBSD! Про нормальные коммерческие системы я вообще молчу. Хотя бы почитайте про NonStop OS, z/VM. А это так.... Баловство в серверной для порносайтов. И, блин, из терминалки сделанное. facepalm.jpg.

Троль? Лінукс це ТОП500 суперкомп"ютерів, Android+WebOS+Tizen+Sailfish+Pokky ( тобто більшість смартфонів, планшетів, читачок, телевізорів, приставок, інших всяких мобільних пристроїв), embedded (включаючи Soft-realtime, hard-realtime), 70% серверів інету, корпоративні системи, ну і на десктопах хомячків трішки. А serial mouse i ISA кому потрібні збираються...

Вот и я про что! Как говорит BBC — 37% всего интернета это прон. Добавим сюда 33 процента хомячков (не думаю что их больше трети) и получаем ваши 70%. А нормальные люди серьезными делами занимаются.

Продам com мышь, б/у, по цене антиквариата. Дискета с драйвером под Виндовс 3.1 в подарок.

С шариком или оптическая? Дискетовка читается или вы мы мне фуфло парите?

Мышь с шариком. Оптическая сom мышь — супер антиквариат, любой музей обзавидуется. Дискета идет в подарок, а дареному коню, как известно, в зубы не смотрят. Но за дополнительное вознаграждение могу дискетку проверить.

Да, есть и такое добро. Покупайте. Тем более что поддержку флопиков еще не выпилили.

Та вже маю. Навіть 5″ та з USB. Мене більш цікавить клава PS/2 від Дігітал компутерс. Можливо навіть без кацапських та хохляцких літерок.

5″ c USB? Месье знает толк в извращениях!
А кто такие «Дігітал компутерс», и чем их PS/2 клава отличается от IBM-ской PS/2?

Не. Пятерка у меня обычная. А треха есть и с usb. А дигитал то DEC. Есть у меня в загашнике компутер моей мечты середины 90-х. Пенек 120-тый, 92 метра памяти, S3 Trio о двух метрах видео, Вуда 3dfx, SB16 исашный. Хочу под него кнопки оригинальные. ;-)

фу... дек на альфі тре а не інтелі

Тогда все-таки “Дігітал компутерс”, потому как у DEC не было модели, с которой можно было бы собрать такую конфигурацию.

Хммм... мы всю жизнь считали что это дек goo.gl/photos/BXcvFDV85UAHTZqa8

Да, по лейбле точно DEC. Но Википедия об этой модели умалчивает, видимо последователи DEC не считали эту модель значимой.

О что COM мыши еще продаются — музеи уже давно их все разобрали. Насчет дистров — это ты хромобуку скажи, который в этом году обошел по количеству венду и маки вместе взятые. А NonStop — это че радио такое ? Нормальные коммерческие системы — это то что входит в TOP500 суперкомпьютеров, так там 99.x% Linux систем, шоб ты был в курсе. И нет там ни фри, ни твоего радио...

Вай-вай-вай! Топ-500? А что такое топ-500? Всего лишь числодробилки. Поймите, если вы поставите тысячу кофемолок, то вы сможете только быстрее молоть кофе. Обогащенный уран вы из них никак не получите. Касательно NonStop, вас видать за школололовство уже и гугель забанил.

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

А на чем эти триллионы считают? На Tandem-ах. С точки зрения задачи учета банковских транзакций в рамках любой страны Линукс выглядит не более как habrahabr.ru/post/245443 с подпорками из говна и палок. Учите матчасть, а то так всю жизнь фигней заниматься и будете.

Вы бы сначала с COM-портами в Linux разобрались, потом подождали пока ваше отстойное радио войдет в TOP500, а потом и продолжим. Как говрят на востоке — «В засохшее дерево — камней не кидают». Покеда

А кому ваш топ-500 нужен? Какая у него реальная отказоустойчивость? А что с транзакциями на уровне железа? Можно ли залочить транзакцией строку в любом текстовом файле? Нет? Лососните тунца и кукарекайте с Линуксом дальше.

А кому ваш топ-500 нужен? Какая у него реальная отказоустойчивость?

Между прочим, офигенно высокая. Так, что позволяет собирать задачу на партицию в 1000 узлов и не предполагать более чем одного отказа на всю партицию в 2-3 месяца (чего даже с суточным checkpoint’ом достаточно, чтобы не плакаться). MTBF можешь подсчитать и сравнить сам...
(Только логи MCE загаживаются, ну что поделаешь, x86...)

А что с транзакциями на уровне железа? Можно ли залочить транзакцией строку в любом текстовом файле?

Это всё-таки был HPC, а не HAC. Там запросы «немножечко так» другие.
С другой стороны, вынос транзакций на уровень ОС и железа оправдывается очень ограниченно — теория развивается, а железо так быстро не разовьёшь. Вон в MVCC базах оптимальные уровни изоляции вообще другие, чем в стандарте SQL, который писался под блокировочники, а кто теперь тот стандарт адаптирует — он же памятник...

Почему не разовьешь? HDL-ы, плиссы и китайцы все еще живы. )))

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

Как раз перегон на железо сейчас делается легко и непринужденно. Великая весЧь — эмуляция. Так работает энвидия и амд. Стоят кластера которые которые гоняют hdl. Отрабатывают логику, прогоняют эмуляцию взаимных наводок, энергопотребления и система им рисует готовый чип. Все просто и непринужденно. Сложнее потом с софтом. Но это отдельная история....

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

А так можешь свой камень нарисовать и в производство отдать. Цена тебя приятно удивит.

А на чем эти триллионы считают? На Tandem-ах.

На zSeries, по идее. Или вообще на AS/400. Но на первых — больше. Что-то я очень давно не слышу про Tandem...

Линукс выглядит не более как

Я вот сильно подозреваю, что подход z/Arch к вопросу надёжности операций оказался более живучим, чем Tandem’овский с компанией.

а то так всю жизнь фигней заниматься и будете.

:)

Пане Нетч, я с Tandem-ми уже как 14 лет завязал. ;-) Но вроде как живы. Правда с MIPSов свалились на x86 процессоры. И хоть сейчас работаю с z/System то ощущение того что NonStop надежней меня не покидает. Хотя у зетов и и камни свои... И с точки зрения кода и SQL выглядят они как родственники (если не брать в расчет зетовский IMS и JCL, их аналогов на Тандемах я не помню). У Тандемов основная фишка в том что у них всегда процессорных модулей больше одного. И для каждого процесса существует бекап процесс на другом CPU. У зетов, я думаю, тоже возможно подобное решение. Но живьем «из коробки» я его неувидел.

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

У «зетов» режим контрольного повторного исполнения одной и той же команды — и вместе с остальным сквозным контролем всего — считается достаточно надёжным, насколько я понял, чтобы не заниматься FSM-стрельбой из кривого ружья из-за угла. Я бы построил, конечно, на это скаптическую рожу, но реальных данных у меня нет, а строить её в вакууме не хочется.

Правда с MIPSов свалились на x86 процессоры.

Вот это меня сильно смущает. Похоже, что им дико не хватало каких-то отдельных фишек современных x86, но ради этого переходить на сверхсложный неуправляемый комбайн...

Как я понял, их начала поддавливать производительность и стоимость хардварного развития ихнего решения. Тандем (во всяком случае тогда) работал очень хитро. У него любой чих был транзакцией. И для каждого действия запускалось два процесса на разных cpu. Если их результаты не совпадали, все откатывалось назад, запускалось на другой паре и результаты сравнивались с предыдущими. Определялся дефектный cpu и маркировался как не рабочий...

И для каждого действия запускалось два процесса на разных cpu.

Да, я помню.

запускалось на другой паре

То есть реально на такую схему надо было 4 процессора. Как-то это странно. Если один маркирован дефектным — остальные 3 должны были стать в общую группу с арбитражем...

Ты понимаешь, я вот точно помню что эта штука так работала при наличии двух процесорных модулей. При этом у нас она как то раз один из них промаркировала как дефектный. А оставшийся мы как то хитро залочили транзакцией в дедлуп. И вот пока нам везли новый модуль.... мы попросили помочь нам Тандем перезагрузить. Тогда это кажется был уже Компак. В начале они офигели, а потом сказали нам сделать следующую последовательность... Выдернуть из него на ходу дохлый модуль. Выдернуть из него все три линии питания. Он при этом переходит на встроенные упсы.... а потом выдернуть рабочий процесорный модуль. После этого он отпислся в лог что у него все плохо, закончились cpu и он сохраняет свое состояние. Затем все в обратной последовательности. Только вместо дохлого уже живой. И о каждом действии есть запись в логе.... Тогда меня это несколько, скажем так, шокировало.

Да, отсутствие явной команды на такое тут как-то очень подозрительно. Должны же они были тестировать свои механизмы?

Там фишка в том была что оставшийся живой процессорный модуль свалился в дедлуп внутри какой-то транзакции. И админы не могли открыть на него даже терминал.

У зетов, я думаю, тоже возможно подобное решение
IBM Parallel Sysplex
сейчас работаю с z/System
стикеры на них на конвейере клеите?

Да, и COM мышь работает даже в последнем Linux ядре, ты походу не в курсе что там протокол реализован в user-space с помощью GPM. А COM’ы никто из ядра не удалял. Так что просвистел ты тут. Твой пост очень напоминает недавний ролик от m$ где они сравнивают surface планшет с mac-book’ом... тот же посыл ;)

Вот и я о чем! Вынесли в юзерспейс. Нелюди.

А в макосях вообще почти всё хорошо замаскированный юзерспейс — и ничего, косят бабло :)

а вот в IDC думают совсем по другому


The world wide market for Unix -based AL4 server revenue is projected to decline from nearly $4
billion in 2009 to almost half that amount in 2018 because IT is abandoning Unix.
On the other hand, revenue for AL4 Linux systems is forecast to grow from near zero in 2009 to almost $1 billion in 2018 given that IT is looking for standardized solutions and open source Linux fits well with the rest of the infrastructure. Finally, revenue from other operating systems in AL4 is slowly declining as well.

ко мне приходит мотив,я подбираю слова

Так не стоит задавать мелодию ))

Кажется, кому-то пришло время отвлечься от написания клона гугла за 500 баксов и узнать про правило трех сигм )

Fact #5: Despite this the sums of money involved — and all the systems that rely on Linux — Linus works from home, alone, with his cat. Here’s a picture of him at his treadmill desk:
cloud.mail.ru/public/KycQ/mS2HbUv8b

WTF?! Where is the cat?

WTF?! Where is the cat?
блин, я тоже хочу посмотреть на кошака Торвальдса!)

Фотку кота Торвальдса в студию, плииз!

нельзя сравнивать х с пальцем и пытаться натянуть статистику на гениев

так фишка в том, что статистики то и нет никакой, никакой науки — сплошные экспертные мнения.

ну я не уверен что Линус можно считать гением. не, я понимаю что он классный спец и все дела.
но както до гения (ну он точно не Энштейн или Тесла) не дотягивает.

Он не гений как Энштейн, а гений как Линус :) считать его гением — разрешаю

а в чем проявилась его гениальность?

он стал пионером, но в целом линукс не был системой с новым/исключительным подходом/архитектурой, это результат качественного инжинерного труда

Качественного? Не смешите мои носки!

Ага, качественный код 20-летнего сеньора)

Да, его препод не заценил

помню свою первую работу, работал с чуваком которому было лет 20 тогда.
так вот, так как он писал код, так не все 30 летние синьоры пишут.

Такая же фигня, тимлид был на 10 лет младше, но таки тимлид :)

Чувак просто очень везучь, из-за ситуации с BSD, x86, GNU. А так обычный известный системный программист.

Не знаю как насчет гения, но обычным програмистом я бы его не называл. Сначала линукс, потом гит. Совпадение? Не думаю. ©

чувак правильно видит куда ветер дует, что в целом редко встречается.

А что git это удачное решение? Lol! Более дурацкой системы хранения версий я не встречал.
Если бы git-а не было, его нужно было бы написать что бы поржать над теми кто им пользуется.

Вот я и говорю — ржака и бугогашенька!

Стесняюсь спросить, чем люб SVN? :)

Минимумом git овладеваешь дня за два, полно gui клиентов. Имхо, дело привычки :)
Основной плюс — бренчи-мержи делаются на ура, никого не трогаешь, храни хоть десять веток у себя на машине.
Был после git SVN — ставил git-svn, сейчас TFS, подумываю поставить git-tfs.

Ну, фломастеры на вкус значит разные.
N.B. Хочешь на сервере — храни на сервере копии локальных веток, только и всего :)

SVN + бренчи с мержами == Армагеддон с холокостом
Git в этом плане напротив, любовен и прельстив, за это и любим :)
Это тебе конкретные аргументы, давай, возражай:)

А еще меньше место бранчи занимают на HDD в разы, насколько я понимаю

Нельзя ли претензии как-то формализовать(1, 2, 3)?

В чем минусы? Отвечали же :
— без линух вай можно обойтись
— гуй клиенты есть
— можно спокойно работать в svn стиле, не лазя в дебри мощной функциональности
П.С. Есть момент где SVN уделывает, не спорю — работа с бинарными файлами :)

1) Для SVN — полный рай с клиентами на всех операционках? Просто информация интересна.
2) В git (да и любом распределенном VCS) полный ад начинается, когда нужно версионировать бинарники. Lockа нет (((.
3) Сейчас работаю с TFS, Убожество клиентов заставляет задумываться о внедрении git или svn моста :)

2) В git (да и любом распределенном VCS) полный ад начинается, когда нужно версионировать бинарники. Lockа нет (((.

А чем бы тут помог лок?

Не дал бы внести в репозитарий новую версию бинарника+ сообщил бы коллегам, что данный бинарник трогать пока нельзя.

даешь вообще полное отсутствие VCS и баг трекеров! У меня бывший директор так работает. Баблу с джипом это не мешает :)

По бинарникам — фатальный недостаток, обусловленный распределенной архитектурой.

И да — мне это как то все напоминает замечание Буденного о ППШ : «ну, стреляет хорошо. Но где патронов напасешься? А в рукопашной — вообще дрянь» :)

А в чем убожество клиентов (и какой версии) TFS?

VS 2010, VS2013
Сложно искать changesets и невозможно united diff на ревью. Обложился плагинами и на время успокоился :)
ППКС — habrahabr.ru/post/223797

SVN — просто проще и удобнее

Смищно.

в последних, если память не изменяет добавляли распределенность.

SVK — это отдельный проект.

И да, жду поста в стиле, не нравится напиши свой.

Ты его уже написал :)

Реально удобный только в Винде — Tortoise. Все остальные клиенты как бы сказать, странные.
ну гит (впрочем как и другая популярная система контроля версий — меркуриал) — изначально консольное. Поэтому ИМХО было бы странно, если бы все поголовно стали бы клепать няшные гуи «с блэкджеком и шлюхами»)
А Toroise видать сделали специально для пользователей «окошек» и для привыкших кликать мышкой.

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

нет аналога Черепахи (точнее есть, но вечно глючный и нерабочий).
это какой имеется ввиду?) просто интересно.
Имхо — это идеал организации GUI работы с системой контроля версий.
ну не знаю, «черепаху» не юзал) стандартного гуя для гита (в линухе оно будет вызываться через git gui, для винды оно называется Git for Windows) — мне хватает. И я бы не сказал, что оно
как для инопланетян
может потому, что я не такой привередливый к гуям для консольных утилит, как ты)

Кстати да. Я бы тоже не против закинуть в запароленный архивчик репозиторий со всеми бранчами. Это можно как-то просто сделать?

Наверное, в вопросе есть какой-то подвох, но я его не чувствую. Что мешает сделать архив каталога проекта ? :)

И потом, распаковка его на другой машине, я получу солюшен со всеми ветками и коммитами которые были на момент архивации?

Есть SourceTree, для Mac единственный бесплатный нормальный.

GitEye еще был, но он на базе Eclipse — соответственно, тяжеленный и хочет Java.

Вместе с тем, после SourceTree пользоваться им было вполне можно.

Естественно, у меня тяга к гиту основанна не только на стремлении к извращениям :)

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

на днях пришлось тяжкий випадок лікувати:
у сабмодулі бранча поміняв файл, потім бранч видалив,
і хотів обновити мастер, і тут засада, гіт побачив що є незакомічений файл, якого в природі вже не існує.
error: Your local changes to the following files would be overwritten by checkout:
Що тільки не пробував, які тільки поради не вичитав,
в кінці кінців, десь хтось на стекооферфлоу написав один із 100500 варіантів який ніби то може помогти, якщо піти в папку сабмодуля зробити:
git reset HEAD —hard
а потім вернутися в основний гіт і
git submodule update
і дійсно,
півдня вилетіло в трубу, але рішення знайшлося (щоб побороти розумний гіт)

мене git оцими кроками вліво-вправо від чогось простого добиває
особливо всякі ’логічні’ і ’послідовні’ параметри команд

Submodules — немного диверсия, но я думаю, что в этом случае нашёл бы решение минут за 5. По крайней мере, hard reset тут очевидный первый шаг.

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

Большего уродца, чем SVN, не видел. Охотно верю, что всякие VSS и TFS хуже, но, извините, не юзал-с.

Обычно говорят, что SVN удобен тем, кто работал с CVS, а перейти на распределённую систему после этого сложно. Мне оказалось иначе — Git освоился влёгкую, а вот SVN или ещё один костыль в лице Mercurial пошли лесом.

Мимими! Найди в куда в гите вошли твои изменения от позапрошлого года. Учитывая что ты точно помнишь что это был фикс для релиза 124.22

В бранч 124.22, ясное дело, а куда еще?

Мимими! В гите? После куа, трех фиксов, код ревью в гиториусе и аджайла со свистоперделками?

И что из этого мешает?

Думаю для человека, который запоминает пятизначный номер релиза позапрошлого года, это не проблема.

Ну если ты знаешь, какой релиз, то для него есть ветка. Это уже соседи по дискуссии сказали.

А вообще в commit message лучше хранить номер тикета, по нему легче такое определять.

Меркуріал — розподілена система

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

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

не знаю не пробував

О. А я пробував. Це жах.

а хаваючи гітом схрещений із геррітом поки крім блювати не викликає інших вражень,

І Gerrit — дуже непогана штука, коли треба peer review і схвалення від колег. Що саме не вподобалось?

Джоин ченжей от каждого коментария в единое непотребство. В результате забываешь о чем шла речь изночально собирая это в единый.... как он там называется?

Джоин ченжей от каждого коментария в единое непотребство.

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

Ага! А вот с комитом в транк я с тобой не согласен. Я видел вариант когда в транк каждый день комитятся изменения даже без проверки того что оно собирается. Но по транку ползут теги stable и release. Вполне рабочий вариант.

> Но по транку ползут теги stable и release. Вполне рабочий вариант.

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

Это будет работать только при дополнительной мере в виде периодов, когда всё новое замораживается нахрен и только и делают, что лечат. Но тогда вопрос — зачем так работать??? Пусть будет хотя бы ветка stable, в которую переносить исправленное — это уже хоть какая-то гарантия.

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

Там каждый работал со своим модулем. Что-то закончил — пометил как stable. Куа забирают stable и либо возвращают и дев двигает метку дальше, либо маркируют как release. Хоть пристрели не помню что мы тогда использовали для контроля версий. Кажется чуть ли не CVS. Хотя кажется было что-то виндовое, загадочное и такое что я больше нигде не встречал.

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

тобі тре всі локальні коміти звести до одного, який і передається на рев"ю.

Звільнятися. Бо нормальної праці з кретинами, що ввели такі правила, не буде.

то звільняйся, хто тебе тримає

Я не працюю там, де кретини у керма :)

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

Я просто оставлю это здесь:
programmers.stackexchange.com/a/263172/165133

Разумеется, не надо пользоваться этим инструментарием бездумно. Но когда после трёх итераций code review накапливается 5-10 мелких коммитов с фиксами, тащить всё это в исходном виде в dev ветку как-то не очень целесообразно.

Ну, или когда у разработчика «commit paranoia» и он в feature branch коммитит по мелочи несколько раз в день — зачем тащить вот это всё в dev ветку?

Я просто оставлю это здесь:

Публично выставленный лог не должен быть отражением потока сознания разработчика, да.
Он должен быть цепочкой цельных изменений, каждое из которых элементарно или хотя бы несложно, и только одного характера из набора — стилевые правки, рефакторинг, изменение функциональности. Возможно и более глубокое деление — например, не надо смешивать reindentation с переносом в другой файл — но предыдущего достаточно для затравки.
В качестве положительного примера можно смотреть на LKML — там нормально, что к одному из коммитов забыли ещё пару зависимых мест, и их исправление лучше соединить с тем же коммитом, а не ставить в хвост по принципу «ой, забыл».

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

Ну, или когда у разработчика «commit paranoia» и он в feature branch коммитит по мелочи несколько раз в день — зачем тащить вот это всё в dev ветку?

См. мой первый абзац текущего сообщения.

в ветке пара рефакторингов, правка багов и новая функциональность, а потом всё это мержат в один коммит в дурно пахнущую кашу

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

Що один каміт тре жувати і пережовувати 100500 раз.
Тіпа кожен каміт — ідеальний клінкод.
В кінці кінців — все одно тести красніньки і нада шото вигрєбать, і тут начинається чорна магія вуду.

Тіпа кожен каміт — ідеальний клінкод.

Додержання цього ідеалу не залежить від gerrit чи будь-якого іншого засобу. Але з ним, безумовно, зручніше.

В кінці кінців — все одно тести красніньки і нада шото вигрєбать, і тут начинається чорна магія вуду.

Це проблема на зовсім іншому рівні. З чого це тести раптом червоненькі, як ті когути? Якщо було відомо, що буде ламатись, треба було підготуватись?

Це проблема на зовсім іншому рівні. З чого це тести раптом червоненькі, як ті когути? Якщо було відомо, що буде ламатись, треба було підготуватись?
умний да?
якщо в тебе юніт тест на машині,
модуль і юніт тести на сервері з емулятором,
а в житті, воно взагалі на зовсім іншому залізі....мультізадачне і мультіпроцесорне (розподілені системи),
не у всіх же стартапи з котятами і репозиторій на 3х користувачів
умний да?

Щонайменше, намагаюсь бути. Годин по 6 на добу :)

а в житті, воно взагалі на зовсім іншому залізі....

Колего, Ви згадали зламані тести в одному конкретному контексті. Коли спочатку «ідеальний код» в засобі для цього, а потім все згамалось. Не треба розширювати контекст на всі випадки в світі, включаючи загибель Тітаніка і вибух Кракатау, бо користі не буде.

Так от — якщо треба зробити щось дивне і некрасиве, то його теж бажано переглянути і, з поправкою на ціль, прийняти (залежно від ситуації, дозволяються пояснення в коментаріях, навіть лайливі, червоні мітки в документації, і т.п.) І так, якщо треба для цього, щоб 2-3 колеги переглянули і схвалили — краще, якщо вони переглянуть і схвалять. Бо далі вони знатимуть, що тут є пастка.

не у всіх же стартапи з котятами і репозиторій на 3х користувачів

Або притримайте себе від таких натяків, або я цю гілку закрию за нестямністю співрозмовника, і казатиму, що котятки саме у Вас.

>> Що саме не вподобалось?

Те що є GitLab, Gogs і т.д.

Л — логика

Так может вы поделитесь вашими генильными решениями ? Например собственным ядром для OS ?

Зачем мне свое? Я сейчас по работе пользуюсь нормальным коммерческим.

Ну как чем :D Ничего своего ума не хватает написать — обгавкать написанное кем то, это легко — очередной «облизыватель микрофона», проходим мимо :D

Мне интересна реализация термина «нормальное коммерческое» :)

с подобными взглядами нужно писать исключительно на COBOL-е, а не на каком-то C++ :-)

PL/1, если уж на то пошло.

Боюсь ошибиться, но вроде читал, что для этого класса ОС давно уже портировали все современные языки программирования, кроме, разве что, специфичных для Microsoft.

Java, по крайней мере, точно упоминалась.

тем не менее есть еще куча приложений, написанных именно на коболе, хотя новые модули к ним уже могут писать и на Java, C++ и так далее
но имелось ввиду совсем не это :-)

Ой тут я с тобой не помирюсь :)
А что тебе лучше? SVN? Hg? Darcs?

Валик, да мне нравится SVN. Он простой и трехугольный. И для пректов до десяти участников он офигителен и прекрасен. Но сейчас, по причине ортодоксальности, мне приходтися работать с SCCS.

Валик, да мне нравится SVN. Он простой и трехугольный. И для пректов до десяти участников он офигителен и прекрасен.

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

Но сейчас, по причине ортодоксальности, мне приходтися работать с SCCS.

Вечно ты во что-то супероригинальное вляпываешься ;)

Валик, я стараюсь. ))) То чем я занимаюсь вообще начали портировать с UNIX-а на MVS еще в начале 80-х.... Тот неловкий момент когда работаешь с исходниками котрые старше чем ты. )))

Я тебе скажу больше. Я встечал оригинального куа который предлжил каждому девелоперу коммитится в саою ветку. Ой сорри. Не так. Ветка на таск. ))) Это произошло вместе с введением скрама. ))) Я так никогда не ржал. ))) Что интересно это даже пару месяцев прожило. А потом еще пару месяцев все смерживали обратно. ))))

Ветка на таск. )))

Это как раз совершенно нормально. Если проходит какой-то контроль (ревью), а потом мержат в целевой трейн сразу, а не тянут до дедлайна.

А потом еще пару месяцев все смерживали обратно. ))))

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

Один текущий коллега ругался в этом плане страшными словами на свою работу, кажется, в глобале для Tex.Ins. — он обязан был сдавать правки на ревью, и пока проходило до этого ревью месяца 3, целевая ветка успевала убежать. Приходилось делать новый цикл, на него опять тормозили... в общем, сбежал он оттуда, хлопнув дверью.

Я сторонник того что все коммитятся в транк (это на комендах до 15 человек, законы Паркинстона, бла бла бла). От транка делаются релиз бранчи которые уходят в куа. Фиксы из бранчей мержатся в транк, а бранчи вливаются в стейбл и уходят в мир.

Если у тебя все матёрые зубры в теме и в качестве кодинга — да, может быть.
Если есть явные юниоры — предварительное ревью лучше для всех, включая ревью падаваном кода гуру (правильный падаван постепенно смелеет и начинает задавать каверзные вопросы). А это неизбежно тянет за собой предварительные бранчи и возможную переделку по нескольку раз (хотя удобнее это делать в том же gerrit).

Тот, кто не понимает, что ученичество — нормальная и обязательная фаза развития, таким «индусом» и останется. Причём у него как раз шансов на развитие будет меньше.

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

Мне не напоминает. Отличное средство для высококачественной работы, причём из всех сейчас доступных на рынке без предварительных объёмных вложений — лучшее.

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

За всё время его активного использования — с ~2008 — я не видел ни одного шага, который бы реально был на пользу «индусов» и против профессионалов — в отличие, например, от ближайшего аналога и конкурента. Для меня это говорит более чем достаточно.

на мільойони ліній говнокода один із варіантів рішення, так як крім гіта є ще мінімум з десяток систем контроль версій

щось таке тобто подаван слонить мастер у свій бранч, шпілить код, комітить в геріт у персональну гілку,
супергуру дає оцінку, якщо +2, коміт автоматом мерджиться із бранчом, або відфутболюється, і далі колотається код джуном, поки не досягне потрібного рівня бути удостоєним +2.
Потім код теститься, і якщо тести дають ОК, робиш ще раз власний бранч береш cherry-pick і робиш ще раз коміт на рев"ю гуру, щоб коміт пішов у мастер.
Якщо тести не ОК, або гуру не дає +2, то далі код товчеться як вода в ступі, поки не набере потрібних кондицій.

для великих роздутих проектів гіт+геріт одне із рішень.
тобто не галери вирішують, якщо їм перепадає івно мамонта на підтримку\розвиток.
все зроблено до галер.
галери або беруть гребців під конкретні весла, або научують\переучують\доучують.
в залежності кого можна хапнути з вулиці.
от тут і одна з причин для код-рев"ю, щоб не поламали те що працює

Ну то есть в гите принуждение к обучению джунов по-сути?

Связь в обратную сторону — если требуется такое принуждение, то нужны и соответствующие инструменты, как Gerrit. Сам по себе Git допускает любой подход.

Т.е. гит идеален для галер?

Для галер не идеально ничего. Но на гите, да, удобно строить адекватные обвязки. Как и для массы других подходов, персональных репо и вверх до LKML-базара и типичных продуктовых компаний.

Возможно это фичу я не признаю, потому как не работал в галерах,

Я тоже не работал в галерах, что не мешает отдавать Git’у должное. Даже для персональной мелочной работы он удобнее конкурентов.

Т.е. гит идеален для галер?
Как процесс настроишь, можно и в одном trunk всем работать :)

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

По религиозным причинам мне не очень хочется претензий со стороны администратора сервера.
Хочу локально, без сервера хранить историю моего теплого и мягкого кода.
Git мне это дает+клевые мерджи с ребейзами. Пускай я извращенец, но мне хорошо, сухо и комфортно :)

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

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

Регулярно делаешь push своих изменений в центр — и тогда это окончательно их забота.

А если в чём-то не настолько уверен, что его не спешишь пушить, то тут в SVN ты просто не можешь его закоммитить, а в любой DVCS ты просто фиксируешь его локально.

Зависит от. Часто бывает, что на рабочей машине это забота админа — как минимум в варианте «еженощно бэкап всего из основных каталогов». Может и чаще — если какая-то приблуда постоянно следит за FS.

И опять-таки — если ты не уверен, можешь запушить в личную ветку, но не в общую; если совсем не уверен — то вряд ли оно такое нужно — восстановить будет возни на пару часов максимум.

А переключение в svn проще, просто переходишь в другой каталог и там работаешь и не надо никаких команд системе котроля версий.

Git позволяет
1) отделённую локальную копию на том же репо
2) клонирование локального репо с хардлинками файлов (до полной перепаковки — нет дублирования файлов)
3) просто полное клонирование

первый вариант — идентичен тому, что у SVN.

Я вызубрил набор нужных заклинаний за день, потом наращивал how to.

В том и дело, что мне Git значительно проще, чем SVN.

Это gerrit так работает. Штука поверх гита

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

Саме так. Але в правильно налаштованій системі тести в вибраному CI запускаються автоматично, і супергуру може не приступати до аналіза, поки CI не схвалить. Тести можуть бути як суто функціональні, так і стильові (на одному проекті у нас був прикручений cppcheck і в тесті перевірялась доповідь про кількість помилок стилю; ліміт регулярно знижувався).

Відфутболити за причиною несумісності (автоматичний мерж не справився) — в нашомі відділі було вкрай рідко; в сусідньому, про який я писав, що вони відкладали всі мержі до дедлайна — типове, але всі знали, що то їх внутрішня проблема.

Потім код теститься, і якщо тести дають ОК, робиш ще раз власний бранч

Вже казав вище — ось тут помилка (крім випадку, коли є обовʼязкова частина ручних тестів). Автоматичні тести повинні були пройти самі. Ручні — людиною після початкового схвалення іншими. «Ще раз власний бранч» це якась ваша місцева самодіяльність; може, саме в ній були всі ваші проблеми.

і робиш ще раз коміт на рев"ю гуру, щоб коміт пішов у мастер.

Не треба, якщо гуру схвалив, то він це зробив з самого початку.

удобнее это делать в том же gerrit
для кого зручніше?
чим зручніше?
для кого зручніше?

Для всіх, кому треба результат :)

чим зручніше?

Власне його функціональністю. Легкий спосіб передачі своїх змін на обговорення, автоматичне групування в ланцюжки. Автоматичне сповіщення зацікавлених про нове ревʼю.
Інтерфейс показу змін, коментування, дискусій, оцінювання. Регулювання прав учасників. Підключення автоматичних учасників (як Jenkins у ролі доповідача про результати тестів).

Недоліки є, але головним чином для адміна. У налаштованій системі простий учасник — ревʼюєр має замислюватись тільки над одним питанням — чи до вподоби йому запропоновані зміни.

ти дивишся з точки рев"ювера
я з точки зору подавана
та в інструменті зробленому програмерами для програмерів зручності і юзабельності дивно було би очікувати

ти дивишся з точки рев"ювера
я з точки зору подавана

Я дивлюсь з обох. Бо проходив це і в ролі падавана в незнайомому проекті, і гуру в такому, що вів майже десять роуів до цього без Git (в CVS), і просто ревʼюєра там, де тільки торкався головних частин.

та в інструменті зробленому програмерами для програмерів зручності і юзабельності дивно було би очікувати

Ти не менше, воні є, і більші, ніж у конкурентів. Хоча деякі риси, які були спочатку тільки у Git, Tortoise’вці зараз впровадили майже всюди.

для мене це чергові три костилі, звязані ізоляційною стрічкою
git — gerrit — jenkins
і ніяке не найкраще рішення

Все костилі, крім столів :)

Тоді розповіж, який варіант був би не костильним.

якийсь інший, ще не написаний,
програмування молода індустрія, тільки стає на ноги,
от ліплять із івна рішення, як можуть

Тобто конструктивної відповіді не буде. OK, зрозумів.

а тут що, має кожен погодитися із генеральної лінією партії?
я висловив свою думку.
Якщо ти чекаєш, що я стану фанатом гіта або свна, або ще чогось, то довго будеш чекати.

а тут що, має кожен погодитися із генеральної лінією партії?

Не має. Але «зараз зовсім нема нічого крім костилів» це тупо марно.

Якщо ти чекаєш, що я стану фанатом гіта або свна, або ще чогось, то довго будеш чекати.

Фанатизму і не треба було.

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

Ні, може бути декілька.

ну хоча б тому має бути дабл чек,
не може бути гуру гуром у всьом

Так а для чого тут двічі засилати один і той же патч? Просто чекаєш схвалення від обох — на одному і тому ж changeset’і.

Длинна каждого бранча была максимум трое суток. И четыре девелопера.

Это ж в общем случае непредсказуемо, на сколько занянется конкретная разработка пусть даже чего-то мелкого. И не будет ли после первого же показа сказано «вы не так сделали, тут нужно предварительно отрефакторить два слоя и только после этого делать основное действие».
В этом смысле отдельный бранч это показательная версия для ревью. Её можно представлять действительно отдельным бранчем, можно pull request’ом из своего репо (так работает github и ему подобные локальные установки), можно, что любая цепочка коммитов вначале проходит ревью, но после одобрения автоматом мержится в целевую ветку (случай gerrit).

Все эти варианты совершенно нормальны. Главное одно — если принято решение, что эту правку принимаем, то не затягивать с мержем.

В Порте именно на этом были заметные грабли. В одном из отделов из-за большого количества сотрудников и невозможности разбить на мелкие группы получалось сначала, что один патчсет мог требовать одобрения десятка человек, и это набиралось много дней. Потом подходило время дедлайна на сборку этого всего в целевую ветку («конец зелёной зоны»), и начиналась судорожная активность по мержу, при том, что патчи начинали мешать друг другу, а время поджимало...

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

Там меньше чем за неделю ветки успевали разнежатся так что их смерджить было уже нереально. При этом это были не фиче бранчи, а таск бранчи. Т.е. на трех разработчиков получалось порядка 15-20 веток. Часть из которых содержала несовместимый между собой рефакторинг. )))

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

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

Tex.Ins. — он обязан был сдавать правки на ревью, и пока проходило до этого ревью месяца 3, целевая ветка успевала убежать.
це все для супер-пупер кволіті полісі, щоб була на 5 рівні якось моделі,
строго по процедурам системи управління якістю

Записано ли в этих процедурах обязательное торможение ответа? :)

дивне питання, звичайно що ні.
Просто мало протеститися, на емуляторі, на залізі в лабораторних умовах, на залізі в польових умовах.

це все для супер-пупер кволіті полісі, щоб була на 5 рівні якось моделі,строго по процедурам системи управління якістю
Ну так до чого тут git? Чи gerrit? Якщо невігласи написали полісі і ніхто не бунтує :)

Гит это просто отличное решение

отличное решение
от других (з реклами)

Коментар порушує правила спільноти і видалений модераторами.

Сидит себе, кнопки нажимает )

Идёт, если еще точнее

на TED talks он говорил что уже сидит.

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