Комментарии 63
Пишете красиво, но тема статьи, её содержание и заголовок у вас почему-то живут в параллельных вселенных.
Точно сказать не могу, но наверное лет пять тому назад я уже мог спокойно оформлять коммиты в браузере.
Но это не прижилось от слова совсем — нет окружения рабочей среды. Хотя до сих пор мелкие коммиты на скорую руку иногда делаю так же в браузере.
Про TraviCI тоже — зачем оно, что оно есть, почём, и самое главное — как его организовать для себя.
Оба этих *CI имеют хорошую интеграцию с GitHub. И в этой связке легко настраиваются на проверку кода на «собираемость» и на прохождение unit-тестов, а также можно настроить загрузку бинариков например на тот же GitHub залить собранные бинарики в ассеты релиза.
Хотя конечно в плане тестов можно и не ограничиваться unit-тестами, можно практически любой уровень автоматизированного тестирования организовать.
Собственно именно благодаря автоматической сборке навешенной как обязательная проверка для пуллреквеста и можно кодить в браузере — написали код, закомммитили в свою репу, а а в ваш пулреквест этот коммит автоматом попадет и произойдет повторная проверка сборки. Не прошло — лезите в этот *CI (прямо по ссылке из пуллреквеста) и смотрите какие были ошибки — правите код коммитите по новой.
Есть у этого решения один неприятный момент — ESP раздел отформатирован в FAT32, на которой невозможно создать жесткие ссылки (которые система создает регулярно при обновлении initrd). И ничего особо криминального в этом нет, но видеть предупреждения системы при обновлении компонентов ядра — не очень то приятно…Это проблема? initrd вообще не нужен, как и ссылки куда-то там. У меня есть два ноута (разных), на обоих ESP и есть /boot и на нём лежит ровно один файл — efistub'нутое ядро. Всё работает.
Я вас и больше обрадую. Будущее прям ещё дальше скакнуло — GitHub Actions. И не нужны никакие внешние CI
GitHub Actions, если говорить про pet проекты
GitLab CI, если говорить про компанию
Про маленькую компанию. Он тормозит жутко, если немного побольше в него запустить.
GitHub Actions, если говорить про pet проекты
Или богатую компанию.
В рамках отказа от оитхаба в свете их поглощения мягкими?
Все к чему прикасаются мягкие становится ужасным
Скайп прям один из самых наглядных примеров.
Да и вообще мягкие имеют свой путь, как Россия — все их продукты дерьмо, Гейтс точно не русский?
Так что все что кажется не так как кажется и я бы не стал все вся обобщать — это не здоровый подход по жизни, ИМХО.
А правда, что скайп хоть когда-то не был дерьмом? Можно узнать когда конкретно?
Не было таких времен, он всегда был ужасным, кривым и тормознутым.
А сейчас это стало сильно заметнее, появились инструменты, которые делают все тоже самое, но быстрее в разы лучше и безопаснее.
Но нормальной замены для видеозвонков, объективно — нет. :/
Skype да, не лучший пример. Для текстового IM перешёл в Telegram, Skype остался только для видеозвонков. Мобильный клиент у Skype слишком тяжёлый и тормозной для постоянного использования. Да и новый десктопный клиент тоже теперь задумчивый.
«We're working on caching packages and artifacts between workflow executions, we'll have it by mid-November.»
Пишите! Интересная статья, ещё бы подробнее о работе прямо в браузере :-)
IDE как онлайн сервис, за абонентку, такое будущее нас ждёт…
Мне вот тоже надоело софт устанавливать и настраивать на разных рабочих местах, поэтому установил на одном компе и подключаюсь туда удаленно программы писать. Даже со смартфона, но с него неудобно — экран маленький, жду когда очки VR подешевеют
Вы видели как конфиг граба строится?
Вы редактируете специальный файл, который управляет шаблонизатором и строит монструозный boot.cfg.
Lilo — один файл, и больше ничего.
habr.com/en/company/oleg-bunin/blog/458922
Другое дело — настраивать диспетчер загрузки UEFI не так то просто и порой опасно (окирпичить совсем комп трудно, но восстанавливать потом тоже непросто).
И большая часть проблем тут обычно от кривой вендорской реализации UEFI.
Так что выкидывать загрузчики на свалку еще рановато.
По поводу нескольких ядер — так и UEFI может загружать столько вариантов сколько вам надо. Конкретно в UEFI-Boot реализовано именно так: в пункты меню загрузчика UEFI добавляются записи для всех ядер, которые утилита находит в /boot. Более того за счет задания переменной UEFI BootOrder загрузка делается поэтапно — если со самым свежим ядром не загрузится то UEFI будет пытаться загружаться с предыдущим.
К сожалению, мой ноут находит только загрузчик со стандартным именем. Хотя, может быть я не знаю, как правильно называть ядра. По крайней мере, если батарейку отключить, что найдётся только
EFI/BOOT/BOOTX64.EFI.
EFI/BOOT/BOOTX64.EFI — это место расположения загрузчика, которое используется если не задано других опций загрузки в менеджере загрузки UEFI. И вам хотя бы в том повезло что отключение батарейки приводит к ожидаемым результатам.
Но вот если без эксцессов, то прописанные опции загрузки BOOTxxxx сначала перебираются в порядке заданном в BootOrder. А вот если их нет или по ним загрузка не удалась, то запускается режим recovery в котором первым делом производится попытка загрузиться из EFI/BOOT/BOOTX64.EFI.
А как прописывать разные ядра — можете посмотреть на гитхабе (смотрите ссылки в начале статьи).
А так то Code Review никто не отменял — я с таким посылом PR и создавал что бы мой код проверили и поправили если надо. Примерно так авторы и поступили.
Ну а вообще то это нормальная практика в Open Source принимать PR-ы от «энтузиастов».
Как работает эта фича я руками проверил на нескольких прошивках UEFI.
Спеки UEFI я изучал достаточно детально. И добавленный код полностью соответствует спецификации UEFI.
Сбоку из мастера я таки сделал и проверил — то что я делал руками и то что работало — работает будучи сделанным и утилитой. Речь то про один бит в структуре загрузочной записи менеджера загрузки UEFI.
Да и код мой авторы проверили и подправили местами.
Так что (на сколько я могу судить), ничего сломать мне не удалось.
Да и опыт добавления своего функционала в чужой код у меня есть. Конкретно в этом PR вместо того что бы пытаться совместить обработку двух опций (LOAD_OPTION_ACTIVE и LOAD_OPTION_FORCE_RECONNECT) в одой функции я таки сделал копию функции от LOAD_OPTION_ACTIVE и переправил ее на LOAD_OPTION_FORCE_RECONNECT — это тоже не самый лучший паттерн, но в плане добавления функционала такой копи-паст страхует от ненужного вмешательства в работающий код. Позже, если кто-то захочет это место привести к одной общей функции — ну вельком.
Я бы как минимум изменил заголовок, ибо ожидал прочесть статью совершенно другого вида.
Не говоря о том, что итог статьи, опять же, не связан с тезисом заголовка.
P.S.
Здесь замешана темная магия или Владимир Владимирович?
C (язык программирования)Можно проще — «Си».
Будущее уже здесь или кодим прямо в браузере