После трёх месяцев разработки опубликован выпуск распределенной системы управления исходными текстами Git 2.46. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Код Git распространяется под лицензией GPLv2+...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61627
Это уже напоминает комбайн, а не просто систему для управления исходными текстами...
В противном случае появился бы альтернативный комбайн. Который вытеснил бы сабж.
Да вытеснить не проблема. Желающих нет и денег. Всего-то. Мир то все тот же.
Тебе знакома концепция уровней? Как думаешь, насколько просто устроена дверь? На уровне пользователя -- очень просто. Есть доска, есть дверная ручка, всё. Продвинутые версии еще имеют глазок. Всё. Абзац. Точка. Аллес. Это полное описание двери на уровне пользователя.А на уровне квантовых флуктуаций дверь устроена настолько сложно, что для ее полного описания потребуется написать больше книг, чем все книги, написанные человечеством, вместе взятые. Квазары, электроны, гравитационное взаимодействие, теория всего.
Гит устроен точно так же. На уровне пользователя -- чрезвычайно просто. А на уровне разработчиков, которые уже лезут в дебри гита для написания гитлаба/гитхаба/хуков/просмотрщиков-в-ide, гит уже устроен посложнее, чтобы дать им все необходимые точки расширений.
На уровне движения электронов в процессоре пасьянс тоже сложно устроен. Но туда почему-то никто не лезет.
Потому что у Пасьянса нет такой сложной структуры в которую можно было бы полезть. Это игра с правилами, за пределами которых нечего не работает.
Гит же дает базовый уровень и много дополнительных доп уровней.
Ты можешь остаться на базовом уровне, а можешь изучить доп уровни.
Нука расскажи нам подробнее об этих, кхе, квантувых флуктуацый!
Да фиг с ними, м квантовыми флуктуациями. Я бы с бОльшим интересом послушал про квазары в дверях.
В колхозном клубе - лекция о полетах в космос. Закончив, лектор предлагает задавать вопросы.
Поднимается колхозный сторож:
- А Вы, товарищ лектор, "подушечку" ели? Вокруг она конфета, а внутри у ей - варенье. Так вот как енто вареньице в тую "подушечку" начиняють?
> - А Вы, товарищ лектор, "подушечку" ели? Вокруг она конфета, а внутри
> у ей - варенье. Так вот как енто вареньице в тую "подушечку" начиняють?Спасибо за отличный вопрос! Вареня в подушку заливается как мясо в пельмень.
Но, представим на мгновенье, что у нас есть квантовая телепортация через море Дирака!
Смогли бы мы переместить варенье в конфету? Да!
Могли бы мы отправить звездолет к альфацентавре? Тоже да!
Предоставьте мир в котором наши внуки летят к далеким звездами и кушают конфеты с вареньем!
> - А Вы, товарищ лектор, "подушечку" ели? Вокруг она конфета, а внутри
> у ей - варенье. Так вот как енто вареньице в тую "подушечку" начиняють?Используются так называемые "корпусные конфеты".
Вначале с использованием жесткой, полужестой формы или барабанов формуется корпус конфеты.
Далее, в него заливается начинка, которая закрывается слоем шоколада.
Потом конфета извлекается их формы.
> А на уровне разработчиков, которые уже лезут в дебри гита ... гит уже устроен посложнееНо тоже всё ещё просто. Автор текста выше просто обывала, триггерящийся на трём по реперным словам
> Тебе знакома концепция уровней? Как думаешь, насколько просто устроена дверь? На уровне
> пользователя -- очень просто. Есть доска, есть дверная ручка, всё. Продвинутые
> версии еще имеют глазок. Всё. Абзац. Точка. Аллес. Это полное описание
> двери на уровне пользователя.Более того. Даже на уровне плотника это как минимум эн разных деревяшек, с разными функциями, всякие там петли, ручки, какой-то крепеж чтобы это все держалось вместе....
...а выпусти вас в поле, без инструментов, где только деревья растут - вы смогете даже простую дверь воспроизвести за обозримое время? Или просто оно - если на плечи гигантов встать? А своим ходом - не такой уж оно и простой предмет, если с точки зрения "разработчика".
Что хорохо в пше, так это то что его можно изучить ровно на столько на сколько необходимо. Если работаешь только с локальным репозирторием и без веток -- достаточно достаточно знать как создавать у далять коммиты. Захотел сделать пше-сервер -- достаточно поставить на север ssh и сам пше, которые скорее всего там и так есть. Не надо ставить, запускать и настраиват какой-нибудь пше-server.service. Никогда не использовал submodules, но надо собрать программу, исполюзующую их? "git submodule update --init" и вперед. Работаешь с репозиторием, в котором используется bitmapPseudoMerge(что бы это не значило) или цифровые подписи? Пускай используется, тебя это ни как не трогает. И в отличии от других комбайнов, с добавлением новых функций производительность не деградирует, а основные функции остаются такими же простыми.
Что в нем просто замечательно - так это то, что сейчас его фактически можно и не учить. Вот тебе веб-интерфейс гитхаба, вот плагин для IDE - а то, что под капотом там хтонический ужас и водяцца драконы - большинству пользователей уже примерно пофиг.
И это говорит о зрелости технологии.
Примерно так же автомобили - какая разница для конечного пользователя какое там покрытие и хонгирование в цилиндрах, их размеры или вообще их кол-во.
Ему достаточно знать как часто менять масло и быть уверенным что 100-150к движок пройдет без проблем.
Это посто говорит о том, что к технологии сделали морду для глупых, и ни о чём больше. Глупым тоже хочется работать и получать деньги просто так
> Это посто говорит о том, что к технологии сделали морду для глупых, и ни о чём больше.Ну конечно умный будет прдолить 10 команд в консольке, а не один клик мышкой.
Он же умный!> Глупым тоже хочется работать и получать деньги просто так
Никто не получает деньги "просто так", их получают за выполненную работу.
Не думаю, что ты отличишь пушнутую ветку которую отправили из консоли, UI приложения или вообще веба.
А потом эти наниматели мышкой плачутся что потеряли весь только что написанный код https://github.com/microsoft/vscode/issues/196223 и таких случаев полно.
> А потом эти наниматели мышкой плачутся что потеряли весь только что написанный
> код https://github.com/microsoft/vscode/issues/196223 и таких случаев полно.И виноваты в этом не "ниасиляторы" 100500 нескучных команд с миллионом "очевидных" (если ты финн-под-веществами) флагов, а... не, они и виноваты, расходимся.
Ну да, ПО дегенерату прямым и простым текстом написало, что всё похерит, а виноваты флаги, которых дегенерат даже не видел т.к. работает через морду и не читает никакой документации.
> Ну да, ПО дегенерату прямым и простым текстом написало, что всё похерит,
> а виноваты флаги, которых дегенерат даже не видел т.к. работает через
> морду и не читает никакой документации.Конечно, если бы он скопипастил заклинание со stackoverflow - все было бы иначе, ведь так? Так?!
> Конечно, если бы он скопипастил заклинание со stackoverflow - все было бы
> иначе, ведь так? Так?!Уважаемый User, вы не понимаете. Отсутствие таких как вы в нормальных рабочих процессах, использующих git - это вообще фича. Это такой критерий обнаруживающий необучаемых экспонатов не умеющих в современные workflow.
Многим современным айтищникам нафиг не упал хозяин с диктатурой. А возможность попрогать вон там под пальмами, или где там, без упования на благодетелей и их доступность здесь и сейчас - вполне.
>> Конечно, если бы он скопипастил заклинание со stackoverflow - все было бы
>> иначе, ведь так? Так?!
> Уважаемый User, вы не понимаете. Отсутствие таких как вы в нормальных рабочих
> процессах, использующих git - это вообще фича. Это такой критерий обнаруживающий
> необучаемых экспонатов не умеющих в современные workflow.
> Многим современным айтищникам нафиг не упал хозяин с диктатурой. А возможность попрогать
> вон там под пальмами, или где там, без упования на благодетелей
> и их доступность здесь и сейчас - вполне."Великие умы обсуждают идеи. Средние умы обсуждают события. Мелкие умы обсуждают людей."
А мелкие и при этом скажем так - не очень умные еще и пытаются делать это вне контекста диалога.
> "Великие умы обсуждают идеи. Средние умы обсуждают события. Мелкие умы обсуждают людей."
> А мелкие и при этом скажем так - не очень умные еще
> и пытаются делать это вне контекста диалога.И хотя вы правы, я никак не припоминаю чтобы вы рвались обсуждать какие-то крутые идеи вокруг опенсорса. Не, обсирание опенсорса направо-налево за это не считается. Из чего я сделал вывод что обсуждать сие лучше с другми людьми.
А так у меня довольно много проектов in flight - и некоторые идеи я вполне себе обсуждаю. Но, конечно, не тут и не с вами. И я занимаюсь проектами только если оно мне самому нравится и интересно. Унылый булшит, типовая продукция проплаченых мясников и проч - ну вот не мое.
В данном же случае - это обсуджение рабочих процессов и workflow. Я обнаружил для себя что с теми кому git нравится лично мне работать, так, по жизни - зело приятнее и эффективнее. И вон то лишь отражение этого опыта.
> И хотя вы правы, я никак не припоминаю чтобы вы рвались обсуждатьИииии - снова бла-бла-бла с обсуждением себя-любимого и меня-нелюбимого.
> В данном же случае - это обсуджение рабочих процессов и workflow. Я
Иииии - если вы посмотрите, то в исходном диалоге эти самые "рабочие процессы и workflow" не обсуждались. Вы просто пришли в произвольное место, сказали, что вы д'Артаньян а абизян удобней сидеть под пальмой и грызть банан. При формальной корректности второй части (Первая бла-бла-бла - поскипано) - не понятно, зачем оно _здесь_?
> Иииии - снова бла-бла-бла с обсуждением себя-любимого и меня-нелюбимого.Идеи и архитектуру пары фич я до этого обсудил - с другими людьми :P.
> сказали, что вы д'Артаньян а абизян удобней сидеть под пальмой и
> грызть банан. При формальной корректности второй части (Первая бла-бла-бла - поскипано)
> - не понятно, зачем оно _здесь_?Я намекнул вам что от вашего отсутствия среди пользователей GIT мало кто и что потеряет, имхо. На мой вкус гит отлично палит необучашек с SVN головного мозга.
...и если кого интересовали современные воркфлоу и IT чтобы сделать свою жизнь лучше, свободнее, и прикольнее - а не чтобы вписаться в рабство, git это то что доктор прописал. Это вообще разные сообщества, и в вон том вас и правда считают за что-то такое.
>> Иииии - снова бла-бла-бла с обсуждением себя-любимого и меня-нелюбимого.
> Идеи и архитектуру пары фич я до этого обсудил - с другими
> людьми :P.
> Я намекнул вам что от вашего отсутствия среди пользователей GIT мало кто"Я", "меня", "я"... может вам на какие-нибудь знакомства мейл.ру надо?
> ...и если кого интересовали современные воркфлоу и IT чтобы сделать свою жизнь
А что именно обсуждалось в исходном треде - вы таки не посмотрели. Зачем? Есть же тату на седалище - btw, i use git! и можно его везде показывать!
И вот все у вас так - понять, о чем люди разговаривают мы даже не пытаемся - вместо этого несем свое очень ценное (нет) мнение известному вопросу.
>> Я намекнул вам что от вашего отсутствия среди пользователей GIT мало кто
> "Я", "меня", "я"... может вам на какие-нибудь знакомства мейл.ру надо?Ктулху меня упаси от ваших мылрушечек и прочих помоек для дедушек и бабушек советского образца.
> Зачем? Есть же тату на седалище - btw, i use git!
> и можно его везде показывать!Комиты лучше работают чем тату. Продвигать свою линию делом - результативнее.
> И вот все у вас так - понять, о чем люди разговаривают
> мы даже не пытаемся - вместо этого несем свое очень ценное
> (нет) мнение известному вопросу.Разговаривать в топике про сабж имеет смысл про сабж. Если это не так - по идее вы клиент модераторов вообще, как по мне.
>> И вот все у вас так - понять, о чем люди разговаривают
>> мы даже не пытаемся - вместо этого несем свое очень ценное
>> (нет) мнение известному вопросу.
> Разговаривать в топике про сабж имеет смысл про сабж. Если это не
> так - по идее вы клиент модераторов вообще, как по мне.ну так у каждого предмета есть более одного аспекта и приходить в обсуждения качества инструмента с рассказом как хорошо с этим инструментом сидится под пальмой с бананом - несколько странно - вам не кажется?
Впрочем, уверен - не кажется. Пальма-и-банан - это ВАЖНО.
> А на уровне разработчиков, которые уже лезут в дебри гита для написания гитлаба/гитхаба/хуков/просмотрщиков-в-ide, гит уже устроен посложнее,Да это легко. У таких деяетелей работа обычно оформлена как у последних удаков. Нормальное пользование инструментами, конечно, автоматически не творит чудес, но даёт возможность работать прилично. А через морды это в принципе невозможно. Как следствие, выбор между мордой и CLI хорошо показывает наличие опыта и отношение человека к работе. Т.е выбирает морду ~> результата лучше гогнокода ожидать не стоит.
> И это говорит о зрелости технологии.
> Примерно так же автомобили - какая разница для конечного пользователя какое там
> покрытие и хонгирование в цилиндрах, их размеры или вообще их кол-во.
> Ему достаточно знать как часто менять масло и быть уверенным что 100-150к
> движок пройдет без проблем.Не совсем удачный пример как по мне. Собственно "удачного" за рамками IT\телекома (ооо!) я так навскидку и не подберу. Тут не "технология достигла определенного уровня зрелости", а "хтонический ужас обмазали абстракциями так, что туда почти уже можно и не смотреть" - "вместо ДВС в автомобили заводные гномики жонглируют шестеренками, но мы приделали к этому одну педальку и закрыли крышкой - нажимаешь и едешь"
Маленькие китайцы уже давно заполонили рынок.
> Маленькие китайцы уже давно заполонили рынок.Эммм... вы намекаете, что под капотом "большого китайца" "маленькие китайцы" быстро-быстро крутят педали? Нууууээээоооук.
always has been
Кто то ещё до сих пор считает, что Git - это юниксвей?
> Кто то ещё до сих пор считает, что Git - это юниксвей?А кого сейчас вообще волнует юниксвей?
Он же про то, чтобы сайт ты "скачал" одной консольной утилитой, текст отобразил в другой, картинку отобразил третей.
Такие горы велосипедов мало кому сейчас нужны.
А что нужно - решение которое из коробки решает 80-90% задач, и желательно имеет расширение возможностей.
> Он же про то, чтобы сайт ты "скачал" одной консольной утилитой...Так git именно так и работает. А вы об этом не знаете ... Ну даже не знаю почему. Интернеты последенее времия наводнило невероятное кол-во ничего не знающих, ничем не интересующихся и не читающих людей. Видимо, то самое поколение 90-х выходит работать.
Да, git это классический юниксвей
А по git svn не скажешь.
> А по git svn не скажешь.Внезапно это вообще отдельная приблуда.
$ git svn
git: 'svn' is not a git command. See 'git --help'
Ну вот как-то так. Да, я не пользуюсь софтом с репами в svn. Вообще совсем. Если кто заплесневел вот настолько - это ниже моих кодерских предпочтений.
Правильно, не надо поддерживать отбитых фанатиков юникса, которым только и делают что парсят текстовые файлы на баше.
> Это уже напоминает комбайн, а не просто систему для управления исходными текстами...Это ты еще штуки типа fossil не видел, где еще встроеная вика и что там еще, багтрек, чтоли... видимо для иллюстрации как сделать хреновый vcs, вику и багтрек все в 1.
Кстати, НЕ хреновый в своих границах применимости, если что.
На современную модель разработки не натягивается, на большие проекты не скейлится - но в нише "для себя и кота" - самоЕ оно, как по мне.
Для себя и кота это как раз Git, он то именно из таких соображений и создавался
> Для себя и кота это как раз Git, он то именно из
> таких соображений и создавалсяНет. Fossil - плюс-минус готовое решение по сопровождению процесса разработки небольшого проекта - с веб мордой, вики, багтрекером, читай SCM-система, а git... ну, вот vcs.
Как раз fossil.
Во-первых, ему начинать, где лежать. Реаозиторий - это просто один файлик. Хоть на каком-нибудь гугл облаке.
Во-вторых, та же вики и баг-треккер. У меня для разных проектов в стол стояла проблема поиска таск-треккера. Многие советовали всякие онлайн варианты, типа trello. Но, как показывает нынешнее время, хранить что-то исключительно у левого дядюшки идея плохая
> Кстати, НЕ хреновый в своих границах применимости, если что.Ну да, сделать VCS, вику и багтрек которыми пользуетесь только вы - сойдет. Для всего остального - deadborn, абсолютный.
> На современную модель разработки не натягивается, на большие проекты не скейлится -
> но в нише "для себя и кота" - самоЕ оно, как по мне.Это очень большое самоограничение. Впрочем я совсем не возражаю чтобы вы его к себе применяли. Это видимо типа Darwin Awards но для программистов получается. Самоустранение из общедоступности, дабы не засорять планету своим кодом? Это по своему гениально.
>> Кстати, НЕ хреновый в своих границах применимости, если что.
> Ну да, сделать VCS, вику и багтрек которыми пользуетесь только вы -
> сойдет. Для всего остального - deadborn, абсолютный.Ну, на проект уровня sqlite хватает, да?
> Это очень большое самоограничение. Впрочем я совсем не возражаю чтобы вы его
> к себе применяли. Это видимо типа Darwin Awards но для программистов
> получается. Самоустранение из общедоступности, дабы не засорять планету своим кодом? Это
> по своему гениально.Ну, да - очень большое ограничение. 99,95% проектов гитхаба в условную "зону эффективности" fossil в общем-то влазит, а вот остальные 0,05% - бИда.
fossil проиграл не git'у (Тот вообще на соревнования не явился), а github'у\gitlab'у\teamcity\etc. Причем проиграл не на поле условного SCM (Там тоже все не идеально - например, хрен ты вменяемым образом CI\CD на fossil скрафтишь, да и in general "базар" выиграл у "собора"), а на поле та-дааам! Соцсеточки-для-разработчиков. Вот тут да, просто без вариантов разгром.
P.S. Самое забавное, что если сравнивать не с крупными коммерческими сервисами, а с Ъ-селфхостед-опенсорсом тоээээ... gitea не то, чтобы далеко убежала, скажем так.
>> сойдет. Для всего остального - deadborn, абсолютный.
> Ну, на проект уровня sqlite хватает, да?А некоторые вообще - тарболы релизят. SQLite точно не самый большой или активный проект на этом глобусе. Он по задумке - мелкая необслуживаемая база вообще.
> Ну, да - очень большое ограничение. 99,95% проектов гитхаба в условную "зону
> эффективности" fossil в общем-то влазит, а вот остальные 0,05% - бИда.Странно что они своего счастья не понимаю :)
> fossil проиграл не git'у (Тот вообще на соревнования не явился),
> а github'у\gitlab'у\teamcity\etc.Очень странно, при наличии вики и багтрекера то :). А может таки - именно гиту, ибо ьез compat с ним - оно уже никому нахрен не вперлось? :)
> Причем проиграл не на поле условного SCM (Там тоже все не
> идеально - например, хрен ты вменяемым образом CI\CD на fossil скрафтишь,И это тоже как бы - не фича. А якорь на тему воркфлоу опять же.
> да и in general "базар" выиграл у "собора"), а на поле
> та-дааам! Соцсеточки-для-разработчиков.Я вообще гитхабом не пользуюсь. А вот гит ... ну вот вчера я вкатил 10 комитов в несколько проектов. DVCS штука такая. Я умею в "D" и просто VCS мне уже и не надо как-то :)
> Вот тут да, просто без вариантов разгром.
Вот лично меня это вообще никак не затрагивает.
> P.S. Самое забавное, что если сравнивать не с крупными коммерческими сервисами, а
> с Ъ-селфхостед-опенсорсом тоээээ... gitea не то, чтобы далеко убежала, скажем так.Gitea - отдельная приблуда. Для тех кому оно надо. Если вообще надо. Так логичнее как-то. А пихать это вообще всем в обязалову - странная идея.
> А некоторые вообще - тарболы релизят. SQLite точно не самый большой или
> активный проект на этом глобусе. Он по задумке - мелкая необслуживаемая
> база вообще.Ну да - подумаешь, самая распространенная БД в мире с числом установок поболе, чем у linux kernel'u - экая ярунда. "Необслуживаемая" же. Так-то да, проект сильно не самый активный - порог входа высоковат, абизянцам не антирэсно.
> Странно что они своего счастья не понимаю :)
Ничего странного. Соцсеточка выиграла - технические аспекты разработки тут очень условно "при чем".
> Очень странно, при наличии вики и багтрекера то :). А может таки
> - именно гиту, ибо ьез compat с ним - оно уже
> никому нахрен не вперлось? :)Нет. git per se нужен примерно "никому". Ведущих какие-либо проекты на голом git'е энтузиастов я просто не знаю - у всех вот эта самая обвязка вокруг разной степени интегрированности в процесс сама собой возникает.
> И это тоже как бы - не фича. А якорь на тему
> воркфлоу опять же.Ну да. Я вам об этом прямым текстом и говорю - на современный процесс разработки fossil ложится не идеально.
> Я вообще гитхабом не пользуюсь. А вот гит ... ну вот вчера
> я вкатил 10 комитов в несколько проектов. DVCS штука такая. Я
> умею в "D" и просто VCS мне уже и не надо
> как-то :)"Я", "меня", "я" - еще линейку вот сфоткайте, блин - раз уж тату "btw-i-use-git" вывалили. Полтора упоротых вот ВОООБЩЕ НИКОМУ НЕ ИНТЕРЕСНЫ. Индустрия работает вот так, как она работает - с de facto централизованными репозиториями, единой точкой ответственности и вот этим вот всем. А то, что полтора анонима по почте друг другу дикпики, пардон, коммиты шлют... да оссспыдя. Пусть шлют - наиграются, работать пойдут. Ну или продолжат ворота поллировать, их дело.
> Вот лично меня это вообще никак не затрагивает.
И меня нет - но какое это имеет отношение к вопросу?
> Gitea - отдельная приблуда. Для тех кому оно надо. Если вообще надо.
> Так логичнее как-то. А пихать это вообще всем в обязалову -
> странная идея.Ну, пока чем-нибудь полезным не займешься - да, странная. А как только попробуешь мигрировать нет, не "код" - кому он по большому счету нужен за пределами maintenance window-то? А собственно процесс разработки - те самые CR, issues, таски с привязкой к постановкам и т.д. - враз поймешь, что иметь все это в одном, блин, инструменте а не в четырех разных - таки великое благо.
> Ну да - подумаешь, самая распространенная БД в мире с числом установок
> поболе, чем у linux kernel'u - экая ярунда.И чего? Это встриваемая необслуживаемая БД. Ничего не говорит о ее крутизне для разработки чего либо.
> "Необслуживаемая" же. Так-то да, проект сильно не самый активный - порог
> входа высоковат, абизянцам не антирэсно.И по задумке - мелкая маложручая хрень. При сильном желании такое даже в версионировании зип архивами катит. А мы вроде круть VCS иллюстрировать собирались...
> Ничего странного. Соцсеточка выиграла - технические аспекты разработки тут очень условно
> "при чем".Выиграл - прагматик Линус. Сделавший то что нормальные современные прогеры хотели, нашару, для всех. Гитхаб уже потом подтянулся на шумок. И были конкуренты типа bitbucket, bazaar и прочей кривой хни. Но хня была столь кривой, тормозной и мучительной что таки - пролетела.
> Нет. git per se нужен примерно "никому".
Это не соответствует действительности. Я имею отношение к пачке проектов - но никаких гитхабов в наших рабочих процессах не фигурирует. Совсем.
> git'е энтузиастов я просто не знаю - у всех вот эта
Я бы удивился если бы знали. С вашим менталитетом у вас круг общения - "покусанные энтерпрайзом". Проприетарщики. Они вообще в гите как правило - инвалиды.
> самая обвязка вокруг разной степени интегрированности в процесс сама собой возникает.
Обвязка в разных проектах бывает разная, от никакой до дофига. И все чаще - специфична для проекта, а не упование на мегаблагодетелями заколебавшими всех уже своими "вы сменили браузер!", "а ну гони номер телефона!", "рюхни-ка капчу", 2FA в каждые дюзы, и какие там еще односторонние изменения и "улучшения" когда с энного момента вкладка с гитхабом дико жрет проц за сам факт открытия гитхаба просто. На гитхабе не осталось проектов в которые я комитил.
> Ну да. Я вам об этом прямым текстом и говорю - на
> современный процесс разработки fossil ложится не идеально.Ну как бы сабж юниксвеен и может стать частью иных процессов если так задумано. А суперкомбо все в одном - спасибо, конечно, но - нафига?
> "Я", "меня", "я" - еще линейку вот сфоткайте, блин -
Как говорится, покупайте наши линейки - и вы всегда будете довольны результатом!
> работает вот так, как она работает - с de facto централизованными
> репозиториями, единой точкой ответственности и вот этим вот всем.Это у всяих, типа вас. И так вам и надо. Ибо каждый человек сам 314ц своего счастья. Если вы хотите узнать это сложным способом - ваше право, я не против :)
> да оссспыдя. Пусть шлют - наиграются, работать пойдут. Ну или продолжат
> ворота поллировать, их дело.Да я смотрю вы там такие работнички, все софтом завалили просто. Но почему-то 90% софта делается в США и гит очень популярен. Даже в корпах.
> Ну, пока чем-нибудь полезным не займешься - да, странная. А как только
> попробуешь мигрировать нет,Простите за нескромный вопрос, а у вас ВАШИ проекты вообще - есть? Не, не надо прикрываться всякими корпами, васянами, и проч примазываясь к их заслугам. Скажите за лично себя. И тогда будет понятнее - есть ли смысл с вами дискутировать дальше на эту тему.
> нужен за пределами maintenance window-то? А собственно процесс разработки - те
> самые CR, issues, таски с привязкой к постановкам и т.д. -
> враз поймешь, что иметь все это в одном, блин, инструменте а
> не в четырех разных - таки великое благо.Ага, блин, вместо "does 1 thing and does it well" - будет "jack of all trades: starts 200 trades, finishes none!". Те кто топил за fossil хорошо вписывались в такое описание.
> И чего? Это встриваемая необслуживаемая БД. Ничего не говорит о ее крутизне
> для разработки чего либо.
> И по задумке - мелкая маложручая хрень. При сильном желании такое даже
> в версионировании зип архивами катит. А мы вроде круть VCS иллюстрировать
> собирались...Ну, вы походите по базару - поищите где дешевле. Шо, нету?! Ой, бида-то какая...
В результате для проекта, более важного для open\closed source'а чем 99% содержимого github'а возможностей fossil - внезапно - хватает. Но для хелловрота Васи кнешн нет, у него требования посерьёзней - анимированные эмодзи, вот это всё...> Выиграл - прагматик Линус. Сделавший то что нормальные современные прогеры хотели, нашару,
> для всех.Те прогеры хотели вот bitkeeper - но ой.
> Гитхаб уже потом подтянулся на шумок. И были конкуренты
> типа bitbucket, bazaar и прочей кривой хни. Но хня была столь
> кривой, тормозной и мучительной что таки - пролетела.Да-да. Именно по этому тот workflow с обвязкой, который применяется в разработке ядра не используется вот практически нигде больше - других желающих кидаться патчами по почте "шоб в экран лезло" чот не нашлось.
> Это не соответствует действительности. Я имею отношение к пачке проектов - но
> никаких гитхабов в наших рабочих процессах не фигурирует. Совсем.
> Обвязка в разных проектах бывает разная, от никакой до дофига.Да-да. И вы сейчас разумеется покажете успешные opensource проекты, которые развиваются без документации, wiki, task\issue-трекеров - вот только и исключительно в git'e, без этих вот богопротивных веб-морд, ведь да? Да?
Нет, "laba1" и "hello, world!" Не предлагать.> И все чаще - специфична для проекта
Бла-бла-бла-бла. В результате примерно 99% проектов оказываются в github\gitlab\gitea\bitbucket да еще и с какими-нибудь jira\confluence\redmine в довесок. Экая, право, оказiя...
> Ну как бы сабж юниксвеен и может стать частью иных процессов если
> так задумано. А суперкомбо все в одном - спасибо, конечно, но
> - нафига?Не, про религию я не разговариваю - эт бесполезно.
> Это у всяих, типа вас. И так вам и надо. Ибо каждый
> человек сам 314ц своего счастья. Если вы хотите узнать это сложным
> способом - ваше право, я не против :)Ну, жду примера альтернатив от всяких типа вас, ага.
> Да я смотрю вы там такие работнички, все софтом завалили просто. Но
> почему-то 90% софта делается в США и гит очень популярен. Даже
> в корпах.Воу. Вот это аргумент, так аргумент - особенно от автора-софта-из-сша, агась? ъ-форчун500-ынтырпрайз-ар-н-ди-админ-из-лос-анжелеса-калифорния, прямое включение!
> Простите за нескромный вопрос, а у вас ВАШИ проекты вообще - есть?
Ээээ... предлагаете хелловротами мериться? А зачем?
> Ага, блин, вместо "does 1 thing and does it well" - будет
> "jack of all trades: starts 200 trades, finishes none!". Те кто
> топил за fossil хорошо вписывались в такое описание.В результате имеем вот два варианта - тот же условный "fossil" - только чужой (А-аааблака! Белогривые лоша-аадки!) и хуже, либо "ачосразуято?! Пусть кто-нибудьдругойсделает из чего-нибудь другого! А пока ну вот вам мыло отсосдателя, по всем проблемам пишите тудой"
Я тоже люблю fossil. Заочно и по-маниловски.Багтрекер выглядит так https://www.sqlite.org/src/rptview/1, поиск где-то отдельно, фильтров нет, пулл-реквестов нет, интеграции багтрекера (экспорта/импорта/синхронизации) с Github/Gitlab нет, хостить самостоятельно, но идея хорошая, красивая (и встроенный скин Xekri - тоже).
Какой-то git-bug https://github.com/MichaelMure/git-bug говорит, что если что, с ним получится перевести багтрекер с Github на Gitlab. Идея уже не такая красивая (даже в теории не прийти к тому, чтобы багтрекер был забэкаплен у всех проектов, как если бы взлетел fossil), и реализация не такая стандартная, но жизнеспособнее в современных реалиях, наверное.
> Я тоже люблю fossil. Заочно и по-маниловски.не-не-не. Я его НЕ люблю - два раза делал подход к снаряду, в 2011 и в 2019 - и оба раза "спасибо, нет".
> Багтрекер выглядит так https://www.sqlite.org/src/rptview/1, поиск где-то отдельно,
> фильтров нет, пулл-реквестов нет, интеграции багтрекера (экспорта/импорта/синхронизации)
> с Github/Gitlab нет, хостить самостоятельно, но идея хорошая, красивая (и встроенный
> скин Xekri - тоже).Ну вот opensource без корпоративной поддержки (и\или надежды на эту поддержку) он такой. Делался для себя, под потребности вполне конкретного opensource'ия - на все остальное ложится весьма условно - но идея, лежащая в основе кмк - хорошая и правильная. После нескольких проектов с "передачей исходных кодов заказчику" или вот текущего разбирательства с проЭктом на 50 реп с докой от 2019 года ценность исходного кода per se я оцениваю не то, чтобы "высоко" - даже без учета, скажем так, "неперсистентности" истории в git'е - что-либо мало-мальски сложное без сопроводиловки и\или команды, которая это "сложное" делало - можно только выкрасить-и-выбросить.
> Какой-то git-bug https://github.com/MichaelMure/git-bug говорит, что если что, с ним
> получится перевести багтрекер с Github на Gitlab. Идея уже не такая
> красивая (даже в теории не прийти к тому, чтобы багтрекер был
> забэкаплен у всех проектов, как если бы взлетел fossil), и реализация
> не такая стандартная, но жизнеспособнее в современных реалиях, наверное.Ну, меня таскалка-трекилка в связке с wiki в которой постановки на реализацию даже больше интересуют.
Пока что единственная нормальная система контроля версий.
Какие аноним проверял?
Mercurial тоже нормальная, даже в чем-то интереснее. Но на неё забили и перестали развивать.
Facebook?
Хуже меркуриала трудно придумать. Только если биткипер.
Ну, формально говоря, обновления Ртути регулярно выходят. А с сабжем происходит не развитие, а "дуракавалянье", как говорил товарищ Шариков.
> Ну, формально говоря, обновления Ртути регулярно выходят. А с сабжем происходит
> не развитие, а "дуракавалянье", как говорил товарищ Шариков.Нюанс в том что весь остальной глобус решил что дураковаляние происходит - вон там, а релиз новых версий вон тут :). Но вы там можете в HG перекидываться комитами, как будто кто-то против. Как раз заодно добровольно отселитесь в гетто.
"За весь глобус", если что - я бы не стал. Не удивлюсь, если чисто количественно всякие перфорсы-биткиперы-свны-цвсы(не к ночи будь помянуты) всё ещё вперде.
> "За весь глобус", если что - я бы не стал.Ну как бы хостинги открытых проектов - этот HG вообще задропали многие уже. Из тех кто это недоразумение умел. Как еще понятнее донести на этом глобусе разработчикам DVCS что у них дуракаваляние получилось - я даже и не знаю. Это уже 10 из 10.
> Не удивлюсь, если чисто количественно всякие перфорсы-биткиперы-свны-цвсы
> (не к ночи будь помянуты) всё ещё вперде.Это барахло никто не видит и де факто это всякое отработаное легаси не имеющее будущего, у всякой замшелой копроратии. Ах, черт, опечатка даже - по Фрейду.
> Это барахло никто не видит и де факто это всякое отработаное легаси не имеющее будущего, у всякой замшелой копроратии.Это практически все топовые айти корпорации, если что. Git просто не тянет их объёмы репозиториев и кол-во коммитов в день. У них, конечно, не прямо вот это всё, свои разработки сильно на них похожие
>> Это барахло никто не видит и де факто это всякое отработаное легаси
>> не имеющее будущего, у всякой замшелой копроратии.
> Это практически все топовые айти корпорации, если что.Мда? А штуки размером с гугл, фэйсбук и проч - погулять вышли?
> Git просто не тянет их объёмы репозиториев и кол-во коммитов в день.
Он тянет - штуку размером с Linux Kernel. И не надо мне про объемы рассказывать. Видел я такую штуку в паре корп как M$ TFS. Господи, какое же убожище вечно клинящее рабочий процесс. И да, с него на гит таки - перешли. Потому что это - проприетарный гуана кусок. Дорогой и бестолковый.
> У них, конечно, не прямо вот это всё, свои разработки сильно на них похожие
Чтобы вещать за эти корпы - неплохо бы там поработать, для начала. При том не в своем сельпо уровня росгос а - именно нормальной транснациональной корпорации. Там гита сейчас - немеряно просто, и умеют его даже уже, вот, всяикие техписы и не сильно технические манагеры, и чуть ли не HR уже. Пришлось. А умение git - один из ключевых скиллов на собеседования, без этого уже в чуть ли не большей части вакансий вообще за человека в IT - не считается.
> Ну как бы хостинги открытых проектов - этот HG вообще задропали многие
> уже. Из тех кто это недоразумение умел. Как еще понятнее донести
> на этом глобусе разработчикам DVCS что у них дуракаваляние получилось -
> я даже и не знаю. Это уже 10 из 10.Так тех "открытых проектов", предполагаю, даже не "кратно" а "порядково" (в LOC) меньше, чем closed-source проприетари. Сделай далеко идущие выводы о количестве кода на какой-нибудь 1C по гитхабу, ага.
>> Не удивлюсь, если чисто количественно всякие перфорсы-биткиперы-свны-цвсы
>> (не к ночи будь помянуты) всё ещё вперде.
> Это барахло никто не видит и де факто это всякое отработаное легаси
> не имеющее будущего, у всякой замшелой копроратии. Ах, черт, опечатка даже
> - по Фрейду.Да-да-да - вот только это "legacy" ну и не "это" и не "legacy" тоже - с нами примерно на "вечно".
> Так тех "открытых проектов", предполагаю, даже не "кратно" а "порядково" (в LOC)
> меньше, чем closed-source проприетари.Угу, вот прям у каждого первого - штуки с Linux Kernel размером. Откуда бы, интересно? И что сие за проекты такие, которые никто не видит и не слышит?
> Сделай далеко идущие выводы о количестве кода на какой-нибудь 1C по гитхабу, ага.
Господи, 1C - вообще 1 единственная хрень от 1 единственной фирмы. А если на гитхаб зайти и вбить поиск по любому топику - можно получить очень интересный экспериенс на тему сколько LoC туда насыпали по разным поводам. От FAANG с сотнями реп до васяна с домашкой. Вот ща 1С FAANG-а по LoC сделает. Да, и эти LoC не сферическая теория в вакууме - а вон клацнул профайл и обозревай все 30+ страниц проектов какого-нибудь гугля. И думай сколько там LoC суммарно, и где 1С по сравнению с этим всем, ога.
1 только андроид - десятикратно покроет это недоразумение. Да, опенсорс и в гите. Видимо тоже недостаточно масштабно? Всего пара миллиардов юзерей - не того? :)
> Да-да-да - вот только это "legacy" ну и не "это" и не
> "legacy" тоже - с нами примерно на "вечно".Ну так где-то и паровозы можно найти до сих пор. Но вот машинист паровоза - и прочие кочегары и что там еще - весьма нишевая штука на данный момент. И те кто git не умеет - стремительно следуют в этом же направлении. Просто глядя на требования к кандидатам на айтищные вакансии.
> Угу, вот прям у каждого первого - штуки с Linux Kernel размером.
> Откуда бы, интересно? И что сие за проекты такие, которые никто
> не видит и не слышит?Да ёлки. Сколько там в кернеле? 30млн LOC? По гребучему COBOL'у (COBOL'у, Карл!!!) оценка 250млн LOC. In use, а не total.
> Господи, 1C - вообще 1 единственная хрень от 1 единственной фирмы. А
> если на гитхаб зайти и вбить поиск по любому топику -
> можно получить очень интересный экспериенс на тему сколько LoC туда насыпали
> по разным поводам. От FAANG с сотнями реп до васяна с
> домашкой. Вот ща 1С FAANG-а по LoC сделает. Да, и эти
> LoC не сферическая теория в вакууме - а вон клацнул профайл
> и обозревай все 30+ страниц проектов какого-нибудь гугля. И думай сколько
> там LoC суммарно, и где 1С по сравнению с этим всем,
> ога.Весь FAANG - нет, не сделает. Linux kernel, предполагаю с хааарошим запасом. Да, один продукт, одной фирмы в одной не богатой стране - порядково.
А у FAANG'а свой ABAP в наличии - и его на github'е что характерно, тоже не богато. Не популярная, видать, штука - никто не пользуется.> 1 только андроид - десятикратно покроет это недоразумение. Да, опенсорс и в
> гите. Видимо тоже недостаточно масштабно? Всего пара миллиардов юзерей - не
> того? :)Эт вряд ли. 9-10к фуллтайм вакансий в месяц в РФ, количественную оценку работающих не дам, но сильно удивлюсь, если у жужля на фуллтайм больше народу андроид пилит.
> Ну так где-то и паровозы можно найти до сих пор. Но вот
> машинист паровоза - и прочие кочегары и что там еще -
> весьма нишевая штука на данный момент. И те кто git не
> умеет - стремительно следуют в этом же направлении. Просто глядя на
> требования к кандидатам на айтищные вакансии.Ну да - можно конечно отказаться от "немодного колеса" - вот только результат, я думаю, не сильно устроит.
> Да ёлки. Сколько там в кернеле? 30млн LOC? По гребучему COBOL'у (COBOL'у,
> Карл!!!) оценка 250млн LOC. In use, а не total.Тем не менее, я думаю даже кернел сильно превышает типовой проект который местные посетители ворочают. И там еще и число девов так то - весьма нормальное. Уж точно у местных столько не найдется, и комитят они куда как активнее. Так что сказ про активность комитов - прохладный.
> Весь FAANG - нет, не сделает. Linux kernel, предполагаю с хааарошим запасом.
Что-то тут не так в этом спиче. Кто кого не сделает? У FAANG'а в гите дохрена проектов, включая и монстроту типа chromium, android и тому подобного.
И, кстати, если кто загнал дохрена LoC в 1 проект, без деления на субкомпоненты совсем (ну там git module в терминах гита) - возможно, с архитектурой у них как-то не задалось, м? Если кто гадит в таком объеме без деления на субпроекты - очень большой вопрос фича ли это :)
> Да, один продукт, одной фирмы в одной не богатой стране - порядково.
Один продукт одной фирмы не очень богатой страны - вообще крайне нишевой кейс, скажем прямо. Это не делает погоду на глобусе. И уж тем более не тот предмет на который стоит ориентироваться разработчикам в обещм случае.
> что характерно, тоже не богато. Не популярная, видать, штука - никто
> не пользуется.И тем не менее, сорцов в git - включая здоровенные проекты с ломовой активностью - немеряно. А тут какие-то сказки что мол так нельзя. Фи.
> Эт вряд ли. 9-10к фуллтайм вакансий в месяц в РФ, количественную оценку
> работающих не дам, но сильно удивлюсь, если у жужля на фуллтайм
> больше народу андроид пилит.В РФии вообще есть проекты сравнимые с хотя-бы андроидом по активности? Вы точно не переоцениваете себя и родину слонов? А то бывает такая фигня... почему-то на мировой арене РФ вообще по объемам софта где-то в полной з@днице, соревнуясь с всяими зимбабве.
> Ну да - можно конечно отказаться от "немодного колеса" - вот только
> результат, я думаю, не сильно устроит.Вот git как раз и стал столь же распостранен - как современные пневматические колеса. А всякая нишевая хрень... ну... она таки - нишевая хрень.
Ииии - вы опять потеряли логику дискуссии.
Смотрите:
Исходный тезис - "Весь мир перешел на git!"
Мой тезис - "Мягко говоря, не так - на git - перешла МАЛЕНЬКАЯ часть этого мира - opensource-манямирок, возможно - сейчас активно переходит корпоративная разработка, но процесс еще сильно далек от завершения, и чисто количественно большая часть кода обрабатывается somewhere out there"
Ваш тезис в подтверждение исходного - "да один kernel уделывает эту вашу проприетарь! А там еще Х, У, Z есть!"
Мой тезис - "объем кода, написанный под одну единственную весьма нишевую платформу кратно больше этого вашего linux kernel'а - а по миру таких "нишевых и-не-нишевых платформ"...
И тут вы начинаете "они код не правильно хранят, у них этого кода в пересчете на проект меньше, архитектура не та, на глобус не влияет" и вот это вот всё. Может даже и правда - но к исходным тезисам относится вот ровно - "никак".
> Исходный тезис - "Весь мир перешел на git!"
> Мой тезис - "Мягко говоря, не так - на git - перешла
> МАЛЕНЬКАЯ часть этого мира - opensource-манямирок,А мой пойнт: вы продолбали момент и не заметили когда манямирок стал, в общем то теми кто создает будущее и определяет как процессы будут выглядеть завтра. А замшелые корпоративные дино, ессно, следуют - с отставанием N лет. Чем больше корпа - тем медленнее ворочается в среднем. Но сейчас git уже и у них - буквально везде. Как в вашем росгоссельпо я не знаю и мне не интересно, я про IT в среднем, 90% софта создается - вообще в США. И там GIT - везде. Если не верите - поищите жирные корп имена в поиске гитхаба. Увидите.
> возможно - сейчас активно переходит корпоративная разработка,
Уже во многом перешла. А россияне, особенно рос-гос и то что рядом - ессно далеко не светочи прогресса и програмеру равняться на это - смысла вообще нет, ибо участь тех - весьма незавидна.
> Ваш тезис в подтверждение исходного - "да один kernel уделывает эту вашу
> проприетарь! А там еще Х, У, Z есть!"
> Мой тезис - "объем кода, написанный под одну единственную весьма нишевую платформу
> кратно больше этого вашего linux kernel'а - а по миру таких "нишевых и-
> не-нишевых платформ"...А таки на гитхабе можно найти легион жирнокорп с кучей репов. Ну и то что там у кого-то в норке - их внутреннее дело, могут хоть ZIP'ами перекидываться. Остальным этого не видно и этого можно считать что нет. Ибо ни на что в этом мире не влияет. Совсем.
> И тут вы начинаете "они код не правильно хранят, у них этого
> кода в пересчете на проект меньше, архитектура не та, на глобус
> не влияет" и вот это вот всё. Может даже и правда
> - но к исходным тезисам относится вот ровно - "никак".Я таки имею наглость думать что в гите сейчас и больше проектов - и больше объем кода. Достаточно посмотреть на тот же гитхаб. И да, там и очень интересные вещи попадаются. Скажем вколотив RISCV можно конкретно затариться исходниками процов. Даже теми которые реально выпекают вооон те. Мир изменился.
> А мой пойнтИ как он соотносится с исходными тезисами? Примерно никак, да. Даже по статистике гитхаба - на открытые репо приходится 20% коммитов. Реально соотношение oss/proprietary скорее 5 к 95 - это для OSS github безальтернативен (хоть зеркало да будет), а для корпоративки - вариантов овердофигища.
> Уже во многом перешла.
И это возможно тоже правда - в отношении новых/активно развиваемых проектов. Относительно общих объёмов накопленной кодовой базы - нет.
> А таки на гитхабе можно найти легион жирнокорп с кучей репов. Ну
> и то что там у кого-то в норке - их внутреннее
> дело, могут хоть ZIP'ами перекидываться. Остальным этого не видно и этого
> можно считать что нет. Ибо ни на что в этом мире
> не влияет. Совсем.Ну, можно погрузить голову куда солнце не светит и сказать "чего я не вижу - того нет!" - позиция для взрослого человека изрядно странная, но можно. Мы ж тут не про "персонально ваши перспективы" говорим, а про текущее положение дел...
> Я таки имею наглость думать что в гите сейчас и больше проектов
> - и больше объем кодаГде код на 1с и abap? На lisp'е под Autocad, блин (не удивлюсь, если даже он этот самый kernel по loc'ам делает)? Программисты сотнями тысяч есть - а кода на github'е - считай, что нет. Чудеса.
> И как он соотносится с исходными тезисами? Примерно никак, да. Даже по
> статистике гитхаба - на открытые репо приходится 20% коммитов.Ну так это значит что
1) В гите кода больше чем вы там вещали.
2) Поди майкрософт сам же и перешел внутри на гит, а кода у них и правда немеряно.> Реально соотношение oss/proprietary скорее 5 к 95 - это для OSS github безальтернативен
> (хоть зеркало да будет), а для корпоративки - вариантов овердофигища.Ну вы там вещайте, да :). А мы посмотрим чья возьмет.
> И это возможно тоже правда - в отношении новых/активно развиваемых проектов. Относительно
> общих объёмов накопленной кодовой базы - нет.Сам же себе и противоречит - тезису про комиты выше.
> странная, но можно. Мы ж тут не про "персонально ваши перспективы"
> говорим, а про текущее положение дел...Полностью текущее положение дел по всей планете мы ессно не узнаем. Придется оперировать доступными наблюдению фактами. Ну и если кто в своей норке что-то пилит, его для остальных можно считать что нет. Если его optimize out - ну и сколько народа заметит что что-то поменялось? Да, это вся оценка нужности ваших супер-продуктов.
Если не будет Linux Kernel - мир остановится. Не будет поездов, самолетов, встанет куча производств, привычные гаджеты резко аннулируются, и даже вайфай придется - забыть. И жизня станет заметно хуже - сразу у миллиардов.
И тут какой-то васян лечит что его ынтыгпгайз самый-самый. Это нишевая какаха, не делающая погоды. Называя вещи своими именами.
> Где код на 1с и abap? На lisp'е под Autocad, блин (не
> удивлюсь, если даже он этот самый kernel по loc'ам делает)?Да откуда я знаю где там код ваших каках? Они ко мне не относятся - никак. Поэтому меня не интересует их участь. Как категории. Вам надо? Вот вы и узнайте где, как и сколько. Это же вы ими размазиваете?!
> Программисты сотнями тысяч есть - а кода на github'е - считай, что нет. Чудеса.
Где б у вас сотни тысяч програмеров и в чем бы это результат проявлялся? :)
> Если не будет Linux Kernel - мир остановится. Не будет поездов, самолетов, встанет куча производств, привычные гаджеты резко аннулируются, и даже вайфай придется - забыть. И жизня станет заметно хуже - сразу у миллиардов.Какая котолампавая история!
Что-то аэропорты остановились когда на винде кривой антивирь все сломал.
А когда тоже самое произошло с ядром, то всем было плевать.В куче производств на станках стоят проприетарные системы реального времени.
Тысячи профи работают в CADах, обрабатывают фото и видео не на линуксе.
Даже телефоны не помрут - есть эпл с шикарной ось, есть MeeGo (Maemo/Tizen), webOS... и даже Аврора.У линукса есть всего один плюс - он бесплатен.
Как только проблемы превысят профиты, от него откажутся.
И последние телодвижения фанатиков с маневрами ЖоПЛь символов намекают, что это может случится скорее чем некоторые думают.Существует не так много софта, которые прибит к ядру и принципиально не портируется на другие платформы.
А вот софта который только винда-мак просто море.
> Ну так это значит что
> 1) В гите кода больше чем вы там вещали.
> 2) Поди майкрософт сам же и перешел внутри на гит, а кода
> у них и правда немеряно.Нет. Это означает именно то, что написано. Читайте-до-просветления.
> Ну вы там вещайте, да :). А мы посмотрим чья возьмет.
Аргументов нет - с тезисом согласны, я правильно понял?
> Сам же себе и противоречит - тезису про комиты выше.
Воу. И много коммитов в проектах в стадии "глубокая поддержка"? Вы вообще читаете на то, что отвечаете - или гптите привычно по ключевым словам?
> Полностью текущее положение дел по всей планете мы ессно не узнаем. Придется
> оперировать доступными наблюдению фактами. Ну и если кто в своей норке
> что-то пилит, его для остальных можно считать что нет. Если его
> optimize out - ну и сколько народа заметит что что-то поменялось?
> Да, это вся оценка нужности ваших супер-продуктов.Ну ок - так и записываем. Чего аноним не видит - то и не существует\не важно. Анонимоцентрический солипсизм - хвилосовское течение будующиего.
> Если не будет Linux Kernel - мир остановится. Не будет поездов, самолетов,
> встанет куча производств, привычные гаджеты резко аннулируются, и даже вайфай придется
> - забыть. И жизня станет заметно хуже - сразу у миллиардов.Я вас умоляю. Стряхнут пыль с чпуксов-солярки-быесдей-айксов-куэниксов-макосей, вольют еще пару ярдов деньгах прошлого столетия - делов-то.
> И тут какой-то васян лечит что его ынтыгпгайз самый-самый. Это нишевая какаха,
> не делающая погоды. Называя вещи своими именами.А вот еще один SAP таким образом не родить, что да - то да.
> Да откуда я знаю где там код ваших каках? Они ко мне
> не относятся - никак. Поэтому меня не интересует их участь. Как
> категории. Вам надо? Вот вы и узнайте где, как и сколько.
> Это же вы ими размазиваете?!Не пугайте страусов - пол бетонный. ВЕСЬ opensource - такой прыщ-на-кончике-носа. Да, всегда спереди, красный такой, заметный - но размер у него вот именно такой.
> Где б у вас сотни тысяч програмеров и в чем бы это
> результат проявлялся? :)Ну я ж вам статистику с HH по РФ бросал, да? 8-10к _вакансий_ в месяц. Сравните с 2к контрибуторов какого-нибудь kernel 6.9, ага. Понятно, что средний 1Сник несколько менее плодовит, нежели opensource М.А. Как-кир - 1снику иногда над предметной областью думать приходится, да и цена ошибки - кратно выше (за криво посчитанную з\п на сдельщине могут и физию намять, а за налоги и вовсе закопать - а kernel developer'а разве что "нинастоящим сишником" назовут и пошлют на rust переписывать), но один черт - кода за ними больше.
> Откуда бы, интересно? И что сие за проекты такие, которые никто не видит и не слышит?Ты их прекрсано видишь. Например, GCC и FF больше ядра. LLVM скоро их догонит. chromium так вообще вне конкуренции. Тулзы для андроида почти наверянка уделывают всё это вместе взятое.
> Ты их прекрсано видишь. Например, GCC и FF больше ядра. LLVM скоро
> их догонит. chromium так вообще вне конкуренции.И что характерно - они тоже все юзают git! Ну, может, кроме лисы, не знаю, как там эти, до сих пор с своим hg догнимают? Но линукс кернель если что - интересен еще и числом девов - их порой до нескольких тысяч за релиз набегает, насколько я помню. И тут вдруг какой-то отбитый кадр лечит что так якобы нельзя. Не потянет. Вау.
> Тулзы для андроида почти наверянка уделывают всё это вместе взятое.
Ну да, андроида много. И он - таки - тоже git юзает. Кто и что там не потянет то? Нельзя ли пояснить? :)
Весь глобус вендами пользуется, если что. И не потому что они такие хорошие, а потому что им так сказали.
> Mercurial тоже нормальная, даже в чем-то интереснее. Но на неё забили и перестали развивать.Ну так не смогли придумать в чем интереснее - и забили. Не, перепишем все и вся на пыхтонрасте - такая себе аргументация за DVCSку. Особенно когда она тормозит как апокалиптец, история и бранчи мучительные, и в общем то VCS'ка из нее - ну вот так себе весьма. А уж DVCS - господи, зачем тогда косплеить "хороший svn"? Для совсем необучашек чтоли? Ну они там и остались взаимодействовать сами с собой.
Бывший?
Bazaar
Любая система контроля версий нормальна, если она - бэкенд для гитхаба.Секрет успеха гита именно в гитхабе, сетевой эффект, все дела. Хотя казалось бы - подсаживаться на централизованный багтрекер - это не очень хорошо и его можно было бы объединить с репозиторием, как уже сделано в Fossil SCM. Но гит - это стандарт. Уже не важно, насколько он плох или хорош.
> Любая система контроля версий нормальна, если она - бэкенд для гитхаба.Не факт. HG с каким-то другим хостингом пытался. Закончилось тем что они дропнули поддержку HG :)
> Секрет успеха гита именно в гитхабе, сетевой эффект, все дела. Хотя казалось
> бы - подсаживаться на централизованный багтрекер - это не очень хорошо
> и его можно было бы объединить с репозиторием, как уже сделано
> в Fossil SCM. Но гит - это стандарт. Уже не важно,
> насколько он плох или хорош.Git - юниксвеен. И DVCS занимается - именно этим. А багтреки, вики и проч в обязаловку - таки маразм.
> Git - юниксвеен. И DVCS занимается - именно этим.Это что-то из серии "всесильно, потому что верно". Unix way - это такие старые спорные принципы, они не хороши безусловно, да и Git под них не особо подходит. Иногда программы хороши, потому что они комбайны, вбирающее в себя всё в своей сфере (ffmpeg), иногда комбайны вытесняют старые юниксвейности (systemd), иногда с годами от идеалов Unix way ничего не остаётся (ls)*. Git наслаивают, наслаивают, внизу "сантехника", сверху "фарфор", у "фарфора" всё равно с годами накапливается по 60 опций на команду, поэтому git периодически пытаются упростить ещё одним слоем в виде альтернативного CLI (gitless, например).
> А багтреки, вики и проч в обязаловку - таки маразм.
Просто есть такая ироничная проблема - DVCS завязывают на сторонний централизованный багтрекер, который несложно потерять. И сколько людей его бэкапит? А если бы его исторически встраивали в DVCS - свежий бэкап был бы у всех и был бы идеально переносимым.
Например: https://www.opennet.me/opennews/art.shtml?num=60400 - GitHub заблокировал игровой движок OpenXRay (блокировка отменена)
700 тикетов, 200 открытых, 50 тщательно развешанных лейблов, куча перекрёстных ссылок - они всё это потеряли бы, если бы не повезло.* "you shouldn't parse the output of ls" и 60+ опций у ls, чтобы избегать unix-way конвейеров.
А если я туда картинку загружу, это будет система управления исходными картинками?
Не попробуешь - не узнаешь.
Если ты думаешь что твоя картинка это не текст я спешу тебя огорчить.
С каких пор картинка это текст?
С тех самых пор как каждому байту в соответствие поставили символ ascii. Так и началось.
> С тех самых пор как каждому байту в соответствие поставили символ ascii.Но даже в пределах ASCII - текстом считается далеко не любой байт!
Это настолько очевидно что я шокирован, почему вас после родов сразу же не утопили?! Ну зачем миру нечто без головы?
> Так и началось.
Наверное какой нибудь секретный военный, ещё под комьюнистами, эксперимент с дефолиантами?
Интересно что ты тогда про всякий UU[en|de]code и Base64 расскажешь 8-о ... Погоди дай до кухни добежать, за попкорном :)
:-)))))
Гугли Netpbm
С момента изобретения ASCII-арта. Раритетное железо, на котором, как известно, сидят опеннетчики, ни что другое показывать не умеет.
Смотря в каком формате картинка, во-первых. Абсолютно любые данные можно _представить_ в виде текста, это не будет значить что бинарник - это текст. Бинарник это бинарник. Ну технари же вроде, а рассуждаете как филологи.
Текст это тоже бинарник прикинь.
С точки зрения в unix любой файл есть текст, это уже потом выдумали эти ваши бинарники
И да у первый "компьютеров" бинарников и небыло никогда, это была либо прошивка либо перфокарты
А Перфокарты как известно это текст
Вообще говоря да, это текст. Всё стало бинарями существенно позже
И что в них по итогу картинки и текст хранились каким то разным способом? Даже если это и не растровые картинки, а векторные для плоттера или любые другие какие тогда можно было вывести.
Перфокарты это абстракция над бинарным кодом, комп понимает только бинарный код.
С каких пор это комп понимает бинарный код, если изначально машина тьюринга была на немецком альфавите, а у бебиджа вообще шестеренки и десятичные цифры были. Почитайка про eniac
Есть только 10 типов людей:
- те кто понимает binary code
- те кто его не понимаетBerkeley шутка хумора.
> С каких пор это комп понимает бинарный код,
>если изначально машина тьюринга
> была на немецком альфавите,Это не комп!
а у бебиджа вообще шестеренки и десятичные
> цифры были.Это не комп!
>Почитайка про eniacЗачем? Мы говорим про компы или про историю?
Это называется обычная демагогия, когда хочется что то сказать, а не чего, поэтому скажут глупость.
Все имеет что имеет "Полноту по Тьюрингу" является вычислительный устройствам, так что иди путник куда шел.
> Все имеет что имеет "Полноту по Тьюрингу" является вычислительный устройствам, так что
> иди путник куда шел.каждый компьютер это вычислительная машина, не каждая вычислительная машина это компьютер.
Сейчас еще в компы Счета записать или вообще палочки!)))
Такое впечатление что про существование НЕХ-редактора здесь не знает никто.
Какого ещё редактора, любой файл это набор байт совсем любой попытайся это понять гуманитарий, мой дорогой.
Концеация юникс - все есть файл
/dev/tty - файл? а набор байт?
Файлов не существует. Это абстракция. Запись в таблице файловой системы. Которая - также абстракция. Способ организации данных. А в системах Unix есть ещё и псевдофайлы, содержимое которых - результат работы алгоритма.Байтов не существует. Это абстракция над группой из восьми битов.
Битов тоже не существует. Есть лишь магнитная запись на носителе. Или иной материальный способ хранения информации в физическом мире.
Двоичное кодирование информации, тоже абстракция, - не единственный способ кодирования, хотя самый распространенный и, вероятно, самый простой (есть сигнал - нет сигнала, большое сопротивление - маленькое).
Когда говорят, что файл "бинарный" или "текстовый", то подразумевают не способ кодирования, а способ декодирования. Бинарный (binary) файл читают побайтово, структура и способ декодирования такой информации определяется форматом файла. Текстовый (plain text) файл читают построчно, группами байт до строчного разделителя. Байты строки декодируются в человекочитаемые символы в соотвествии с текстовой кодировкой.
> Файлов не существует. Это абстракция. Запись в таблице файловой системы.Для технарей сообщаю: уже цать лет как есть ФС не основанные на таблицах ;). Не, B-tree таки вам не таблица.
А человека можно представить в виде волновой функции. Что это меняет? Человек перестал быть человеком?
Ты рпндомные факты выдаёшь? Молодец.
Нельзя. Волновой функцией можно представить только квантовый объект
В том понимании в которой закладывается слово Бинарник, то нет, текст не бинарник. Но если прям лезть в структуру файла, то в компе нет ничего кроме бинарников)
Тут технарей почти нет. Иной раз такую чушь начинают тут нести и доказывать, что черное это белое, что последние волосы на заду выпадают.
Не удивляйся, что люди думают, что картинка это текст, раз есть текстовое представление)
> Иной раз такую чушь начинают тут нести и доказывать, что черное это белое,О, и ты как раз один из таких персонажей. Удивитильно, что такие персонажи даже не догадываются насколько они ничего не знают и не понимают
С каких пор четырёхмерный вектор (RGBA) стал текстом?
Однажды мы с коллегами столкнулись с необходимостью переноса одного проекта с устаревшего движка на что-то, что наша команда сможет нормально обслуживать
Заглянули мы внутрь больного и обнаружили, что там как ты сказал «картинки», то есть графические файлы, фигачили какого-то беса в MySQL, а не складывали на файловой системе как это принято. Стал ли мускуль от этого из СУБД какой-нибудь СУК? Нет, не стал. Это те кто это сотворили оказались долбоклюямиА в git есть git-lfs для версионирования больших файлов. Если в него будешь совать, то все ок. Если же просто в гит фигачить, то окажешься тем же, кем те ребятки-девчатки оказались
Поясни, что плохого в хранении картинок в БД, если они не в base64 там хранятся? Целый класс уязвимостей сразу убирается автоматом.
Тут не то что плохо, а то что эффективней.
Куда эффективней картинки класть в ФС, а не в БД.
Хоть и есть плюсы в хранении картинок в БД, но из опыта скажу, плохая это идея.
Были примеры, когда мы убирали картинки из БД и БД начинала выдавать результаты в минимум в 2 раза быстрей.
Это если картинки сделать одним из полей таблицы, а если вынести картинки в отдельную таблицу и привязать по индексу только - то на скорости это никак не скажется.
> Это если картинки сделать одним из полей таблицы, а если вынести картинки
> в отдельную таблицу и привязать по индексу только - то на
> скорости это никак не скажется.Скажется. Давно пройденный путь. Картинки ЛУЧШЕ всего хранить в ФС.
Картинки в ФС закэшируются и ваш нгинкс забесплатно, вообще без движняка с вашей стороны, порвёт любую Марию Мыскл :)
Марию можно правильно поставить в позу и она будет не настолько хуже, но придется пое... понастраивать :)
Вопрос - а оно надо?
Ответ - иногда да, надо. Но редко.
Поэтому лепи в ФС, а если что пошло не так - вот тогда и смотри. Но обычно всё идёт пучком.
Главное не сделай 1 директорию под все картинки :)
> Картинки в ФС закэшируются и ваш нгинкс забесплатно, вообще без движняка с
> вашей стороны, порвёт любую Марию Мыскл :)
> Марию можно правильно поставить в позу и она будет не настолько хуже,
> но придется пое... понастраивать :)
> Вопрос - а оно надо?
> Ответ - иногда да, надо. Но редко.
> Поэтому лепи в ФС, а если что пошло не так - вот
> тогда и смотри. Но обычно всё идёт пучком.Может и есть исключительные ситуации когда картинки в ФС можно поместить.
Но в целом это вредно! Файлы надо хранить в ФС, она для этого создана! БД не для этого создана. Хоть и может хранить файлы.> Главное не сделай 1 директорию под все картинки :)
Не-не-не пройденный путь)
Тем что sendfile() работает с файловыми дискрипторами.
Даже интересно сколько чел тут вообще поняли о чём ты? :-D
sendfile() на несколько десятков KiB это да, как раз что тебе нужно делать
> sendfile() на несколько десятков KiB это да, как раз что тебе нужно делатьВы видимо не видели картинки с современных смартфонов. Там скорее - на несколько десятков мегабайт получится с их мегапикселами.
> Поясни, что плохого в хранении картинок в БД, если они не в base64 там хранятся?
> Целый класс уязвимостей сразу убирается автоматом.А также добавляется парочка новых, в паре с целыми классами нового административного гимора. Например, попробуй быренько вообще посмотреть что там пользователи налили? А, что, это надо через тормозную чтокапец вебморду, или как-то очень нестандартно извращаться? Удобно что капец. И потом еще бд пухнет, а получив предъяву "картинка не открывается" наверное интересно бэкап восстанавливать - чтобы только вот эту картинку оттуда достать, так то.
В git нет git-lfs, git-lfs это страшно-убогий костыль сбоку. Сам же git неплохо переживает большие данные до определённого объёма, несльколько десятков GiB. И в новых версиях пилят фичи вроде ленивых ссылок, вот это уже родной аналог lfs.
> графические файлы ... фигачили ... в MySQL, а не складывали на файловой системе как это принято.Не неси чуши, не принято такого. Тут разве что из неправильного это MySQL
Это ты просто никогда не терял эти карточки в файловой системе и не получал расинхрон от переноса и переименований. Молодой есчо.
Если вы настолько косорукие, что даже в ФС теряли файлы, что вам мешало потерять целую БД?! :))) Да, походу ты такой же зелёный салага, если не понимаешь, что "картинки в базе" - самая маразматическая идея!
Ты просто не в курсе что бывают компании где больше одного человека и эти люди ещё и увольняются. Бекап бд делается по умолчанию, а бекап файлов на системе это всегда такой велосипед что каждый делает его как придется или никак не делает)А ещё бывает больше одного сервера, но это уже я боюсь ты переварить не сможешь. Простое решение хранить. Картинки в бд, а на фс скидывать если надо уже из базы.
Бекапы никогда не делаются по умолчанию. Нет такого функционала, как бекап по умолчанию.
Бекап всегда настраивается и делается по расписанию, вручную или по различным триггерам. Но чтобы вот так, по умолчанию, это вообще чушь.
Или ты хотел сказать, что бекап БД всегда настраивают, а файлов нет?
Так тоже чушь!
Как и БД, так и файлы, нормальные компании и люди настраивают создание бекапов.
А про велосипед бекапов файлов, вообще выдает в тебе что ты с бекапами мало дружишь.
Для бекапов файлов созданно тонны инструментов и гораздо больше инструментов для файлов, чем для БД.
Не каждая система бекапов умеет бекапить БД! Но каждая система бекапов умеет бекапить файлы! Подумай над этим, перед тем как городить чушь, что бекап файлов это велосипед и не все делают!И хранение в БД картинок не считается хорошей практикой. БД хоть и могут это делать(БД то вообще похер что хранить в себе), но для этого не предназначена! (Удивительно для нубасов)
Опять новости из мира розовых поней. В реальной жизни так не бывает. И компании бывают не только лишь большие. И не только лишь один васян. То что кем то там считается тоже мало кого интересует. Ты ещё скажи хорошая практика в церковь ходить каждое воскресенье. Только никто туда не ходит.
> Опять новости из мира розовых поней. В реальной жизни так не бывает.Как не бывает? Что бекапят файлы? Кто тут еще из розового пони.
> И компании бывают не только лишь большие. И не только
> лишь один васян. То что кем то там считается тоже мало
> кого интересует. Ты ещё скажи хорошая практика в церковь ходить каждое
> воскресенье. Только никто туда не ходит.ну давай начинай рассказывать, что есть дебилы которые дебилы, а значит надо опираться на опыт дебилов, как быть дебилом.
Главное по сути ты ничего не сказал. Что сказать то хотел? Что есть дебилы которые не делают бекапы? Факт! Зачем нам их опыт? Кроме разве что как антипример, так не делать. Или что ты хотел сказать?
Бэкап ФС? Зачем? S3 хранилища запрещены законом?
> Бэкап ФС? Зачем? S3 хранилища запрещены законом?Бекап ФС лучше делать даже если кажется что хранилище надежное! Поверь. Уже были случаи когда облака теряли файлы.
>Бекап бд делается по умолчанию, а бекап файлов на системе это всегда такой велосипед что каждый делает его как придется или никак не делает)Ииии-пппп-аааа****** 8-о
ТО модеры: Ипалит! в смысле :)
Бэкаб базы делается только если DBA толковый, а снапы VM Avamar-ом бэкапятся даже если владельцы против :)
Так вот друК, файлы от теда - восстановятся, а БД - только если DBA толковый ... но чего он забыл в такой лавке как ты описываешь? Понятно что там тусня придурков, и в такое место даже ремотно заходить не надо :)
Нукагбэда, но потом !внезапно! выясняется, что "снапшот" это не "бэкап", и чтобы привести одно к другому надо (было) много чего ещё сделать...
> "картинки в базе" - самая маразматическая идея!Если ты файлами хранишь картинки, то у тебя есть id картинки, плюс путь файла. Получается эдакая комбинированная БД в которой тебе свои велосипеды приходится костылять, чтобы всё было чики-пуки, чтобы у тебя на каждый id был бы путь к файлу и собственно файл, и чтобы не было бы ситуаций когда что-то одно есть, а остальное отсутствует. Или два компонента из трёх есть, а третьего нет. А это значит, что тебе придётся ещё и транзакции реализовывать, чтобы когда ты начал добавлять картинку в бд, не случилось бы такого, что id и путь к файлу выбраны, а файл не записан, потому что что-то пошло не так, соединение оборвалось откуда файл скачивался, или место на жёстком диске кончилось, или тред который всё это проделывал обрушился... В таких случаях придётся откатывать назад уже внесённые изменения. И вот тут ты целую новую СУБД напишешь, пока будешь доказывать, что ты не "косорукий" и можешь хранить картинке в ФС не теряя их.
И это помимо того, что теперь чтобы отдать картинку, тебе надо взять id картинки, найти по нему путь к файлу, скормить этот путь файловой системе, чтобы та распарсила его, пробежалась бы по всем вложенным директориям, нашла бы нужный inode директории, откуда прочитала бы номер первого инода файла. СУБД может делать это гораздо эффективнее, выкидывая совершенно бесполезную здесь иерархичность путей, и непосредственно по id'у выяснять список блоков которые надо прочитать с диска.
Если тебе это кажется маразмом, то я рекомендую попить таблеток, восстанавливающих высшую нервную деятельность головного мозга, тогда в голове прояснение наступит и ты поймёшь, почему картинки надо хранить в бд.
Фига, вы тут не на жизнь сошлись! Я, как опеннет-эксперт, не державший ни одного сайта, не могу не вмешаться.Картинки надо хранить отдельно не только от базы, но и от сервера. Сервер с базой будет компактнее и стабильнее (ровнее нагрузка), его легко восстановить из бэкапа, который можно делать чаще. Сервер с картинками можно подобрать соответственно характеру нагрузки, кэшировать в CDN, добавлять диски, а если отвалится, то база устоит. У пользователей сайта, хотя бы, будет доступ к аккаунтам и текст с плашками.
Постоянный ID картинки в базе, можно использовать как имя файла при заливке.
При любом фейле нужно адекватно ошибки обрабатывать. Общее правило для некосоруких. Тогда при фейле залива будет перезалив со стороны пользователя с новой записью, ID и файлом.
А чтобы отдать картинку нужно только объединить адрес сервера и ID. Можно сразу, в отдаваемой статичной html-странице.
А ФС, вообще-то, всякие разные бывают.
> Картинки надо хранить отдельно не только от базы, но и от сервера.
> Сервер с базой будет компактнее и стабильнее (ровнее нагрузка),В смысле, займется при отдаче картинки парсингом и ФС, и БД на ней и проц в полку при случае более плотно будет? Так то хрен поспоришь.
> его легко восстановить из бэкапа,
Покажи как восстановить условную 35-ю картинку после репорта "не открывается" в вот именно базе, именно из бэкапа базы? На фс то тупо как тапка - файло скопировать.
> Постоянный ID картинки в базе, можно использовать как имя файла при заливке.
А с ФС что это все мешает? И вообще, вам не приходило в голову что ФС это такая специализированная бд, так то? :)
> А чтобы отдать картинку нужно только объединить адрес сервера и ID. Можно сразу,С ФС это так то даже проще сделать, пожалуй. А какой смысл БД косплеить файлуху - кто б его знает? С таким же успехом можно и диск-в-файле на loop device зацепить. Чем это так уж от бд key-value в файле отличаться будет - хрен бы его знает. А двойной парсинг сперва ФС потом БД или вложенной ФС вы получите для более ровной нагрузки в обеих случаях :)
Постоянно всякие штуки появляются и они выключены по умолчанию.
А есть какое то место где собраны все эти волшебные комманды, чтобы запустил и все ништяки включились?
Если тебя всё устраивает, то зачем включать? Когда обкатают на мышах и желающих, будет добровольно-принудительное включение
Написано же что включают по дефолту для новых реп - так что видимо вполне норм.
> А есть какое то место где собраны все эти волшебные комманды, чтобы запустил
> и все ништяки включились?Неужто "man" не помогает. Но с таким подходом лучше Linux Kernel попробовать. Там столько крыжиков, что врубить их все намного интереснее. Там какой-нить [x] compile drivers that wouldn't load в menuconfig закрутить - поугарать с времени сборки и того какой макаронный монстр получится.
Хорошо что в этот раз в основном внутрянку шатают.
Лишь бы на Blake3 не переходить.
При всем уважении к Бернштейну с его терабайтными RSA-ключами, ты представляешь какие последствия совместимости будут у такого перехода?
К хрену совместимость, SHA1 уже сломан (ладно, для целей гита - не сломан), его надо менять, и менять надо не на тормохной SHA256, а на мамного более быстрый Blake3. Вообще в git должны были запилить поддержку нескольких функций. И Blake сделан не Бернштейном, хотя и на основе его примитивов, а Зуко Вилкоксом, который в принципе тоже весьма легендарен.
> его надо менятьЗачем?
Да
> и менять надо не на тормохной SHA256, а на мамного более быстрый Blake3Так как ты не показал флеймграф на котором видно что в SHA256 узкое место, ты сделал ничем не обоснованое некомпетентное заявление.
> Вообще в git должны были
Кому должны?
Разверни мысль - для какой функции надо переходить на Blake3 ?
Чтобы быть впереди паровоза !
Впереди паровоза противоминной трал.
Разворачиваю. Берешь sha256sum, sha1sum, и b3sum. Натравиливаешь на один и тот же файл и замеряешь время. Файл предварительно кешируешь путём одного хэширования, но без измерения времени. После этого все вопросы должны отпасть
Как же больно за индустрию когда такие опусы читаешь. Скорость - не главное свойство хэш функции, но если ты про неё заикнулся, нужно измерить sha256 не саму по себе, а внутри типовых гитовых операций и показать там хотя бы процент выигрыша от перехода на blake3. А так-то нужно провести аудит, этой, по сути, нонейм поделки на том же уровне как изучен sha256, чтобы, будь он хоть в миллион раз быстрее, его можно использовать в git.
>нонейм поделки1. blake2 делал тоже он
2. за годы существования уязвимостей не выявлено
3. функция blake2 широко используется
4. автор - известный криптографУ анонимов опеннета - всё "ноунейм-поделка".
> 1. blake2 делал тоже он
> 2. за годы существования уязвимостей не выявленоКакие бы годы существования у blake3 могли бы быть с его без году неделей?
> 3. функция blake2 широко используется
И при чем тут blake3? Он другой.
> 4. автор - известный криптограф
Это не повод слепо доверять. На старуху тоже бывает проруха.
> У анонимов опеннета - всё "ноунейм-поделка".
Ну они то не какие-то нонеймы. Хотя... :)
>pseudo-merge reachability bitmapОчень специфичная штука и включать её так бездумно не нужно.
Тем кому надо сами включать на будут.
Нет ничего лучше, чем клик -> новая папка.
И нет никого, кто бы смог доказать обратное.
> Git является одной из самых ... надёжных и высокопроизводительных систем управления версиямиЭто же точно не про git, зачем так врать. Хотя в совокупности хорошая VCS
Гит это лучшее что произошло с системами контроля версий за последние 2000 лет. Если есть лучше почему ими никто не пользуется или почему ты не написал лучше или не нанял прогеров и не сделал лучше и не стал миллионером?
Потому что гит бесплатный, а нанять прогрреов нужны деньги.
Надеюсь дальше сам
Если ты сделаешь лучше у тебя его и купят и ещё прогеров пришлют. Так понятнее?
Фантазёр. Реальность работает несколько иначе. См. как и почему появился Git
Ну за деньги работали программисты и bitkeeper, и perforce, и clearcase, и vss и plastic. Где-то даже ещё работают. Пластик вон даже относительно современен и бесплатен для индивидуалов, нонпрофитов и опенсорса. Так и где все эти поделки? Правильно, именно там где им место, потому что в самом лучшем случае у них получается git, а git уже есть.
Git у них не получается потому что Git не масштабируется на объёмы, для которых предназначены некоторые из продуктов выше. Пишешь сам не знаешь о чём. Git подходит только для небольших проектов и небольшого кол-ва активных разработчиков в проекте.
> Git у них не получается потому что Git не масштабируется на объёмы,
> для которых предназначены некоторые из продуктов выше. Пишешь сам не знаешь
> о чём. Git подходит только для небольших проектов и небольшого кол-ва
> активных разработчиков в проекте.И все б ничего но вот Linux Kernel назвать небольшим проектом с небольшим числом участников - это надо реально быть некомпетентным проприетарным овощем живущем в своем плесневелом мирке с отдельными реальностями. Иначе можно было бы заметить что это здоровенный проект с тысячами комитеров по всему глобусу. То что у вас вообще есть проект крупнее и активнее - это далеко не факт. Мягко говоря.
Читай внимательнее что написано.Во-первых, даже по абсолютным показателям ядро это небольшой проект среди СПО. Во-вторых, речь идёт не о кол-ве уникальных коммитеров, а об ___активных___, т.е. которые постоянно коммитят в общие ветки. И в ядре это только мейнтейнеры в мизерном кол-ве. Контрибьютеры же разрабатываются в своих репозиториях и шлют результат патчами в рассылку или дают ссылки на свои репозитории, откуда мейнтейнер забирает патчи и в одно-два лицо(а) доносит в общую ветку. Это именно что проект, как где-то выше написали, "для себя и кота".
> Во-первых, даже по абсолютным показателям ядро это небольшой проект среди СПО. Во-вторых,
> речь идёт не о кол-ве уникальных коммитеров, а об ___активных___, т.е.
> которые постоянно коммитят в общие ветки.Лол, тут прекрасно все. Включая стиль "одна большая гадюшна на всех без одупляемых workflow". Но даже так - Торвальдс при открытии окна приема изменений им мастеркласс, пожалуй, даст в коммитах на рыло в юнит времени.
> И в ядре это только мейнтейнеры в мизерном кол-ве.
Только они агрегируют за толпой народа. А, вы кажется начинаете догадываться что кроме лобового масштабирования в виде 1 мега-супер-сервера - бывает, оказывается, еще и другое, используя распределенность этой штуки? Ну надо же, поздравляю с прозрением.
> Контрибьютеры же разрабатываются в своих репозиториях и
> шлют результат патчами в рассылку или дают ссылки на свои репозитории,
> откуда мейнтейнер забирает патчи и в одно-два лицо(а) доносит в общую
> ветку. Это именно что проект, как где-то выше написали, "для себя и кота".Они нынче порой шлют pull request'ы тупо, если ну вот реально много всего, типа ФС там каких-нибудь, или дров GPU, где комитов по жизни большая пачка.
Это ложь конечно, что показывает опыт ms, например, и огромных свободный проектов как-то ядро и freebsd. Есть проблемы с большими файлами, но это решается изменениями бэкенда, который пользователь вообще не заметит. А про git я говорил в том ключе что cli пластик, например, 1 в 1 git. И даже бэкенд там 1:1 git с расширениями, поэтом с ним можно и гитовым клиентом работать, и пластиковым клиентом работать с гитовыми серверами.
Лучшее что случилось это Fossil
Прям вот совсем нет. Только если может для прогера одиночки норм.
Во-первых, fossil не случился, потому что полутора калеками пользуется. Во-вторых кроме встроенного в репозиторий убогого багтрекера ему и похвастаться нечем. Он дико медленный, имеет кошмарный нелогичный cli и не поддерживает половины everyday фичей гита. Ну и не поддерживая нормально редактирование истории, он вообще не может считаться современной VCS.
> Во-первых, fossil не случился, потому что полутора калеками пользуется. Во-вторых кроме
> встроенного в репозиторий убогого багтрекера ему и похвастаться нечем.Неправда! Еще столь же бестолковая вика есть.
> Он дико медленный, имеет кошмарный нелогичный cli и не поддерживает половины everyday фичей
> гита. Ну и не поддерживая нормально редактирование истории, он вообще не
> может считаться современной VCS.Да кого VCS интересует, если, вот, багтрекер и вика? А, нормальные можно отдельно поставить? И даже есть в пакетных манагерах дистро? Ну, э, упс... :)
> Это же точно не про git, зачем так врать. Хотя в совокупности хорошая VCSДействительно, давно пора писать "самая" надёжная и производительная.
Сидел на старой работе в SVN. И все было легко и просто. Пересели на гит и сразу куча геммора. Все это разделение на коммиты и пуши не нужно, когда ты хочешь, чтобы тимиэйты сразу видели внесенные тобой изменения. Плюс еще конфликты разрешались через одно место.
Как вы критично к Micro$oft...
>... не нужно, когда ты хочешь, чтобы тимиэйты сразу видели внесенные тобой изменения.А зачем вам VCS тогда? FTP и proga_v102238.zip, ой соррян proga_v2_2404011223.zip !
"Геммор" встроен в сабж как неотключаемая фича. Особенно при использовании командной строки.
Норот не понимать, что задача vcs со всей обвязкой - поддержка процесса разработки, и в зависимости от организации процесса и требований к нему - локальный оптимум vcs может быть разным...
> Все это разделение на коммиты и пуши не нужноА если хочется только закоммитить, а пушить не хочется? А если пушить вообще некуда, разработка локальная? А если пушить есть куда, но временно нет связи с сервером, например работаешь в поезде? В общем, искореняй старые и плохие привычки, привитые старыми VCS.
> А если хочется только закоммитить, а пушить не хочется? А если пушить
> вообще некуда, разработка локальная? А если пушить есть куда, но временно
> нет связи с сервером, например работаешь в поезде? В общем, искореняй
> старые и плохие привычки, привитые старыми VCS.Зачем?! Мы просто задекларим баг - фичой: "отпугивает необучашек". И пусть они своим истошным тормозизмом достают - кого-то еще. Если кто не понимает чем комит от пуша отличается - ну, с ними и так по жизни на уровне програмизма взаимодействовать... ээ... как бы это повежливее сказать то?! Пусть своих коллег якорят могучим интеллектом?
Понимаете, гит, на уровне достаточном для IO с гитхабом - умеют даже совсем не технические манагеры в корпах. Если кто не может даже так, ну, а что это тело в IT делает вообще? Пусть рассаду выращивает, например?!
Не знаю ни одного разработчика который во времена SVN не мечтал о локальных коммитах. Некоторые svnsync'ом выкачивали себе репу только чтобы иметь что-то похожее. Вы не разработчик, видимо? А когда разделяет шаг в разработке ткущей фичи и её публикацию, проблем с commit/push не возникает. А вот конфликты в SVN не решались вовсе, и из-за принципиально убогого алгоритма, и из-за того что copy/move трекались явно, и про них всегда забывали, коммитя копию с нуля, теряя вдобавок историю, и из-за отсутствия rerere.
Для тех кто подключался к старым серверам, кому нужен DSA (ssh-dss)
PubkeyAcceptedKeyTypes +ssh-dss
HostKeyAlgorithms=+ssh-dss
не стоит обновляться, потому git (ssh) не может делать fetch, потому что не может распарсить ~/.ssh/config .