Здравствуйте, undo75, Вы писали:

U>а вообще? дурацкий такой вопрос.
U>как там с ide дела обстоят? печально?
U>вопрос не в "желательно", а "жизненно необходимо".

С IDE всё как везде. VS и Xcode по понятным причинам нет, остальные есть. Лично я пользуюсь Idea для Java и VScode для всего остального. Про C# не подскажу.

Если есть человек, который будет решать и настраивать твой линукс, то никаких жизненно необходимых знаний не нужно, разберёшься по ходу дела.

Если такого человека нет, то желательно иметь какие-то базовые знания по администрированию хотя бы своего локалхоста. Я сомневаюсь, что можно составить какой-то конкретный список, но в целом — уметь гуглить и с пониманием применять нагугленное.

От себя посоветую выучить sh. К линуксу напрямую это не относится, но жизнь упрощает во всех системах. Хотя вроде есть и товарищи, которые powershell используют, тоже вариант, если ты .NET разраб, тебе этот вариант может быть ближе.

Ещё могу дать такие абстрактные рекомендации:

1. Улавливать то, как разработчики планировали его кастомизацию. К примеру ты можешь править файл /etc/sysctl.conf, но вообще-то этот файл поставляется с определённым пакетом и если при очередном апдейте этот файл поменяется, тебе придётся тратить время на merge твоих изменений. Правильней создать файл /etc/sysctl.d/local.conf и править его. Причём эти моменты в интернете чаще всего не обозначаются, тут надо самому соображать. Чем меньше изменяешь то, что поставляется с дистрибутивом, тем меньше проблем у тебя будет при обновлениях. В systemd есть целая система override файлов специально для этого, к примеру.

2. Перед применением непонятных команд почитать маны. В интернете много советов, не совсем правильных. Или от недалёкости авторов, или от устаревания. Их можно, конечно, применять как есть, но лучше всего использовать их, как направление движения и перепроверить всё. В манах обычно актуальная информация. И вообще маны — наше всё.

3. Относиться с большим опасением к каким-то рандомным скриптам. Верный способ запороть свою систему — скачать какие-нибудь исходники и сделать sudo make install. Не весь софт можно найти в репозиториях, порой приходится ставить софт в обход, но с этим надо быть максимально осторожным. Очень много софта поставляется в виде просто одного бинарника. Такой софт можно скачать, скопировать этот бинарник в какой-нибудь ~/bin/ и бед не знать. Также ряд софтин поставляются в виде архивов, такой архив можно распаковать в какой-нибудь ~/apps/java-temurin-17/ и добавить ~/apps/java-temurin-17/bin в PATH. Это идеальный вариант. Если без сборки никак, я бы посоветовал собрать её в докере и попробовать использовать её в контейнере. В крайнем случае собрать её в контейнере, изучить как работает make install и потом просто скопировать бинарники из конейтенера в хост куда-нибудь в /opt. В общем держать весь левый максимально изолированно и под контролем. Если ты не можешь сделать rm -rf /opt/blaprog то у тебя проблема.

4. Некоторые дистрибутивные пакеты мне не нравятся. К примеру я жава девелопер и жаву всегда ставлю сам, несмотря на то, что она есть. Дело в том, что у дистрибутиводелателей очень странная манера. Разработчик жавы её даёт одним цельным архивом, они же этот архив раздербанивают на куски и делают из этого архива десяток пакетов, которые рассовывают содержимое архива по всем углам системы. Они художники, они так видят. Лично мне это кажется неправильным и ряд пакетов я всегда ставлю отдельно в виде бинарных архивов. В основном это всё, что относится непосредственно к разработке. Возможно с .NET будет похожая ситуация.