Sly_tom_cat 12 окт 2019 в 21:20

Будущее уже здесь или кодим прямо в браузере

3 мин

29K

Open source**nix*C*GitHub*UEFI*

Recovery Mode

+20

Комментарии 63

wxmaper 12 окт 2019 в 21:47

Пишете красиво, но тема статьи, её содержание и заголовок у вас почему-то живут в параллельных вселенных.

+21

Sly_tom_cat 12 окт 2019 в 23:04

САРКАЗМ_МОДЕ=ON
А разве на хабре принято иначе?

-3

extempl 13 окт 2019 в 09:06

А вы на редакторов равняетесь?

+12

Sly_tom_cat 13 окт 2019 в 11:29

Это моя первая статья и оно само как-то так получилось.

ZaEzzz 12 окт 2019 в 22:24

Будущее наступило давно.
Точно сказать не могу, но наверное лет пять тому назад я уже мог спокойно оформлять коммиты в браузере.
Но это не прижилось от слова совсем — нет окружения рабочей среды. Хотя до сих пор мелкие коммиты на скорую руку иногда делаю так же в браузере.

NetBUG 13 окт 2019 в 22:52

Именно
Фикс сделать — возможно, исправить конфликт — весьма удобно, но писать новую функциональность — такое себе

LuckyOok 12 окт 2019 в 22:48

Да, хотелось бы побольше про кодинг прямо в браузере.
Про TraviCI тоже — зачем оно, что оно есть, почём, и самое главное — как его организовать для себя.

Sly_tom_cat 12 окт 2019 в 22:58

TravisCI конкретно мне не зашел. Мне как-то больше понравился CircleCI.

Оба этих *CI имеют хорошую интеграцию с GitHub. И в этой связке легко настраиваются на проверку кода на «собираемость» и на прохождение unit-тестов, а также можно настроить загрузку бинариков например на тот же GitHub залить собранные бинарики в ассеты релиза.
Хотя конечно в плане тестов можно и не ограничиваться unit-тестами, можно практически любой уровень автоматизированного тестирования организовать.

Собственно именно благодаря автоматической сборке навешенной как обязательная проверка для пуллреквеста и можно кодить в браузере — написали код, закомммитили в свою репу, а а в ваш пулреквест этот коммит автоматом попадет и произойдет повторная проверка сборки. Не прошло — лезите в этот *CI (прямо по ссылке из пуллреквеста) и смотрите какие были ошибки — правите код коммитите по новой.

DreamingKitten 12 окт 2019 в 22:49

Есть у этого решения один неприятный момент — ESP раздел отформатирован в FAT32, на которой невозможно создать жесткие ссылки (которые система создает регулярно при обновлении initrd). И ничего особо криминального в этом нет, но видеть предупреждения системы при обновлении компонентов ядра — не очень то приятно…

Это проблема? initrd вообще не нужен, как и ссылки куда-то там. У меня есть два ноута (разных), на обоих ESP и есть /boot и на нём лежит ровно один файл — efistub'нутое ядро. Всё работает.

НЛО прилетело и опубликовало эту надпись здесь

DreamingKitten 13 окт 2019 в 20:42

Gentoo

В этом всё и дело. Нам, гентушникам, не понять ^_^

IGR2014 12 окт 2019 в 23:02

Я вас и больше обрадую. Будущее прям ещё дальше скакнуло — GitHub Actions. И не нужны никакие внешние CI

Sly_tom_cat 12 окт 2019 в 23:10

GitHub Actions мне показалось пока сыроватым. Но ему от роду то всего-ничего. Уверен что оно действительно потеснит внешние решения. Но вот переносить свое CI решение с одной платформы на другую — нужны серьезные мотивы.

IGR2014 12 окт 2019 в 23:48

Я и не говорил про переносить. Можно сразу несколько использовать же.
Да, Actions пока сыроваты, но работают вполне сносно. Мне приятно что до них можно добраться в один клик без переходов на другие сайты. И результат сразу видно возле последнего коммита. Удобные плюшки

