Надеюсь они хоть в 8ке перейдут на python>=3.5 по умолчанию, а вместе с ними и CentOS, и Oracle Linux. Из-за них приходится поддерживать на 2.7 проекты, а это порою капец как неудобно.
Я с Gentoo уже лет 5 назад перешёл на Calculate Linux. Там есть в принципе всё, чаще даже есть в репах то, чего нет в других дистрах. Ядро тоже используется более свежее, поэтому никогда не испытывал проблем с поддержкой оборудования.
Коллега использовал SuSE, но он несколько раз упирался в то, что в репах только одна версия пакета, поэтому при поломке не мог откатиться назад и ждал релиза.
Есть еще коллега — любитель Fedora, но этот мистер знает толк в извращениях даже похлеще меня.
Один из действительно важных релизов для пользователей CE-версии.
Осталось только дождаться, когда возможность дашборды создавать позволят в CE и тогда вообще всё прекрасно будет.
Вы можете подключить к проектам ваш собственный gitlab-runner и его уже подключить к какому удобно docker. Единственная проблема в данном случае будет — подключать вручную ваш runner к новым проектам. Но как по мне, так это не проблема вовсе.
Вся информация о репозитории и базе данных проекта-шаблона будет скопирована в ваш новый проект, включая репозитории проекта и вики, задачи, настройки проекта и другое.
Разве форк решает подобную проблему? Если бы нужно было просто скопировать репозиторий, то это можно было бы решить даже просто pipeline'ами. Проблема в том, чтобы выгрузить настройки, задачи и прочее.
Пока что смотрю в сторону экспорта/импорта проектов в связке с ansible для автоматизации этого действия.
Это частично работает, но не всегда… только не надо ограничиваться только им.
Я с вами полностью согласен. Я же не говорю, что нужно использовать только этот метод. Безусловно в любой сфере не надо исключать здравый смысл и искать «серебряную пулю».
Я только обрадовался, что появилась возможность создавать свои шаблоны проектов, но потом увидел, что мимо CE. С одной стороны, я их понимаю, кушать все хотят, но всё равно обидно.
Лучше всего UI улучшается, когда разработчик сам регулярно пользуется приложением. Бывают конечно исключения, но чаще всего это помогает быть «в шкуре» пользователя и проявлять больше эмпатии.
А можете рассказать о структуре ES? Строили для заказчика ещё на 2.4 версии хранилище для логов и у них, насколько мне известно, всё ещё успешно используется. Сталкивался с проблемой, что нужно отделять HTTP и Мастер/Дата-ноду, в противном случае под нагрузкой ES стабильно падал. Достаточно было просто два сервиса на разных портах поднять и проблема уходила.
Каждый раз открываю новости о новом релизе Gitlab, всё надеюсь увидеть кастомные шаблоны проектов. А вообще отдельное большое спасибо вам за продукт, особенно Free реализацию.
Мне кажется тут как раз всё просто: тимлид это су-шеф, который тесно взаимодействует с администратором пекарни (менеджером по продажам) и «гоняет пекарей», тестировщик — дегустатор. С фронт/бек посложнее: бекенд это корж для торта, а фронтенд — ягоды и крем.
В ваше высказывание закралась логическая ошибка: причём здесь конкуренты? Оборот может быть небольшой не только из-за конкуренции, а ещё и от слабой платёжеспособности населения.
Собственно поэтому это нововведение в первую очередь малый бизнес и «кошмарит».
Вообще действительно завышенное число. Но для разных компаний по разному. Например, моей родственнице пришлось купить кассу (35к), ноутбук (20к), 1С на два рабочих места с Розницей (13к + 6к) для того, чтобы удовлетворить требованию вести учёт. Доход от продаж в месяц 100к — зп сотрудникам (всего около 60к). При этом обучить старушек-продавцов действительно нетривиальная задача. Итого нагрузка в виде 69к при месячном доходе чистыми в 40к. Как-то накладно малому бизнесу такая инициатива.
Платить налоги должны все, тогда возможно их будет и снизить за счет роста собираемости.
<сарказм>Точно! Поэтому в Приморском крае топливо по 44р/л и транспортный налог</сарказм>
Оставили бы в покое малый бизнес, в стране и так который год стагнация.
Малому бизнесу такая инициатива мягко говоря в нагрузку. Я подключил родственнице всё что нужно (экономия на обслуживании). Теперь ей нужно подключить непродовольственный отдел с ещё меньшим доходом. Логичным решением было закрыть непродовольственный отдел.
Коллега использовал SuSE, но он несколько раз упирался в то, что в репах только одна версия пакета, поэтому при поломке не мог откатиться назад и ждал релиза.
Есть еще коллега — любитель Fedora, но этот мистер знает толк в извращениях даже похлеще меня.
Осталось только дождаться, когда возможность дашборды создавать позволят в CE и тогда вообще всё прекрасно будет.
Разве форк решает подобную проблему? Если бы нужно было просто скопировать репозиторий, то это можно было бы решить даже просто pipeline'ами. Проблема в том, чтобы выгрузить настройки, задачи и прочее.
Пока что смотрю в сторону экспорта/импорта проектов в связке с ansible для автоматизации этого действия.
Я с вами полностью согласен. Я же не говорю, что нужно использовать только этот метод. Безусловно в любой сфере не надо исключать здравый смысл и искать «серебряную пулю».
В ваше высказывание закралась логическая ошибка: причём здесь конкуренты? Оборот может быть небольшой не только из-за конкуренции, а ещё и от слабой платёжеспособности населения.
Собственно поэтому это нововведение в первую очередь малый бизнес и «кошмарит».
Вообще действительно завышенное число. Но для разных компаний по разному. Например, моей родственнице пришлось купить кассу (35к), ноутбук (20к), 1С на два рабочих места с Розницей (13к + 6к) для того, чтобы удовлетворить требованию вести учёт. Доход от продаж в месяц 100к — зп сотрудникам (всего около 60к). При этом обучить старушек-продавцов действительно нетривиальная задача. Итого нагрузка в виде 69к при месячном доходе чистыми в 40к. Как-то накладно малому бизнесу такая инициатива.
<сарказм>Точно! Поэтому в Приморском крае топливо по 44р/л и транспортный налог</сарказм>
Согласен полностью с Merkusheva:
Малому бизнесу такая инициатива мягко говоря в нагрузку. Я подключил родственнице всё что нужно (экономия на обслуживании). Теперь ей нужно подключить непродовольственный отдел с ещё меньшим доходом. Логичным решением было закрыть непродовольственный отдел.