Разработчики проекта Heptapod, развивающего форк открытой платформы совместной разработки GitLab Community Edition, адаптированный для использования системы управления исходными текстами Mercurial, объявили о введении в строй публичного хостинга для Open Source проектов (foss.heptapod.net), использующих Mercurial. Код Heptapod, как и GitLab, распространяется под свободной лицензией MIT и может использоваться для развёртывания аналогичных хостингов кода на своих серверах...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52268
Зарегался. Ну и как там создать новый репозиторий? Запрещено я так понимаю?
В новости куча условия для размещения ты их выполнил? Гитлаб написан на руби он не сможет выдержать даже опеннетэффект, не то что хаброэффект или какие там заграницей еще есть эффекты?
Слешдот еще жив?
> Гитлаб написан на руби он не сможет выдержать даже опеннетэффектУ гитлаба нормальный HA, всё он выдержит. Язык бэкенда вообще не играет никакой роли. Роляет всегда архитектура бэка.
В случае руби играет роль экстенсивный рост мощностей серверов. И сюрприз, сюрприз он упирается в деньги что даже сабжевый проект на старте не может себе позволить такое количество.Да даже стоковый гитлаб как сервис тоже еще тот тормоз. В его оправдание только большое количество плюшек.
> экстенсивный рост мощностей серверовO_o
Просветите, что означает слово "экстенсивный" в данном случае?
Значит это что ей перекрываешь большое потребление ресурсов этим самым руби. И делаешь это только для того чтобы отдача страничек не прерывалась по таймауту.Тут похоже фанатик руби а комментариях. Для них то да трата ресурсов пустой звук.
> Значит это чтоА вопрос-то был простой, между прочим.
freehck таки псино-дев, так что в отличие от тебя он знает что говорит. Просто серверов потребуется в эн раз больше чем с go/c++/чеготамеще, но вот масштабировать дотыканием серверов можно на любом ЯП - если архитектура бэка позволяет.А если не позволяет - как только ты превысишь возможности 1 железки, тебя ждет жестокий болт на люобм ЯП. Ну вот например, если HDD или даже SSD читает вот столько - быстрее этого ты не прыгнешь. А если поставить десяток серверов и там будут параллельно сразу 10 таких штук вкалывать - суммарно оно сможет больше, ага? :)
Вопрос разумный, но святять лучше всё же не надо, надо просвещать :-)
> Вопрос разумный, но святять лучше всё же не надо, надо просвещать :-)Уел. )
>> экстенсивный рост мощностей серверов
> O_o
> Просветите, что означает слово "экстенсивный" в данном случае?Наверное, это:
CPU
This is the recommended minimum hardware for a handful of example GitLab user base sizes. Your exact needs may be more, depending on your workload. Your workload is influenced by factors such as - but not limited to - how active your users are, how much automation you use, mirroring, and repo/change size.
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
This is the recommended minimum hardware for a handful of example GitLab user base sizes. Your exact needs may be more, depending on your workload. Your workload is influenced by factors such as - but not limited to - how active your users are, how much automation you use, mirroring, and repo/change size.
You need at least 8GB of addressable memory (RAM + swap) to install and use GitLab! The operating system and any other running applications will also be using memory so keep in mind that you need at least 4GB available before running GitLab. With less memory GitLab will give strange errors during the reconfigure run and 500 errors during usage.
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
>>> экстенсивный рост мощностей серверов
>> O_o
>> Просветите, что означает слово "экстенсивный" в данном случае?
> Наверное, это:Потрясающе. При увеличении нагрузки серверу требуется больше ресурсов. Ну надо же.
Просто из любопытства: а как тогда должен выглядеть "интенсивный рост мощностей серверов"? =)
Скучный ты, Орду (с)
Просто оратор решил заменить "слишком много жрёт" умным и красивым словом.
> Скучный ты, Орду (с)
> Просто оратор решил заменить "слишком много жрёт" умным и красивым словом.Угу. Это был лазерный оратор. Лазерный, понимаешь? Не понимаешь, да? Какой же ты скучный! Я просто решил заменить "не понимает, что говорит" умным и красивым словом! :)
А вдруг оратором был кибранский БКЦ с апгрейдом на лазер 🤔
>> Скучный ты, Орду (с)
>> Просто оратор решил заменить "слишком много жрёт" умным и красивым словом.
> Угу. Это был лазерный оратор. Лазерный, понимаешь?Ещё как. Отчётливо помню, как преподаватель перемещалась вокруг стула, рассказывая про орбиты электронов, потом со знанием дела на него запрыгнула и подытожила: «вот так, дети, и происходит излучение!»
А механики, цуки, рассказывали что у электронов нет орбит...
> Роляет всегда архитектура бэка.да-да, при бесконечных деньгах - "роялит архитектура".
Но у этих ребят - деньги конечные, поэтому роялит, внезапно, п-цовая неэффективность кода на нескучном язычке.
Что он где-то там прекрасно масштабируется на мощности, которых у них просто нет - им мало поможет."А других разработчиков у меня для вас - нет."
> Что он где-то там прекрасно масштабируется на мощности, которых у них просто нет - им мало поможет.Если у клиента нет денег, то ему и HA не нужен.
Да и знаешь, люди так-то всё равно стоят дороже железа.
Ну если так утрированно рассуждать, то при таком подходе их никогда и не будет
>Гитлаб написан на руби он не сможет выдержать даже опеннетэффект, не то что хаброэффект или какие там заграницей еще есть эффекты?Гитлаб даже сам себя выдержать не может: GitLab has memory leaks. These memory leaks manifest themselves in long-running processes, such as Unicorn workers. (The Unicorn master process is not known to leak memory, probably because it does not handle user requests.)
https://docs.gitlab.com/ee/administration/operations/unicorn...
(и эти люди-рубисты будут рассказывать о мемори ликах в плюсах...)
все норм, автомагические дрессированные обезьянки перезагрузят, не волнуйтесь.
One other thing that stands out in the log snippet above, taken from GitLab.com, is that ‘worker 4’ was serving requests for only 23 seconds. This is a normal value for our current GitLab.com setup and traffic.Зато мы прекрасно масштабируемся - срочно завезите нам еще сто новых серверов, вам же денег девать совершенно некуда, мы точно знаем!
https://foss.heptapod.net/heptapod/foss.heptapod.net/issues/new
С таким подходом идут они лесом.
Нет, дружочек - лесом-то идешь - ты, со своим васян-репо.
Outstanding. Чем больше васянов с их крапом пойдет нафиг, тем быстрее hg исчезнет с глобуса.
в osdn.Org неплохо меркуриал подлерживается. Он бодрее sourcefore ворочается.
Попробуйте туда сунуться. Только там тож вроде без заявок не обойтись.
Это что бы потом их все вместе прикопать?
Удобно!
Прямо Идлиб для меркуриала :)
Лет на 10-12 опоздали.
С меркуриалом все было понятно уже 10-12 лет назад. Сабж это кунсткамера или музей для проектов которые некуда больше деть.
лучше бы gogs/gitea форкнули, gitlab здороооовый
Гогз был бы самым лучшим решением. Если нужен просто репозиторий без свистелок.
kallithea неплоха, но нет трекера и вики. гогс-гитея приятен именно своими свистелками (трекер и вики)
Свистелкам приятен гитея но не гогз.
Есть Sourcehut, который лучше: https://sourcehut.org/blog/2019-08-21-sourcehut-welcomes-bit.../
Чем лучше-то?
Работает без JS.
> Работает без JS.Он, конечно, работает... но зайди на https://git.sr.ht/~sircmpwn/core.sr.ht/tree и попробуй так же на, допустим, гитхабе. Даже без JS. Почувствуй разницу.
Эти верстали так же как и кодили. Видимо, кодинг на питоне и верстать приучает так же.
ну зашел, в чем проблема? Слишком быстро открылось, не пришлось пялиться сперва на пустую страницу, потом на моргающие-переливающиеся плэйсхолдеры (зато так модно), потом закрыть бесполезный svg баннер на пол-страницы, хипстота в шоке ?> Эти верстали так же как и кодили.
да, ничего не пищит, не моргает и не колет глаза дикими цветовыми пятнами. Как в этом может работать совеременный разработчик с отбеленной бороденкой и штанцах с подворотиками - не знаю.
вы разницу между ржавым камазом и услугами по грузоперевозке хорошо понимаете? Это - ржавый камаз, к тому же кто-то сп-л одно из задних колес.А с услугой - sr.ht is currently in alpha, and the quality of the service may
[be shitty]
не говоря уже о том что планировалось сделать его платным, без всяких соплей - но даже это не взлетело.Впрочем, девятих@й скорее всего тоже не взлетит. Олдфагов, все еще пользующимся hg, скорее всего от интерфейса с мигающими и пищащими перделками стошнит.
А как же встроенный CI? Без него пацаны засмеют.
А зачем форк, в апстрим влить нельзя, переименовав его из GitLab в SCMLab?
Гитлаб итак медленно ворочается куда ему ещё меркуриал?
Да нас рать на меркуриал, главное чтобы слой абстракции принесли, который позволит добавить туда и другие SCM.
Можно сделать просто транслятор который по хукам будет добавлять гит в меркуриал и даже наоборот. Но зачем делать из хлеба троллейбус?
> Можно сделать просто транслятор который по хукам будет добавлять гит в меркуриал
> и даже наоборот. Но зачем делать из хлеба троллейбус?А теперь попробуйте все это сделать ... ну хотя-бы без пачки глупых хипстерских вулнов, иначе сервис через три дня работы объявит себя покемоном и присоединится к ботнету.
внезапно, исходники "апстрима" - закрытые.В CE нет никаких следов поддержки немодных-немолодежных vcs - и вряд ли у тебя получится что-то туда "влить", что оттуда намеренно удалено бесследно.
А кто запретит? Можно ещё и под agpl запилить ради лулзов. Но это придётся поддерживать, что уже будет проблемой
апстрим. "запретит" путем положения болта на твои хотелки.Запилить-то ты можешь только личный васян-форк (что эти ребята и сделали, но - договорившись с крышей заранее, поэтому чуть менее васянский)
И нет - поменять лицензию нельзя. Если ты вместо форка, конечно, не готов переписать все с нуля - и чур не подглядывать.
> апстрим. "запретит" путем положения болта на твои хотелки.
> Запилить-то ты можешь только личный васян-форк (что эти ребята и сделали, но
> - договорившись с крышей заранее, поэтому чуть менее васянский)
> И нет - поменять лицензию нельзя. Если ты вместо форка, конечно, не
> готов переписать все с нуля - и чур не подглядывать.AGPL нельзя компоновать с MIT?
"компоновать" - можно. Выбросить чужую лицензию и вместо нее положить свою - нет, нельзя.
>внезапно, исходники "апстрима" - закрытыеДа ладно! https://gitlab.com/gitlab-org/gitlab - исходники ПРОПРИЕТАРНОЙ версии.
Нельзя, слишком много перелопачивать, да и не факт, что апстрим правки примет
факт что он их не примет - не для того выпиливал.
(вроде, еще два года назад - ограниченная поддержка hg-репозиториев на самом gitlab была? С тех пор, к счастью, у меня не было поводов заходить в это вырвиглазие.)
> факт что он их не примет - не для того выпиливал.
> (вроде, еще два года назад - ограниченная поддержка hg-репозиториев на самом gitlab
> была? С тех пор, к счастью, у меня не было поводов
> заходить в это вырвиглазие.)ссылок бы, благо исходники открыты
ну я вот порылся - никаких следов не нашел. Сделать чекаут этого чудища и рыться уже детально в гигабайтах git log - оставляю энтузиастам.Все же, подозреваю, если бы было так просто - этим ребятам не понадобилось бы переделывать с нуля.
А стабильную работу Меркуриала под 3-м Питоном уже обеспечили?
Или будут под 2-м?
его перепишут на руби; 1.9
вот и хоспис для hg-проектов подвезли
Как будто система управлениями версиями — определяющая характеристика проекта. Или что такое "hg-проекты"? Система управлениями версиями — это просто инструмент, который не так уж сложно поменять. К сожалению, большинство разработчиков просто идет на поводу у масс, но есть еще инженеры, которые выбирают свои инструменты исходя из их технических достоинств и в соответствии с решаемыми задачами, поэтому не все используют Гит.
> Как будто система управлениями версиями — определяющая характеристика проекта.а то! Используете мамонтово уг - вы немодные-нестильные-немолодежные, к тому же вы против sjw (альтернативно-одаренные испытывают неимоверные страдания, обнаружив что у вас не работает git clone и им надо ставить какой-то софт!)
Хрен вам, а не патчи и багрепорты!
И, главное - хрен вам бабло от всяких фондов и прочих попильно-отмывален. Поэтому проект с такой характеристикой - обречен.
Ну если только он не мурзила, но та, полагаю, тоже рано или поздно пойдет за всеми.
А какие технические преимущества у hg?Интерфейсные - да: hg намного приятнее в использовании, из git-а все же до сих пор торчат его кишки, и надо понимать, что делаешь. Но при условии, что git book прочитан и осмыслен, именно технической разницы я вообще не вижу (хотя упорно пользовался hg, пока это не перестали делать почти все).
У Mercurial нормальные ветки (информация о ветке сохраняется в каждом коммите), полноценно трекаются переименования файлов (в Git есть только имитация этого путём сравнения похожести файлов, но это не всегда работает). Всю историю проекта можно без потери подобной информации перенести из Git в Mercurial, но не наоборот. Ну и формат репозитория более компактный. Тоже иногда полезно =)
> вот и хоспис для hg-проектов подвезлиА как дойдут до кондиции - попадут в инкубатор опача!
> прекращением поддержки Mercurial хостингом BitbucketF..g LOL!!!