dikkini 12 окт 2019 в 23:48

GitLab CI, если говорить про компанию
GitHub Actions, если говорить про pet проекты

BugM 13 окт 2019 в 01:45

GitLab CI, если говорить про компанию

Про маленькую компанию. Он тормозит жутко, если немного побольше в него запустить.

GitHub Actions, если говорить про pet проекты

Или богатую компанию.

chupasaurus 13 окт 2019 в 18:51

Self-hosted Gitlab тормозит одинаково при любой нагрузке, эту фичу правда сейчас дорабатывают. В моей маленькой (около сотни разработчиков, 400 реп) компании инсталляция ещё не смогла упереться ни в один из ресурсов.

Areso 13 окт 2019 в 19:43

Может тогда Jenkins? И «готовить» можно на любой вкус.

AlexanderMarginal 13 окт 2019 в 14:10

В рамках отказа от оитхаба в свете их поглощения мягкими?

-2

НЛО прилетело и опубликовало эту надпись здесь

AlexanderMarginal 13 окт 2019 в 15:53

Все к чему прикасаются мягкие становится ужасным

Viceroyalty 13 окт 2019 в 17:22

А ведь таких примеров — масса

AlexanderMarginal 13 окт 2019 в 18:11

+
Скайп прям один из самых наглядных примеров.
Да и вообще мягкие имеют свой путь, как Россия — все их продукты дерьмо, Гейтс точно не русский?

-1

Sly_tom_cat 13 окт 2019 в 18:21

Со скайпом вообще веселуха. У нас на работе его используют в основном для внешних связей (внутри slack). У многих стоит Linux и вот замечено уже многими у нас — Skype-for-Linux работает куда как надежнее чем на винде.

Так что все что кажется не так как кажется и я бы не стал все вся обобщать — это не здоровый подход по жизни, ИМХО.

AlexanderMarginal 13 окт 2019 в 18:23

Просто на Linux все что угодно работает лучше чем на винде))))
А на Mac OS еще лучше))

-3

ZiggiPop 13 окт 2019 в 20:43

А правда, что скайп хоть когда-то не был дерьмом? Можно узнать когда конкретно?

DreamingKitten 13 окт 2019 в 21:24

Году этак в 2006 он меня прямо поразил поддержкой множественных подключений с разных устройств и синхронизацией истории в них. По сравнению с аськой это был просто технологический прорыв, и вот примерно в то время его десктопные клиенты ещё не были дерьмом и не тормозили.

var 14 окт 2019 в 12:57

Не было таких времен, он всегда был ужасным, кривым и тормознутым.
А сейчас это стало сильно заметнее, появились инструменты, которые делают все тоже самое, но быстрее в разы лучше и безопаснее.
Но нормальной замены для видеозвонков, объективно — нет. :/

НЛО прилетело и опубликовало эту надпись здесь

VEG 13 окт 2019 в 20:01

C# и TypeScript — хороши. GitHub после поглощения стал пока что только лучше. VS Code, не глядя на то, что работает на Electron, работает шустро. Ну и также не стоит забывать, что они также «прикасаются» и к куче других значимых вещей, принимают активное участие в разработке C++, например. Да и к Linux они прикасались, и не раз. Так что не надо =)

Skype да, не лучший пример. Для текстового IM перешёл в Telegram, Skype остался только для видеозвонков. Мобильный клиент у Skype слишком тяжёлый и тормозной для постоянного использования. Да и новый десктопный клиент тоже теперь задумчивый.

НЛО прилетело и опубликовало эту надпись здесь

AlexanderMarginal 13 окт 2019 в 23:11

Отсюда и "особый путь" у мягких

Mayurifag 14 окт 2019 в 04:49

Github Actions неплох, но, увы,

«We're working on caching packages and artifacts between workflow executions, we'll have it by mid-November.»

НЛО прилетело и опубликовало эту надпись здесь

Sly_tom_cat 13 окт 2019 в 03:16

