Представлен выпуск проекта GitBucket 4.33, в рамках которого развивается система для совместной работы с Git-репозиторием, предоставляющая интерфейс в стиле GitHub и Bitbucket. Система отличается простотой установки, возможностью расширения функциональности через плагины и совместимостью с API GitHub. Код написан на языке Scala и доступен под лицензией Apache 2.0. В качестве СУБД могут использоваться MySQL и PostgreSQL...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52124
Мне не нравится, юзаю Gitiles
Мне не нравится жручий Gitlab и сабж юзаю Gogs.
сабж тоже проиграет по ресурсам Gogs
Проверил gogs из докера (шутки про докер за 300) ест 37 мегабайт оперативы и 8 мегабайт база данных после логина под админом.
Gitbucket 394 мегабайта после логина над админом. Gitiles в докере (старой какой-то версии) ест 191 мегабайт.Не знаю в какой вселенной поделки на JVM могут быть памятеэффективнее чем приложение на Golang.
перепись нищебордов с оверсейлнутых vps?
Да да перепись людей которые умеют экономно тратить ресурсы, а не пускать пыль в глаза 64 гигами рам на баре метал.
После пары месяцев работы в кровавом энтерпрайзе начинаешь более философски относиться к такой ерунде, как сотня-другая гигов оперативы.
Фигово быть тобой.
Да не, норм. Где большие деньги — там и большие зарплаты, внезапно.
Т.е. когда денег меньше ты ощущаешь себя ущербней?
Деньги дают свободу. Больше денег — больше свободы.
Это первые пару месяцев-лет-десятилетий. Потом вопрос о том, кто кому хозяин, с таким подходом обычно встаёт в полный рост: процентики, конкурентики, бандосики -- каждому несчастному своё.Мне больше по нраву характеристика денег из "Трёх товарищей" Ремарка и понимание различия целей, средств и их муляжей.
PS: ещё вспомнилося тот бородатый анекдот с концовкой вида: "купил бы себе остров и загорал на нём! -- мужик, а я что делаю?" ;-)
А чтобы было ещё больше денег, можно сэкономить затраты на память хотя бы на лишние 5 процентов (на всём миллионеры серверов Вашего флота)
Судя по тексту энтепрайза ты никогда не видел и тем более не строил энтерпрайз решений, философ.
Т.е. изначально не понимаешь почему они строятся подобным образом.
Сами сервисы может показаться жирными, но часто там только кеши исчисляются гигабайтами. Серьезно нагруженные сервисы с десятками/сотнями гигабайт базами всегда по возможности кешируются. Адекватный разраб не будет дергать базу лишний раз, если это можно обойти кешированием на благо отзывчивости сервиса.И не нужно узкоприкладной напильник Go сравнивать с JVM. Это глупость великая сравнивать мартышку со слоном.
Gо не быстрей JVM это факт. Расход памяти зависит от рук разработчика.
Безусловно, наколеночный хелловорлд на Go будет занимать меньше памяти аппликейшен сервера на JVM.Ну так если я возьму и создам(с умным лицом конечно же) стендалон сетевой сервис на JDK используя Netty или Vertx, возьму OpenJ9 JDK которая кушает на 30-50% меньше ОЗУ, то результат будет сопоставим с Go.
Так зачем Gо тогда? Ответ очевиден.
> Gо не быстрей JVM это факт.Что ж вы так скромно, скажите ещё, что JVM быстрее ассемблера, и что это тоже факт, ну же!
> Ну так если я возьму и создам(с умным лицом конечно же) стендалон сетевой сервис на JDK используя Netty или Vertx, возьму OpenJ9 JDK которая кушает на 30-50% меньше ОЗУ, то результат будет сопоставим с Go.
Ну, всего в 10 раз больше памяти... мда, наверное, уже можно сопоставлять. Но сопоставление, увы, будет не в пользу жабки.
Прогресс не стоит на месте, и legacy-технологии остаются техническим долгом. Да, убыточным, но взять переписать заново будет ещё дороже.
>Так зачем Gо тогда?Не более затем, что гуглоразрабам в их цикле так удобнее (собственно, почему бы и нет). Но в конечном счёте, если нужен выигрыш в скорости разработки + оперативе и прочих плюшек - разумнее всего использовать Kotlin.
не покажется ли тебе немножко забавным тот факт, что компания-изобретатель kotlin _свою_ систему для code review наляпала на жабке, преимущественно?(угу, разумеется "не течёт". Упс, а что это вместо страницы опять "проблема при запуске gc"?) 3*50гигабайт процесса неведомо-чего - ооок, ну вот просто оно так работает... или не совсем - последний публичный анонс был в виде "ой, а линукс-версия вообще не запускалась! Но вы не думайте, мы не такие, всего за месяц исправили!"
> Gо не быстрей JVM это фактА что это за факт и где можно почитать исследование?
> Не знаю в какой вселенной поделки на JVM могут быть памятеэффективнее чем
> приложение на Golang.Когда дофига реп и юзеров + пайплайны + докер регистри памятьэффективность уже в других масштабах исчисляется, ну и способность работать под нагрузкой тоже.
Я не тестил, но мне кажется, что при прочих равных на 10к юзеров тот же гитлаб уже будет быстрее gogs/gitea (мнение взято с потолка, буду рад если кто-то тестил и отпишется об этом :) )
Гитлаб и вовсе на руби. Но десктопе после запуска система и вовсе перестает слушаться, а что будет на 10к юзверей боюсь даже представить. 64 гига оперы может конечно и хватит, но зачем когда есть альтернатива.Gogs с Postgres в качестве базы (там она у гогза выбираемая) на проекте до 10 человек полет нормальный 1 гига оперы хватит на всех.
Голый гитлаб после установки потребляет 1.5 ГБ ОЗУ.
Что весьма жирно прямо на старте.
> Гитлаб и вовсе на руби. Но десктопе после запуска система и вовсе
> перестает слушаться, а что будет на 10к юзверей боюсь даже представить.
> 64 гига оперы может конечно и хватит, но зачем когда есть
> альтернатива.CPU
1 core supports up to 100 users but the application can be a bit slower due to having all workers and background jobs running on the same core
2 cores is the recommended minimum number of cores and supports up to 100 users
4 cores supports up to 500 users
8 cores supports up to 1,000 users
32 cores supports up to 5,000 users
More users? Run it high-availability on multiple application serversMemory
4GB RAM + 4GB swap supports up to 100 users but it will be very slow
8GB RAM is the recommended minimum memory size for all installations and supports up to 100 users
16GB RAM supports up to 500 users
32GB RAM supports up to 1,000 users
128GB RAM supports up to 5,000 users
More users? Run it high-availability on multiple application servers
А разве не на пихоне? Впрочем, юзеринтерфейс у гитлаба такой что до мысли посмотреть на исходники этого дело просто не дошло.
В любой адекватной, в которой понимают, что сравнивать потребление памяти на старте, тоже самое, что сравнивать языки на примере hello world-ах, а именно, что холодный старт не имеет никакого отношения к эффективной работе с памятью, а имеет отношение только к занимаемой памяти на старте приложения.В качестве иллюстрации можно взять вот этот пост http://macias.info/entry/201912201300_graal_aot.md, там товорищ решил сравнить Java (JIT и AOT) c Go на простом примере Quick Sort-f. И, если на массивах небольшого размера Java сливала только в путь, то уже на средних и больших размерах ситуация изменилась на противоположную. Да, конечно, можно замерить на массивах маленьких размерах (или замерить только на старте) и бегать с криками, что "Java жрёт память и медленная", но если сделать сравнение на массивах больших размеров, то оказывается, что Java не такая уж и плохая.
И в enteprise-е тоже не особо важно, сколько на старте приложение потребляет память (никто не собирается часто запускать приложение, наоборот, чем реже запускается, тем лучше), главное, что на больших объёмах и нагрузках работа с Java оказывается эффективнее других экосистем.
> то уже на средних и больших размерах ситуация изменилась на противоположнуюТам лишь процентов 15 времени съедается на allocation и генерацию случайных данных для массива в имплементации для Golang. А для Java ссылка почему-то ведёт просто на коллекцию сортеров, где не видно таких же действий.
P.S.: Кроме того, это сферический тест, где не будут видны плюсы goroutine и прочих особенностей Golang.
Post P.S.: А вообще хотелось бы увидеть objdump-ы и сравнить.
Потому что нагрузка у всех разная и даже заменить один продукт другим под нагрузкой еще та задача. А на старте всегда ясно кто есть кто. Тем более после логина можно понять продукт работает и конкретно GitBucket накидывает сверху не мало мегабайт после логина так что это тоже надо учесть.
^ Молодцы, ребята
Ждём вебморду к гиту + issues прямо на расте.
На расте только каскадные таблицы можно парсить на остальное он не способен бай дизайн.
Это не так. Просто раст - это не рельсы. Макаки не освоят. А работы много, нужно много кодеров и подешевле, то есть нужны как раз макаки.
Вы всё верно сказали, но, по-моему, вы это воспринимаете как-то негативно. Зря.
А зачем позитивно воспринимать тонны крапа выдаваемые макаками на гора? Хреновый софт - это хреновый софт.
Юзаю gitea, хватает дохлой виртуалки с 1 потоком
Жреть 159 мб после суток аптайа и активного юзания двух реп, работает без докера, fcgi+unix
Было бы неплохо добавить гитею в новости :)
А что его добавлять это форк gogs с дополнительным свистелками. Список свистелок у них на сайте перечислен https://docs.gitea.io/en-us/comparison/ ну не сказал бы что там есть что-то сверхнужное за что нужно использовать именно гитею.
не знаю, чем rhodecode ce отличается от kallithea сейчас, но я помню и rhodecode до перевода в коммерческую плоскость, и его форк kallithea.так вот, что касается low ram / cpu usage: kallithea и соответственно старые rhodecode нормально себе летают на pentium 3 / 128 mb ram. а у gogs/gitea, как и у любых go-проектов, тупо нет инструкций хоть для pentium 3, хоть для процессоров несколько старше
а ещё kallithea поддерживает mercurial
https://www.opennet.ru/announce_news.shtml?cache=off
Макс по итогу новости все равно сильно правит. Иногда.
Нуу да, но если где-то не туда выправил или потерял важную задумку -- всегда можно предложить правку (или вместе с отправкой новости сразу написать в {{скобочках}} свои комментарии по неочевидным связкам, которые лучше не переписывать/стыковать с другим).
gitolite не осилил никто?
жрет меньше 10М
https://gitolite.com/gitolite/index.html
Гит без вебинтерфейса? У меня даже моноколь выпал от удивления.
Добро пожаловать в мир юниксвея. gitolite обслуживает только git-remote (по сути, это git-daemon с ACL), а веб-морда — read-only gitweb или cgit. Каждая программа делает только своё дело.
(Что, неудобно? Так бы сразу и сказали, что вам ехать, а не шашечки)
В мире юниксвея никогда не было принято затыкать явные ошибки дизайна слоями костыликов и подпорочек, да будет вам известно.gitolite действительно костыль, решающий только одну из целой пачки проблему, созданную автором гита с его "порежьте помельче, мне в экран не лезет, и пришлите в рассылку, каждую завернув в салфеточку" единственноверным способом работы.
А дело "организованной совместной разработки" никак этот костыль не решает - вообще.
В отличие от гитоведра, которое хотя бы - пытается.
> В мире юниксвея никогда не было принято затыкать явные ошибки дизайна слоями костыликов и подпорочек, да будет вам известно.Весь юниксвей, по сути, сводится к полной атомарности компонентов. Можете называть их "костыликами" или "подпорочками", сути это не меняет.
При таком подходе ошибки дизайна невозможны в принципе — если какой-то компонент работает неправильно, выкидываем его и заменяем другим. Вот как git-daemon заменяется на gitolite.> А дело "организованной совместной разработки" никак этот костыль не решает - вообще.
Он всего лишь предоставляет удалённых доступ к git-репам с поддержкой контроля доступа.
Для организованной совместной разработки есть списки рассылки.
Да gitlab тоже состоит из отдельных компонентов, вроде бы :)
Вы не поверите, даже systemd состоит из отдельных компонентов.
Даже часы с кукушкой состоят из отдельных шестерёнок.
systemd нельзя разобраться на отдельно-работающие компоненты, а gitlab можно.
Ну, если вы даже в systemd разобраться не можете, то в gitlab и подавно не разберётесь.
И с тем и другим давно разобрались, и на личности при этом не переходили.
> И с тем и другим давно разобралисьИз вашего комментария это не очевидно, очевидно обратное.
> и на личности при этом не переходили.
Глупость есть глупость. Хотите культурной дискуссии — не пишите явных глупостей.
Если это такая шутка, которая выглядит как глупость, помечайте её [сарказм].
> Из вашего комментария это не очевидно, очевидно обратное.Это не имеет отношения к объекту обсуждения. Есть что сказать по делу -- говорите. Главное на личности не переходите.
> Гит без вебинтерфейса? У меня даже моноколь выпал от удивления.;)
кстати, назачем гиту гуйня нужна? для неосиливших?
Больше всего о ненужности гуя и величии консоли пишут те, у кого линукс в вмвари под виндой. Действительно, зачем им в линуксе гуй?Аналогично, больше всего о ненужности вебморды для гита пишут те, кто им не пользуется (или пользуется раз в месяц).
опеннетовские х..перты, тыщи их...да осилили,осилили давно, убедились в полной бесполезности, и выкинули.
Никому, кроме местных васянов с их хомячковыми прожектами для себя и своих воображаемых друзей, нахрен неинтересно, "сколько жрет" то, что ничего делать не умеет, тем более - "после логина админом".
Интересно, сколько жрет система для code review, работающая с нормальной командой разработчиков нормального проекта - и можно ли ее использовать в этом качестве. (всякие вики-фигики и тикетницы можно поставить отдельные, но работа с кодом - привязана к репо)
И тут, внезапно, выясняется, что gitlab ce не так уж и ужасен, в отличие от васян-поделок на нескучных язычках, разваливающиеся с порчей всей истории после десятого разработчика и пары сотен мелких комитов в сутки.
После логина можно определить что система работает и потребление у всех, независимо от нагрузки примерно одинаково. GitBucket например после логина накидывает сотню мегабайт так что надо это учесть.Gitlab может быть интересен любителям комбайнов. Как раз кровавому энтепрайзу которому интересно куча функций и побольше и побольше и за деньги тоже побольше побольше. Список опций внушает https://about.gitlab.com/devops-tools/gogs-vs-gitlab.html
Чего стоит только
New features every month
GitLab is updated with new features and improvements every month on the 22nd.Что там за фичи пофиг главное чтобы 22 числа каждого месяца была новая.
> Что там за фичи пофиг главное чтобы 22 числа каждого месяца была новая.Цитата из их changelog:
> 12.6.1
> No changes.
Ну это хотфиксы имхо, а так в декабре они чуть раньше выкатили фичи 20 числа (22 выходной). До этого все выходило по расписанию 22 всегда что-то было.Так что маркетинг соблюден большие боссы рады. А то что этим никто не пользуется пофиг. А то что заходя на сам сервис гитлаба на его официальном хостинге жду по 30 секунд пока докрутится бегунок чтобы посмотреть чейнджлог на 600 Кб имхо знак что уж очень нагружен сей сервис.
главное, васян - верить! Что если ты не пользуешься - то и никто не пользуется.(а больших боссов вообще-то обычно продажи интересуют)
> на его официальном хостинге жду по 30 секунд пока докрутится бегунок чтобы
> посмотреть чейнджлог на 600 Кб имхо знак что уж очень нагружен сей сервис.конечно ж не нагружен - подумаешь, несколько миллионов репо, включая реально кому-то нужные. То ли дело твой васянский наколенный. Вот там ченджлог как нада - на целых шесть килобайт!
(кстати, 600 - это очень даже до...я, но васянам виднее)К тому же ждешь ты, вероятнее всего, свой тормознутый браузер, хреновато умеющий что в аякс, что в http2.
> (а больших боссов вообще-то обычно продажи интересуют)
> конечно ж не нагружен - подумаешь, несколько миллионов репо, включая реально кому-то нужные.После парочки скандалов (со сбором телеметрии и Nazi HR policy) все более-менее адекватные люди от них свалили. Волна хайпа "приходите к нам с гитхаба, мы не такие, как мелкософт" разбилась о суровую реальность.
> К тому же ждешь ты, вероятнее всего, свой тормознутый браузер, хреновато умеющий что в аякс, что в http2.
Нет, там тормозит именно бэк, достаточно воспользоваться developer tools. Но для вашего интеллектуального уровня это, похоже, недостижимая высота.
> gitolite не осилил никто?Собирался посмотреть лет десять назад, даже паковал для альта -- но в итоге сидим на своём altlinux.org/girar; надо заметить, у гитолита достаточно грамотный автор, тогда он прям порадовал.
ungit ещё классный
Ну хоть не петон, уже плюс.
Угу - сломалось, похоронив всю разработку - делаем массовую сепукку, ибо починить написанное на нескучном язычке, как показала история gpg keyservers - не может никто. Отличный плюс. Стаей макак меньше.
Думаете, если бы gpg keyservers были бы написаны на пыхе, это помогло бы избавиться от ошибки в архитектуре сети доверия?
причем тут ваша сеть доверия васянам, когда ошибка банально в том, что какая-то константа позволяет наляпать подписей больше, чем такая же константа но с меньшим значением в коде единственно-верного клиента? (мы ж боимсо-боимсо динамически выделять память, это ж нисиюрна нисисюрна, статические структуры наше всьо...ой, нилызе...)И вот найти, исправить и пересобрать за пятнадцать минут (из них десять на установку тулсета, ненужного в обычной жизни) - что не было бы проблемой ни с проклятым нисисюрным мамонтовым калом Си, ни с проклятым пригодным только для макак пехепе, да ни с каким вообще популярным языком, включая ненавистный вам пихон (пробелы тут трогать незачем) - и ничего в другом месте при этом не поломать, что тоже ни разу не бином ньютона - оказалась неспособа вся шобла, пилящая гранты вокруг поддержки keyservers. Потому что владеющих arcane magic среди них не нашлось.
Но некоторые люди, я смотрю, ничему не способны научиться.
Напрашивается название для системы сборки GitBin.
GitBucket нормально интегрируется с jenkins
Лол с джениксом любой гит интегрируется. У гита стандартный интерфейс.
Все кошки в мире серого цвета? Вылезайте уже из сумрака...И не "дженикс" а все же Дженкинс.
В 2020 выпускать продукт на жвм, да ещё и на скале.
Легаси как оно есть даже если сама команда решит пилить новый продукт на новом языке его уже придется переименовать.