Ads
Comments 39
0
Уточню, если сидишь под Linux, то VirtualBox нужен ради безопасности для kubernetes?
0
Чтобы запустить kubernetes (Minikube, если быть совсем точным) желательно использовать гипервизор, иначе Minikube будет запускать свои компоненты прямо на хост-машине. Это требует установки устаревших (менее безопасных) пакетов Docker, которые сам Docker уже не рекомендует к установке.
Установка гипервизора — Virtualbox или KVM — требует добавления кастомных репозиториев, реконфигурации или вообще отключения Secure boot, возможны конфликты по версиям пакетов. Например, после установки пакета virtualbox-6.0 и последующего обновления через apt-get, я больше не смог его больше запустить из-за конфликтов версий пакетов.
В статье формулировку поправил, она действительно была непонятная, спасибо.
0
вообще отключения Secure boot, возможны конфликты по версиям пакетов.

Нет.


Достаточно просто добавить сгенерировать и добавить свои ключи, а затем подписывать ими модули KVM или VirtualBox.


Ноже самое с версиями пакетов — "из каробки" есть репозитории для всех актуальных версий всех популярных дистрибутивов и конфликтов при этом точно не возникает.

0
Вы рекомендуете на девелоперскую машину устанавливать kubernetes без VirtualBox/KVM?
У вас на машине kubernetes без виртуализации?
+3

Я предлагаю не распространять неверную информацию "требует… или вообще отключения Secure boot, возможны конфликты по версиям пакетов".


Вовсе не хочется обвинять автора, он просто неопытен и набил шишек. Но распространять такой нечаянный FUD не следует.

+2
Погуглил еще — вы правы, спасибо за наводку. Статью поправил.
0
А если использовать гипервизор, то Minikube установит устаревшие пакеты уже в виртуальную машину?
+5
Также занимаюсь разработкой под .NET в Kubuntu. Понравилось, что докер завел в полпинка в сравнении с виндой. VS Code конечно же проигрывает Visual Studio в качестве инструмента под .NET. Перешел на Rider, благо он работает под Linux, плюс быстрее, чем решарпер.
+1
Перешел на Rider, благо он работает под Linux, плюс быстрее, чем решарпер.

Прошу прощения, а как вы решаете проблему лицензии? Покупаете? Или ломаете? Мне что-то совесть не даёт пользоваться ломаным продуктом. А цена на него никак не радует. Поэтому под linux'ом использую VSCode. Хотя работу в ней удобной не назовёшь. Да ещё и OmniSharp приходится периодически перезапускать, т.к. в какие-то моменты он начинает подглюкивать.
+3

Тоже пользуюсь Rider+Resharper на винде (Rider в первом скрипте даже записан, но закомментирован как платный), лицензионными. Только что посчитал — один рабочий день с этими инструментами стоит мне 27 рублей. Как проезд в маршрутке или пачка жвачки. Имхо, это отличная цена за получаемые комфорт и продуктивность.

+1
Поэтому под linux'ом использую VSCode. Хотя работу в ней удобной не назовёшь

Странно: а по результатам недавнего опроса на StackOverflow больше половины разработчиков предпочитают именно VSCode

+1

В качестве альтернативы там из бесплатного только MonoDevelop, в котором для .NET Core не работает отладка. По желанию левой пятки M$FT.

+2

Rider себя окупит очень быстро даже для джунов (потому что научит много чему). VSCode и рядом не валялась. Не стоит экономить на рабочих инструментах.


Плюс, полученный опыт транслируется на все остальные продукты, если придётся работать с Python, Java, Go, PHP.

0

В любом случае VSCode будет быстрее и гибче развиваться как свободный продукт + в долгосрочной перспективе лучше ориентироваться на популярные инструменты.

+1
VS Code действительно быстро развивается, но как редактор общего назначения, годный для всего подряд, неспециализированный.