Благодарю за критику, учту на будущее.

LuckyOok 13 окт 2019 в 07:48

Я, когда название увидел, думал, что будет что-то вроде этого: https://technix.github.io/instead-playground/

cerberus13 13 окт 2019 в 08:59

Пишите! Интересная статья, ещё бы подробнее о работе прямо в браузере :-)

DjSens 13 окт 2019 в 10:25

IDE как онлайн сервис, за абонентку, такое будущее нас ждёт…
Мне вот тоже надоело софт устанавливать и настраивать на разных рабочих местах, поэтому установил на одном компе и подключаюсь туда удаленно программы писать. Даже со смартфона, но с него неудобно — экран маленький, жду когда очки VR подешевеют

Shtucer 13 окт 2019 в 10:47

Eclipse Che
mbed.com
и наверное ещё 100500 online IDE уже здесь.

Naves 13 окт 2019 в 10:53

Внезапно вспомнилось.

Вы видели как конфиг граба строится?
Вы редактируете специальный файл, который управляет шаблонизатором и строит монструозный boot.cfg.
Lilo — один файл, и больше ничего.

habr.com/en/company/oleg-bunin/blog/458922

Sly_tom_cat 13 окт 2019 в 11:40

Ни Grub ни Lilo с UEFI в принципе не нужны. Возможностей диспетчера загрузки UEFI вполне достаточно для загрузки ОС без посредников.

Другое дело — настраивать диспетчер загрузки UEFI не так то просто и порой опасно (окирпичить совсем комп трудно, но восстанавливать потом тоже непросто).
И большая часть проблем тут обычно от кривой вендорской реализации UEFI.

Так что выкидывать загрузчики на свалку еще рановато.

FSA 13 окт 2019 в 18:18

Я тоже баловался загрузкой ядра через UEFI. Но потом забил на это дело, потому что Grub позволяет держать на разделе несколько ядер (как минимум новое и старое, которое точно работает). На у экономия 3 секунд на загрузку Grub… Так ли часто вы компьютер перезагружаете?

Sly_tom_cat 13 окт 2019 в 19:43

Ну у меня довольно старенький ноут — на нем немного больше 3 секунд экономии. Точных замеров не делал, но прирост скорости загрузки — ощутимый.

По поводу нескольких ядер — так и UEFI может загружать столько вариантов сколько вам надо. Конкретно в UEFI-Boot реализовано именно так: в пункты меню загрузчика UEFI добавляются записи для всех ядер, которые утилита находит в /boot. Более того за счет задания переменной UEFI BootOrder загрузка делается поэтапно — если со самым свежим ядром не загрузится то UEFI будет пытаться загружаться с предыдущим.

FSA 13 окт 2019 в 19:47

> Конкретно в UEFI-Boot реализовано именно так: в пункты меню загрузчика UEFI добавляются записи для всех ядер, которые утилита находит в /boot.

К сожалению, мой ноут находит только загрузчик со стандартным именем. Хотя, может быть я не знаю, как правильно называть ядра. По крайней мере, если батарейку отключить, что найдётся только
EFI/BOOT/BOOTX64.EFI.

Sly_tom_cat 13 окт 2019 в 20:04

Это сильно зависит от реализации UEFI для каждой конкретной модели и вендора. К сожалению старые UEFI прошивки были очень глючные.

EFI/BOOT/BOOTX64.EFI — это место расположения загрузчика, которое используется если не задано других опций загрузки в менеджере загрузки UEFI. И вам хотя бы в том повезло что отключение батарейки приводит к ожидаемым результатам.

Но вот если без эксцессов, то прописанные опции загрузки BOOTxxxx сначала перебираются в порядке заданном в BootOrder. А вот если их нет или по ним загрузка не удалась, то запускается режим recovery в котором первым делом производится попытка загрузиться из EFI/BOOT/BOOTX64.EFI.

А как прописывать разные ядра — можете посмотреть на гитхабе (смотрите ссылки в начале статьи).

