Pull to refresh

Comments 28

Это примерно как Kali Linux - можно собрать все под себя, а можно поставить дистрибутив где уже собрали ))

Ну и без MS VS

Весьма, интересное применение докера! Надо будет замутить для себя образ с настройками редакторов под конкретные цели...

Конечно, все самое ценное лежало в архивах, но вот рабочая среда...

Можно расширить область того, что считается ценным и начать бекапить избранные файлы и папки "~/.name".

А еще можно сделать `git init .` в домашнем каталоге и получить бесплатное версионирование избранных файлов и папок.

и начать с /

Потому что /etc/*, /usr/lib/*, и т.д.
Или сделать сразу дамп рабочей станции, о чем и была речь ))

Гит для этого плохо подходит, особенно когда будет идти речь про большие файлы. Себе настроил snapper (поверх файловой системы btrfs). Точно не помню, но по умолчанию хранится 10 ежемесячных/10 ежедневных/10 ежечасных бекапов.

Меня сильно покоробило:

sudo vim /etc/group

docker:x:121:my_username

Вы уж если не особо образованных людей просвещаете, что посоветовали? Добавить строчку? Отредактировать строчку? Что в этом случае будет? А с кривыми ручками пользователя, работающего по инструкции?

Человечьим языком - добавить своего пользователя в группу докера и будет хорошо, но это делается через usermod, а никак не прямым редактированием groups

но это делается через usermod

это делется примерно десятью плюс-минус PI разными методами.
догматики и зубрилы должны страдать.
"не особо образованные люди" тоже должны страдать.

не, ну товарищ прав -- что за 121? кривая магия. на убунте это avahi вообще)..

Вообще-то предполагается что юзер найдет строчку с ключевым словом docker и проставит там себя как члена группы.
Без вписывания цифры 121 вместо оригинальной (я просил 400 капель, а здесь 402!!)

usermod примерно это и делает, только с дополнительными телодвижениями.

Велосипед, который вы придумали, называется Devcontainers. И он уже вполне стандартный.

Теория - https://habr.com/ru/articles/814071/

Практика - https://habr.com/ru/articles/734062/

Спецификация - https://containers.dev/

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

Cобирать девконтейнеры можно не только на VS Code / VSCodium, для JetBrains уже тоже есть. Если сильно хочется собрать такое на Vim, гугл показывает статьи и реддит с решениями на NeoVim, выглядит рабочим. Хотя я бы рекомендовал не сходить с ума, просто взять VSCodium, обвешать плагинами и включить хоткеи из вима. Знакомые вимеры говорят, что почти то же самое.

Я не продаю решение, не предлагаю новый велосипед, я просто написал об использовании технологии которую применяю сам примерно лет 7+, чтобы не соврать (когда там у меня диск посыпался?). Эт во-первых.

А во вторых - я описываю именно сам подход.
Это не обязательно должно быть программирование на c++, не обязательно связанное с какой-то организацией, компанией или консорциумом.
Это может быть, например, "разработка сайтов на PHP", где у разработчика настроена среда со всеми нужными зависимостями, или работа с каким-то хитромудрым фреймворком, который абсолютно так же точно может быть установлен в контейнере, или программирование девайсов с установкой специфических тулчейнов.

И это может сделать буквально любой на коленке, опять же не обращаясь к компаниям, организациям и консорциумам.
Взять и сделать как удобно самому. Это просто, не надо гуглить решения, принцип одинаковый.

А предложение заменить удобный МНЕ инструмент на какие-то мутные VS-чего-то-там, или хотя бы просто по похожий на названию NeoVim, потому что где-то _написано что оно должно работать_ почти так же, да еще "обвешивать плагинами" - ну, это и есть тот самый подход "поставить IDE покруче и посовременнее", от которого я ушел давно и целенаправленно ))

Не нужны там лишние плагины. Лучше mc ими обвешать: этот файл редактируем, этот компилируем, этот заливаем через репозитарий на тест, а этот через USB в прошивку.

На волне популяризации докера шутили, что "скоро vim будем из докера запускать". Прошло N лет...

Теперь давайте прокинем в docker образ X-11 сервер, и будет вообще конфетка

а вот это уже излишество: Х-сервер работает с железом, ему не надо в контейнере сидеть, т.к. именно железо тут и может меняться.
Разве что Xvnc какой-нибудь или Xrdp...

Wayland или X11 , причем тут железо.. даже с wsl через x11 прокидывали в те времена пока МС не сделала все проще. Xvnc rdp абсолютно не удобны для разработки. Запаритесь экраны переключать, особенно если машина разработки может содержать только софт для разработки, без почты, мессенджер и тп..

X-сервер - это та часть системы, где стоит монитор с видеокартой, вот причем тут железо. Как правило вы за ним сидите, на рабочей станции.
Кроме случаев где "монитор" виртуальный, те же vnc или rdp.

А то, что к нему подключается, прикладной софт, даже если он крутится на сервере - это X-клиенты. Почему все это путают постоянно?

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

Вот переключать экраны как раз удобно ))

Одних только виртуалок сколько уже напридумывали ...

  1. export XDG_CONFIG_HOME=$HOME/.config

  2. cd $XDG_CONFIG_HOME

  3. git init; git add .; git commit -m 'all my configs'; git push

  4. PROFIT

А если серьезно, то метод с контейнером конечно тоже неплох, но не исключает предварительного провижена новой машины. Имхо лучше или прям конкретно заморочиться с flakes для nix или не заморачиваться вообще и просто как в шутке выше xdg_config_home в репозиторий положить

Просто надо конфиги под энвы отдельно в репозитории хранить. Задумка хорошая, но я вот сталкивался с тем что через некоторое время шаг в сторону приводит к пересборке, гаданию где и чего еще надо напильником доработать. Как итог - я просто не использую винду, а свои конфиги под ансибл,вим и zsh я храню в гите. Под zsh до недавнего времени использовал только те параметры, для которых не надо ставить плагины и расширения.

Sign up to leave a comment.

Articles