Любая «заточка» его под конкретные нужды (тот же C#) делается через расширения. Такая модель имеет ограничения, потому что правила игры определяет сам редактор кода и они должны оставаться универсальными, подходить всем плагинам.

Скорее всего, мы никогда не увидим такие возможности анализа, рефакторинга, автоисправлений, контекстных действий как в Rider и в той же Visual studio. А также штуки вроде дизайнеров DbContext-ов и прочие.

Полагаю, что все больше функционала будет перекочевывать в консоль. В dotnet CLI уже есть шаблоны проектов, работа с зависимостями, сборка, тесты, публикация, запуск — все через консоль вместо кнопок на UI.

И полноценным IDE в этих условиях всегда будет место и на них будет спрос. И, скорее всего, они так и будут платными именно за свою оптимальность и продуманность для конкретных задач.
0
в долгосрочной перспективе лучше ориентироваться на популярные инструменты

С такой логикой можно на JavaScript или Python перейти c дотнета, они ведь популярней :)

0

Отсутствие крупного игрока, который будет поддерживать и развивать стандарты в долгосрочной перспективе, сыграло с JavaScript злую шутку. Оказалось, что даже COBOL даёт более стабильное и выгодное трудоустройство :)

0

Поделитесь статистикой про COBOL в сравнении с Javascript. По моим источникам в случае со вторым трудоустройство вполне стабильное и выгодное.

+1

Я купил лицензию. И не пожалел. Удобство в разы повышается в сравнении VsCode+OmniSharp. Встроенный клиент клиент БД по сути тот же datagrip. Мне показалось что сам Rider быстрее чем Reshaper

+6
Спасибо за статью. По-моему одного маленького шажка не хватило — Ansible. Скрипты делают своё дело, но это инструмент прошлого тысячелетия (тогда софт был заметно проще, его было меньше, open source и коллаборация были на совершенно ином уровне), поддерживать чужой плейбук проще простого, а вот скрипт уже кому как.
0

Отличная мысль, спасибо) мне как-то в голову не пришло. Попробую как с ним заведётся.

0
А это вообще про то? Вроде же нет задачи менеджерить сеть из 10+ компьютеров, а просто настроить себе рабочую машину?
+1
А Ansible и не требует 10+ хостов. Зато иногда надо рабочую машину переустановить (новое железо например).
Установка чего-либо скриптом не гарантирует идемпотентности, а Ansible'ом гарантирует, поэтому имеет смысл предпочесть его.
0
Спасибо за статью, я даже не догадывался что .NET теперь не привязана только к винде
+1
Например, без гипервизора Minikube будет запускать свои компоненты прямо на хост-машине и потребует установки устаревших пакетов Docker
Например, в виртуалке тоже будут устаревшие пакеты Docker?
Есть snap-пакет microk8s от Canonical, да и в конце концов kubeadm init хватит всем (ну ладно, ещё поставить CNI и сделать ноду рабочей, документация).
+3
а можно общий вопрос? я понимаю зачим ЗАПУСКАТЬ дотнет на линуксе, но зачем РАЗРАБАТЫВАТЬ на нём же? в чём были плюсы ухода со знакомой платформы именно для разработки-дебага?
+3
Вы знаете, ответ на этот вопрос почти философский и сугубое имхо.

У меня за время работы в индустрии сложилась примерная такая картина:

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

Дальше активное развитие получил open source. И уже не просто библиотечки, а огромные инструменты. Те же Google и Netflix сделали гигантский вклад в инструменты continuous delivery. И множество сообществ объединилось вокруг этих инструментов. На мой взгляд, объединились уже все, а Microsoft-сообщество (не сам Microsoft, а его сообщество) стоит несколько в сторонке и за проприетарные инструменты держится: Visual Studio, Powershell, Azure DevOps, SQL Server, и, конечно, Windows.

Еще можно на Cloud Native Landscape посмотреть. В каждой категории множество инструментов, альтернатив. В большинстве бесплатное и open source Но, если отфильтровать по Microsoft, то останется совсем немного и все прямо или опосредовано (через Azure) платное. Я тут оговорюсь — я совершенно не против чтобы Microsoft зарабатывал, тем более что многие из его инструментов действительно отличные. Но один и платный инструмент, привязанный к экосистиеме — это ограничение. И сам же Microsoft все больше вливается в общий движняк. Linux уже не только в Azure живет, но и WSL прямо в Windows работает. А недавно Microsoft объявил, что Windows для них больше не стратегический продукт и его роль в бизнесе компании будет снижаться.

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