FSA 13 окт 2019 в 21:52

Я об этом и говорю, чем плясать с бубном и надеяться, что твои записи не будут уничтожены случайным сбросом настроек, проще положить в EFI/BOOT/BOOTX64.EFI grub и пусть он уже рулит загрузкой. Кстати, нормально загрузить Windows 8.1 из Grub не получается. Иногда просто чего-то не находится, иногда грузится. Я не нашёл логики. Спасает, что можно Windows на отдельном винте держать и уже через меню загрузки BIOS грузить нужную систему.

caffeinum 13 окт 2019 в 12:22

Наверное, следующий шаг, это когда Travis запускает тесты прямо в браузере, чтоб не ждать 5 минут, пока он соберется на виртуалке, и быстрее разрабатывать?

Sly_tom_cat 13 окт 2019 в 14:17

CircleCI когда с виртуалок на докер образы перешли начали все проверять очень даже быстро — ни каких 5-и минутах речи нет — от силы 1, а иногда и быстрее.

TravisCI (когда я его пробовал) потому и не зашел, что тормозной до жути с этими своими виртуалками.

solver 13 окт 2019 в 14:21

Один я немного фоигел от того, что в мастер важной части ОС приняли наколенную поделку, автор которой не то что не особо разбирается в языке, но еще и пропихнул код чисто через CI, который многого просто не может проверить?

Sly_tom_cat 13 окт 2019 в 14:51

Ну наверно я не правильно сформулировал. На С у меня просто опыта мало и был он давно. Поэтом синтаксис его меня немного напрягает. И это выливается в то что после моих изменений С-код надо несколько раз прогонять через компилятор пока я там все нужные «знаки препинания» не расставлю.

А так то Code Review никто не отменял — я с таким посылом PR и создавал что бы мой код проверили и поправили если надо. Примерно так авторы и поступили.

Ну а вообще то это нормальная практика в Open Source принимать PR-ы от «энтузиастов».

НЛО прилетело и опубликовало эту надпись здесь

Sly_tom_cat 13 окт 2019 в 15:58

Не совсем так.

Как работает эта фича я руками проверил на нескольких прошивках UEFI.

Спеки UEFI я изучал достаточно детально. И добавленный код полностью соответствует спецификации UEFI.

Сбоку из мастера я таки сделал и проверил — то что я делал руками и то что работало — работает будучи сделанным и утилитой. Речь то про один бит в структуре загрузочной записи менеджера загрузки UEFI.

Да и код мой авторы проверили и подправили местами.

НЛО прилетело и опубликовало эту надпись здесь

Sly_tom_cat 13 окт 2019 в 17:39

Да, я подергал все места, которых касались мои «шаловливые ручки»: man страницы, парсинг входных параметров, проверка совместимости входных параметров, задание значения (не активно) по умолчанию и собственно обработку изменения LOAD_OPTION_FORCE_RECONNECT, которая управляется двумя новыми опциями -f и -F.

Так что (на сколько я могу судить), ничего сломать мне не удалось.

Да и опыт добавления своего функционала в чужой код у меня есть. Конкретно в этом PR вместо того что бы пытаться совместить обработку двух опций (LOAD_OPTION_ACTIVE и LOAD_OPTION_FORCE_RECONNECT) в одой функции я таки сделал копию функции от LOAD_OPTION_ACTIVE и переправил ее на LOAD_OPTION_FORCE_RECONNECT — это тоже не самый лучший паттерн, но в плане добавления функционала такой копи-паст страхует от ненужного вмешательства в работающий код. Позже, если кто-то захочет это место привести к одной общей функции — ну вельком.

Sly_tom_cat 13 окт 2019 в 15:09

— Del

-1

НЛО прилетело и опубликовало эту надпись здесь

Lexicon 13 окт 2019 в 15:57

Я бы как минимум изменил заголовок, ибо ожидал прочесть статью совершенно другого вида.
Не говоря о том, что итог статьи, опять же, не связан с тезисом заголовка.

P.S.