для .net разработчика. имхо .net core он и в африке такой.
а вообще? дурацкий такой вопрос.
как там с ide дела обстоят? печально?
вопрос не в "желательно", а "жизненно необходимо".
сам с линуксом дел не имел со времен ред хат и мандрейк
Здравствуйте, 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 будет похожая ситуация.
1) Нужно прочитать, как располагаются файлы на диске
FHS — File Hierarchy Standard
это важно, чтобы знать где работать и как
2) Нужно ознакомиться с работой пакетного менеджера выбранного дистрибутива
без этого тоже не обойтись, несмотря на существование nuget
3) программировать на C# придётся закончить,
так как нет процедуры бутстрапа компилятора. Он поставляется только как бинарник.
Переходите на Java, там с бутстрапом всё хорошо.
Здравствуйте, undo75, Вы писали:
U>для .net разработчика. имхо .net core он и в африке такой. U>а вообще? дурацкий такой вопрос. U>как там с ide дела обстоят? печально? U>вопрос не в "желательно", а "жизненно необходимо". U>сам с линуксом дел не имел со времен ред хат и мандрейк
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>3) программировать на C# придётся закончить, ЭФ>так как нет процедуры бутстрапа компилятора. Он поставляется только как бинарник. ЭФ>Переходите на Java, там с бутстрапом всё хорошо.
Ну была же тема на этот счет в dotnet в свое время. Опять за старое?
Здравствуйте, undo75, Вы писали:
U>для .net разработчика. имхо .net core он и в африке такой. U>а вообще? дурацкий такой вопрос. U>как там с ide дела обстоят? печально?
Jetbrains Rider под линупс работает, он теперь бесплатный для некоммерческого софта.
Здравствуйте, vsb, Вы писали:
vsb>3. Относиться с большим опасением к каким-то рандомным скриптам. Верный способ запороть свою систему — скачать какие-нибудь исходники и сделать sudo make install.
Здравствуйте, Stanislaw K, Вы писали:
SK>я как-то сделал uninstall пакета в ubuntu. этот пакет снес за компанию perl и ещё "половину системы" так удачно, что apt перестал работать.
Ну оно ж явно тебе писало, что сносит 100500 пакетов?
А что за пакет-то был?
Здравствуйте, netch80, Вы писали:
SK>>я как-то сделал uninstall пакета в ubuntu. этот пакет снес за компанию perl и ещё "половину системы" так удачно, что apt перестал работать.
N>Ну оно ж явно тебе писало, что сносит 100500 пакетов?
Ктож это читает? Кстати — нет. не писало. было написано что-то вроде "удаляю 1 пакет и 3 не используемых зависимости, будет освобождено 12 мегабайт дискового.."
в 2 зависимостях что-то было про perl, в том смысле что они евоные модули. (xmlformat-perl, perlmagick)
N>А что за пакет-то был?
Да я уж не помню. Не имеет значения. По сумме с предыдущими странностями был сделан Главный Вывод: никогда больше не использовать ubuntu. потому что ни redhat (centos, alma, rocky) ни debian такого себе не позволяют.
Нет никакого "make uninstall" в Linux. Поэтому придумали checkinstall, чтобы хоть как-то отследить, что куда пишется — по аналогии с виртуализаторами софта в винде. Также была попытка с chroot, но потом поняли, что у человеческой глупости пределов нет, поэтому придумали контейнеры и докер, чтобы изолировать раз и навсегда.
Здравствуйте, Stanislaw K, Вы писали:
SK>>>я как-то сделал uninstall пакета в ubuntu. этот пакет снес за компанию perl и ещё "половину системы" так удачно, что apt перестал работать. N>>Ну оно ж явно тебе писало, что сносит 100500 пакетов? SK>Ктож это читает? Кстати — нет. не писало. было написано что-то вроде "удаляю 1 пакет и 3 не используемых зависимости, будет освобождено 12 мегабайт дискового.."
А вот тут уже, извини, не верю. Если оно снесло "половину системы", то должно было как раз явно написать, что сносит половину системы (полный состав пакетов).
Скорее всего, ты жмякнул yes не заметив необычности.
SK>в 2 зависимостях что-то было про perl, в том смысле что они евоные модули. (xmlformat-perl, perlmagick)
N>>А что за пакет-то был?
SK>Да я уж не помню. Не имеет значения. По сумме с предыдущими странностями был сделан Главный Вывод: никогда больше не использовать ubuntu. потому что ни redhat (centos, alma, rocky) ни debian такого себе не позволяют.
Я использую одновременно и убунту с прочими дебианоидами, и редхатоиды.
Именно в плане показа что и как добавляют и сносят они одинаковы, различия нет.
Зато многие редхатоиды в принципе не позволяют адекватный апгрейд на следующую версию всего дистрибутива — особенно в последние лет пять, когда центось юридически отымели и превратили в ничто — поэтому больше склоняюсь в продуктине к дебианоидам. Разумеется, где можно.
Полагаю, тут опечатка, вы явно хотели написать "make uninstall".
F> Поэтому придумали checkinstall, чтобы хоть как-то отследить, что куда пишется — по аналогии с виртуализаторами софта в винде. Также была попытка с chroot, но потом поняли, что у человеческой глупости пределов нет, поэтому придумали контейнеры и докер, чтобы изолировать раз и навсегда.
Ну последнее я бы не формулировал так. От chroot до тех контейнеров, которыми рулит docker, podman, LXC и прочие, нет чёткой границы, это развитие фичами одного и того же пути.
If you're lucky, running make uninstall will work. It's up to the library's authors to provide that, however; some authors provide an uninstall target, others don't.
На самом деле я ещё ни разу не видел источника с uninstall. Интересно, где такие вообще штатно водятся. autotools точно не дают.
И даже если он будет работать в смысле просто удалить файлы — он не откатит результат перезаписывания чужих файлов, а обычный make install не проверяет такое.
N>А вот тут уже, извини, не верю. Если оно снесло "половину системы", то должно было как раз явно написать, что сносит половину системы (полный состав пакетов).
N>Скорее всего, ты жмякнул yes не заметив необычности.
Я и говорю — абсолютно недружелюбная к пользователю система.
N>Я использую одновременно и убунту с прочими дебианоидами, и редхатоиды.
Нет убедительных причин использовать странную убунту вместо дебиана.
Здравствуйте, Stanislaw K, Вы писали:
N>>А вот тут уже, извини, не верю. Если оно снесло "половину системы", то должно было как раз явно написать, что сносит половину системы (полный состав пакетов). N>>Скорее всего, ты жмякнул yes не заметив необычности. SK>Я и говорю — абсолютно недружелюбная к пользователю система.
Если ты жмёшь не попытавшись хотя бы наискось прочитать, что видишь, то дело не в системе, дело в тебе. Ты любую так угробишь, и винду даже быстрее и восстанавливать будет в разы сложнее.
N>>Я использую одновременно и убунту с прочими дебианоидами, и редхатоиды. SK>Нет убедительных причин использовать странную убунту вместо дебиана.
Какие бы ни были её свойства, не тебе судить — с такими грубейшими ошибками в управлении.
Здравствуйте, netch80, Вы писали:
N>>>А вот тут уже, извини, не верю. Если оно снесло "половину системы", то должно было как раз явно написать, что сносит половину системы (полный состав пакетов). N>>>Скорее всего, ты жмякнул yes не заметив необычности. SK>>Я и говорю — абсолютно недружелюбная к пользователю система.
N>Если ты жмёшь не попытавшись хотя бы наискось прочитать, что видишь, то дело не в системе, дело в тебе.
Это факт.
N>Ты любую так угробишь, и винду даже быстрее и восстанавливать будет в разы сложнее.
Но, однако, не всё так просто. убунта — единственная система с которой возникали внезапные сложности.
Здравствуйте, Stanislaw K, Вы писали:
N>>Ты любую так угробишь, и винду даже быстрее и восстанавливать будет в разы сложнее. SK>Но, однако, не всё так просто. убунта — единственная система с которой возникали внезапные сложности.
"Эффект не выжившего", в противоположность эффекту выжившего. Он же anecdotal evidence во всех формах.
Я и убунту ломал, и дебиан, и редхатоиды всех видов, и фряху. Вот опёнка и NetBSD не сломал, но это потому, что мало с ними возился вообще А коллега как-то замечательно сломал солярку, так, что пришлось к вендору на поклон бежать.
Но все случаи поломки были или тогда, когда не внял предупреждению ("ой, я установлю этот пакет... а что это такое, что он говорит, что вот эти снесёт взамен... да пофиг, проскочу... как это не загружаюсь???"), или когда пошёл таким путём, что предупреждать было нечему — например, менял один файл напрямую от рута.
apt-get очень подробно рассказывает, что делает. И dpkg рассказывает, что делает.
Самые большие проблемы растут у них от недодокументирования (включая случаи, когда авторы доки говорят на своём языке и считают, что все вокруг должны знать базу).