Второй момент заключается в том, что некоторые важные вещи на Linux просто лучше работают (контейнеры). Также нередко какая-нибудь open source библиотека (во фронтенд разработке спотыкался об это не раз и не два) полезная, хочешь фичу запилить. Но на windows ни собрать, ни тесты запустить не можешь. Потому что разработчики на Linux/Mac сидят и тулинг у них свой. А для тебя Linux это барьер.

И третий момент заключается в том, что выучить новый язык программирования, например, python или scala, чаще всего совсем нетрудно. На это нужно буквально пару недель. Ну ладно, чтобы неплохо освоиться — пара месяцев. Но вот ты узнал новый язык, он тебе понравился и это твое. Устраиваешься в классный стартап. Но Scala-то-Scala а работают там в линухах, на bash, глубоко знают весь тулинг. А с этим уже не так просто освоиться и быстро начать продуктивно работать. У меня вот вообще был такой эффект, что я в Rider первые месяцы не мог делать действительно сложные задачи. UI непривычный, цветовые схемы, шрифты — внимание постоянно на них отвлекается и я не могу работать на пике. Кастомные темы цветовые перебирал — без толку. Просто со временем привык, но это время понадобилось.

В общем, главный барьер это не язык, а тулинг. И я не вижу причин не перескочить этот барьер и не влиться в большое, единое, в основном бесплатное и open source сообщество да еще и повысить свою востребованность на рынке труда. Тем более что и Microsoft уже вовсю поддерживает Linux.

Сейчас у меня стоят параллельно Ubuntu и Windows и я спокойно осваиваюсь. Изначально старался работать в Ubuntu, если уперся в незнание — перескочил на винду и продуктивность по текущей работе не теряю. А нужные знания позже подтягиваю. На текущий момент на Ubuntu работать уже банально удобнее.
0

Вы сравнивали перформанс .Net приложения при запуске под Windows и Linux? С такой разницей надо или иметь кучу лишних денег или очень ценить, чтобы в качестве целевой платформы выбирать линукс.

+1

Мой комментарий про разработку, а не про конечный хостинг.
Но про перфоманс очень интересно. Можете поделиться ссылкой на сравнения? Я даже не в курсе, что с перфомансом .Net на Linux есть серьёзные проблемы.

0

Я сравнивал — разницы по скорости в CPU-bound задачах нет. В работе с диском выигрываeт Linux. Кучу лишних денег надо иметь на лицухи для винды.

0
У меня была задачка, микросервис выбирал из базы и крутил у себя в кеше, мог выдавать запрос.
Под виндой или линуксом разница в работе не ощущалась особо.
+2

Отвечу за себя — как и автор, перешёл на Ubuntu для разработки на .NET Core. Причины:


  • Скорость. Файловая система работает быстрее, отсюда Git намного быстрее, Rider / IDEA запускаются быстрее, итд
  • Другие языки и тулзы, с которыми приходится работать (docker, go, python, ..) зачастую лучше работают на линухе
  • Улучшение знаний ОС, работы в терминале, etc (да, есть WSL на винде, но полное погружение способствует изучению лучше)
+4

Спасибо за статью! Посыл очень верный, и попробовать переехать с винды стоит каждому.


Но, говоря справедливо, не всё так гладко:


  • Профайлеры. Ситуация печальная. Только сейчас в .NET Core 3.x появились инструменты от Microsoft (dotnet-trace, dotnet-dump), да и то, результаты лучше смотреть на винде в PerfView/VS. dotTrace от JetBrains пока что только в EAP и работает не для всех версий .NET
  • Conference tools (Zoom, Skype, ...) — что-то работает, что-то не очень
  • Нет многих других вещей типа LINQPad
  • Железо — тут лотерея и танцы с бубном, особенно с ноутами и с видяхами nvidia
+1
так и есть, думаю надо трезво оценивать усилия и время, затраченное на такой переход. А также пути компенсации за неизбежное снижение продуктивности.
UFO landed and left these words here
0
Но разве для ранчера не нужна чуть ли не 16.04 или вообще своя сборка ядро+докер? Что если мне хочется 19+ версию убунты (если честно, не уверен, зачем)?
UFO landed and left these words here
0

Это радует, а то на моей последней попытке падал старт etcd ноды под 18.04 и на форуме ответили дескать так и нужно.

Only those users with full accounts are able to leave comments.  , please.