Comments 162
Теперь имею дуал лоад. Винду оставил на всякий случай( пока не всё умею делать под линухом)
(говорят слишком много подводных камней при паралельной установке винды и линукса)
всё же интересно, что же там за камни? не раз ставил параллельно. работают.
Но я не включал его постоянно, только когда нужно было какие-то документы с раздела Linux достать.
В те далекие времена, также, исследовал какие ФС читаются обеими ОС и можно использовать для обмена. Список был удручающе мал: нативно поддерживаются FAT32 и UDF, еще через FUSE можно подключить NTFS и exFAT. Сейчас поддержку exFAT добавили в ядро, можно использовать его.
На данный момент использую драйвер WinBtrfs, т.к. Proton от Steam использует симлинки и просто так игры, расположенные на NTFS/exFAT, запустить под линуксом не удалось. Но последнее время думаю о том, чтобы снести винду полностью, а освободившееся место использовать под BCache.
- разный формат времени
- если не выключить fastboot в винде (по-умолчанию вкл) то линукс не сможет корректно работать с ntfs разделами и монтирует их только для чтения.
- разница файловых систем рождает лулзы, хотя делати вспомнить не могу
- мразотные драйвера Nvidia. Я немало провел времени подстраивая цвета в панели управления nvidia т.к. цвета в винде и линуксе были разные настолько что с установками по умолчанию разглядеть некоторые цвета было невозможно. Т.е. если настройками монитора получаю нормальный цвет в линуске, то в винде его не видно или он желтит/краснит. Удовлетворительного результата добился только заменой Nvidia на AMD. Хотя думаю это мне так повезло и это скорее исключение.
Это ограничение windows, а не ntfs. Из-под линукса/мака на разделе с ntfs замечательно создаются и работают файлы с практически любыми символами в именах (очень удобно хранить электронные книги с полным именем издания в качестве имени файла). Но вот когда потом под windows пытаешься открыть файл вида "QNX_UNIX: анатомия параллелизма.pdf" — эти ограничения вылезают.
arxont@potex /run/media/arxont/0C6C0A526C0A36CC $ echo "ZZZZ" > "?"
bash: ?: Недопустимый аргумент
arxont@potex /run/media/arxont/0C6C0A526C0A36CC $ echo "ZZZZ" > "*"
bash: *: Недопустимый аргумент
arxont@potex /run/media/arxont/0C6C0A526C0A36CC $ cd ~
arxont@potex ~ $ echo "ZZZZ" > "*"
arxont@potex ~ $ echo "ZZZZ" > "?"
первое — ntfs, второе — ext4
Зависит от *nix, видимо. На маке я могу писать звёздочки и вопросики, но не могу двоеточия. На убунте (сейчас попробовать не могу, нет под рукой) двоеточия, насколько помню, можно.
Ну и вишенкой на торте остаются разные "магические" имена вроде prn, lpt1 и т.д., которые винда по старинке считает именами спец. устройств и приходит в замешательство, когда сталкивается с файлами с именно такими именами, но на диске. Это тоже, очевидно, ограничения ОС, а не ФС.
bash: ?: Недопустимый аргумент
bash: *: Недопустимый аргумент
Экранирование? Не, не слышал :)
echo 1234 > \*Отрабатывает без ошибок. Главное теперь не забыть экранировать при удалении
Второй пункт — бесит. Особенно, когда нужно по-быстрому, что-то скопировать на системный раздел. Выручают несистемные диски.
С третьим пока не сталкивался или просто не особо пользовался «общими» данными. Возможно, что основная система у меня Linux. А Windows — вспомогательная, своего рода замена wine.
А четвёртый — я просто предпочитаю AMD. Ни разу не брал Nvidia, поэтому не могу сказать как они ведут себя.
Говоря о том, что не сталкивался с подводными камнями, я имел в виду не их взаимодействие, а о том, что они без особых проблем ставятся на одну машину и живут своей жизнью.
Нет. С опенсорсными драйверами Intel и AMD, в линуксе всё более чем хорошо. В отличие от проприетарных (ибо, из-за закрытых спеков, опенсорсные нвидия дрова неюзабельны чуть более чем полностью) дров Nvidia, вокруг которых приходится постоянно плясать. Особенно плохо владельцам ноутбуков с двумя видеокартами. Вообщем не зря Nvidia многие называют её ненавидия.
Ни разу не слышал о подводных камнях в линукс-системах. Вот в дистрибутивах — возможно. Кстати, можно установить виртуалку на линукс, кто уверенно хочет использовать её, но и винду жалко оставлять без внимания)
Так что если вы разрабатываете под win, то и не стоит ничего менять.
Linux, в то же время, даёт нам и разумный набор слоёв абстракции, применимых в ситуациях, когда прямой доступ к чему либо или ручное написание некоего кода может вылиться в больший объём работы, чем тот, к которому готов программист. Много удобных инструментов можно найти в Qt и Java, есть целые стеки вспомогательных технологий, вроде Pulse Audio, Pipewire и gstreamer. Linux стремится к тому, чтобы её пользователи могли бы заниматься программированием, и не скрывает этого.
При чем тут Linux? JVM может быть установлена на любой (практически) платформе. Qt — мультиплатформенный фреймворк…
из них одна доступна только через конду, второй в конде нет…
Делаем в конде два окружения. Ставим самой кондой, что она может, а чего в конде нет — через pip (не забыв, конечно, активировать окружение сперва). Да, не совсем удобно, но по крайней мере работает.
Я вам расскажу почему так происходит.
Основная масса тулчейнов писалась под линукс. И эти "упоротые" товарищи только декларируют портируемость, но не следуют ей.
Поэтому часто их (тулчейнов) использование под вин требует дополнительных танцев с бубнами.
Так что я в свое время, когда повзрослел и танцы надоели — для работы пересел на линукс. Он, конечно, говно по юзабилити, но мне нужно работу делать.
Хочешь ставь двоичные образы любой версии, хочешь — качай исходники и собирай.
От питона бог миловал, так что ничего не скажу.
Статья, написанная ИИ.
Практически во всех случаях, за исключением каких-то совсем уж экзотических, код, чтобы стать полноценной программой, обращается к заголовочным файлам и использует внешние библиотеки. Это происходит на всех платформах, но Linux подталкивает программиста к тому, чтобы он сам бы во всём этом разобрался, а не доверял бы заботу обо всём этом исключительно инструментам разработчика для некоей платформы.Но ведь это актуально только для «старых» языков, без нормальной системы сборки и управления зависимостями. Сегодня и Rust и Go сами разруливают все связи и сборку.
Много лет пользуюсь IDE от JetBrains под Ubuntu, с особыми проблемами не сталкивался. Если какие-то комбинации клавиш сталкиваются с комбинациями графического окружения (при использовании floating-окружений типа Gnome, KDE, Cinnamon — с i3wm вообще не помню таких проблем), то проблема решается элементарно переназначением клавиш либо IDE, либо окружения.
Первое — отличная документация. MSDN и пачка связанных SDK — это просто охрененная вещь. Хотите написать драйвер? Без проблем, вас научат пошагово, покажут кучу примеров и даже намекнут на подводные камни. Вас интересует создание мультимедийных приложений? А может, работа с 3D-графикой посредством DirectX? Всё будет показано и разжёвано, описание всех функций находится на расстоянии двух кликов мышью, и вся информация собрана в одном месте.
В случае Linux вы будете, проклиная всё на свете, собирать информацию по крупицам со 100500 ресурсов, форумов и новостных групп, а потом ещё и актуализировать её, потому что значительная её часть, конечно же, давно устарела. И грабли все положенные будете собирать своим собственным хребтом, потому что никто даже не намекнёт, что вот это вот — deprecated и в следующей версии библиотеки уже будет убрано, а вот это только для отладочных целей и сильно просаживает производительность всей системы.
Можно считать, что по сравнению с виндой у Linux-программистов документации вообще нет. Есть какой-то полуфабрикат, на основе которого вы путём кропотливых исследований шаг за шагом накапливаете в вашем блокнотике актуальные доки по вашей проблеме.
Второе — это отличная совместимость на уровне софта. Если вы хотите не только программировать, но и распространять напрограммированное без раскрытия исходников, то под Linux у вас возникнут существенные сложности. Фактически, вам придётся взять на себя работу майнтейнера, раз за разом пересобирая ваш софт хотя бы для самых популярных дистрибутивов.
Мало того, Linux-софт требует постоянной поддержки. Он очень быстро протухает и перестаёт запускаться на новых версиях системы. Вы не можете просто написать один раз, зарелизить и забыть на 15 лет, вам придётся постоянно тратить ваше время, просто чтобы оно не перестало работать. Это чудовищная и совершенно непроизводительная растрата ценного времени, которому можно найти лучшее применение.
Есть какой-то полуфабрикат, на основе которого вы путём кропотливых исследований шаг за шагом накапливаете в вашем блокнотике актуальные доки по вашей проблеме.
Сейчас пишу PCI драйвер на linux и не могу передать словами как вы правы. Mailing листы состоят на половину из статей 2003-2007 года, на вторую половину из простых патчей. Очень много структур и функций с похожим функционалом. Release notes только грепать, нормальное summary там просто невозможно увидеть.
С этой стороны, какое-нибудь системное linux приложение поставляемое в исходных кодах просто кладезь стабильности.
Что касается совместимости, то тут проблема, скорее, связана с зависимостями. Частично решается статической сборкой (когда это возможно, конечно).
Но проблема с зависимостями есть и под Windows. Проявляется всплывающим сообщением об отсутствующем dll/ocx/vxd и пр. Особенно для специализированного софта. И тогда приходится бегать по сайтам и искать их. А одну ошибку с .NET пока так и не удалось подправить — пакет элементарно не ставится на ОС.
От линуха бог миловал, но сейчас работаю под AS/400 (IBM i) — доки от IBM (Knowlege Center) на порядок хуже MSDN. И написаны кривым языком и с примерами так себе. Правда, и система посложнее винды и линуха вместе взятых…
Камень преткновения был Altera MAX 10 FPGA.
Под Linux Quartus 15/16/17/18 — через JTAG только мог конфигурировать FPGA, а вот при попытке прошить проект во внутренню flash-память (CFM/UFM), Programmer вис и по таймауту давал ошибку. Приходилось ходить к Windows машине и там перепрошивать MAX10.
Надо будет проверить, как там новый Intel Quartus, может уже починили.
С добавлением нового семейства мк в разработку все просто: нужен компилятор+либы, а ide остается старая, давно освоенная. Иногда нужны просто либы.
ide для плис (altera|xilinx|lattice) под лин нативные.
jtag отладчики работают. Хотя им пользуюсь редко.
Разрабатывать/отлаживать интерфейсы связи с помощью rpi/python — очень удобно. Практически любая тестовая последовательность на кончиках пальцев.
Да и шить зоопарк мк/пзу предпочитаю опять же через rpi.
Что еще нужно то?
Про поведение проприетарных продуктов, не соответствующих документации, боюсь вспоминать.
Смотря с какой стороны смотреть :)
Про документацию — есть много разных проектов, у каких-то документация хорошая, у каких-то не очень, бывает ведь и лучше, чем для винды.
Про совместимость бинарей — ну, Neverwinter Nights для Linux 2003 года у меня совсем недавно перестала работать из-за того, что в моем случае iglx сломали в xf86-video-intel, с modesetting работает. Вы же можете, как и в винде делают, тащить с собой часть библиотек нужной версии и так далее.
Про дистрибутивы — чушь собачья. В стародавние времена линуксовые версии софта распространялись без оглядки на конкретный дистрибутив, обычно в архиве со скриптом-инсталлятором, клавшим все в /opt. Есть люди, которые запускают линуксовые версии разного древнего софта ради ностальгии и тому подобного.
В стародавние времена линуксовые версии софта распространялись без оглядки на конкретный дистрибутив, обычно в архиве со скриптом-инсталлятором, клавшим все в /opt.
А ничего по сути и не поменялось ). Только вместо /opt теперь всё чаще /var/lib/docker или /snap если на десктопе ).
Вот недавно вычистил все поставленное через flatpak, подумал, что Zoom можно и в веб-версии пользоваться.
Тоже так думал.
Но в течение уже второго крупного апргейда (16 на 18, теперь на 20) вижу, что все программы, установленные снапами, этих апгрейдов вообще не заметили. Просто работают, как раньше. Те же скайп, зум и другое. А вот с другими каждый раз приходится возиться…
Это отличный способ "заморозить" программу, чтоб не протухла. Естественно, с учётом сторонних издержек (лишние копии файлов и т.д.)
Обоснуйте.
Zoom прекрасно раздаётся под все возможные дистрибутивы, нативными пакетами, прямо с сайта производителя.
Он очень быстро протухает и перестаёт запускаться на новых версиях системы. Вы не можете просто написать один раз, зарелизить и забыть на 15 лет, вам придётся постоянно тратить ваше время, просто чтобы оно не перестало работать
Уже 3 года пытаюсь убедить коллег использовать ip вместо ifconfig. Ведь его последний релиз произошёл в 2001-м году
1. У вас вызывает чувство удовольствия техническая сложность. Мозг радуется, когда вы в силах не задумываясь написать в консоли команду на пол-листа. Даже сам процесс установки, с выкачиванием зависимостей, компиляцией, многокилометровым полотном текста в консоли — радует глаз. Что, камера в Скайпе показывает перевернутое изображение? Сейчас загуглим, наверняка кто-то чинил. Вы чувствуете себя почти что Богом компьютера, в консоли вы можете всё.
2. Вам нужно поставить операционку несколькими кликами мыши, и чтобы всё работало. Не так: ВСЁ работало. Сразу и из коробки. Вы не хотите забивать голову командами, и вам приятнее визуальный интерфейс. У вас нет времени ковырять систему (ну, разве что отключить надоедающие автообновления), строчить команды на клавиатуре. И да, вы готовы заплатить за это, т.к. цените своё время. Для вас компьютер, программирование — это инструмент для реализации чего-то.
К сожалению, эти две альтернативы были возможны лет 10 назад. Сейчас уже не так. У меня, например, третий сценарий. Я готов порешать технически сложные проблемы, повозится в консоли и погуглить. И потом у меня будет рабочая система. Не буду говорить, что она идеально под меня и что она не глючит — это не так. И глючит иногда, и некоторые вещи сделаны не так, как мне нравится. Но она не выжирает дисковое пространство бесконечными обновлениями, не предлагает где-то зарегестрироваться и залогинится, не шумят вентилятором фоновые индексирование и антивирус… И еще куча подобных мелочей. Вот как-то так.
P. S. Подумал, что под ваш второй пункт MacOS еще пока подходит. Современная винда, имхо, немного тамагочи.
2. Вам нужно поставить операционку несколькими кликами мыши, и чтобы всё работало. Не так: ВСЁ работало.
P. S. Подумал, что под ваш второй пункт MacOS еще пока подходит. Современная винда, имхо, немного тамагочи.
А мне кажется под второй пункт не подходит ничего, MacOS уж тем более. А с выходом десятки и винда движется в противоположную сторону. Тут скорее вопрос в задачах, но ВСЁ не работает нигде. Серьёзные и нерешенные проблемы есть в любой экосистеме.
Мало того, Linux-софт требует постоянной поддержки. Он очень быстро протухает и перестаёт запускаться на новых версиях системы.
Обновил Mint с 19 на 20. И Mono Runtime уже не работает. Почему? А хрен его знает.
Вот что то про MSDN у меня другой опыт. Поиск находит только сишарп, а я на нем не пишу. Ищешь функцию винапи-он все равно шарповую находит. Както смотрел как мне написать драйвер usb устройства — самый простой вариант был "возьми libusb" и хотя звучит стремно- работает без проблем (да еще и кросс-платформенно). Вчера ставил TeamCity агента как сервис- вылезла ошибка, по коду ошибки на МСДН стало ясно что то-ли количество бананов в холодильнике не достаточно, толи папуасы новой гвинеи танцуют не в ту сторону. Оказалось что винде не нравится запускать сервис от имени пользователя без пароля.
MSDN в целом весьма хорош.
Но часто ускользает разница между MSDN и спец. разделами вроде platform sdk, которые тоже выдают результат в то же окошко поиска.
Ну и встречаются порой забавные накладки, вроде справки по poll (который есть на линуксах) — оно вроде пытается его имитировать, и даже копирует доку. Но вдруг оказывается, что по докам, к примеру, деактивация записи — это поставить её со знаком "минус" (типо было 10 — поставил -10 — и вроде как и число сохранил, и оно больше неактивно), а по факту тип идентификатора под виндой — беззнаковый. Упс...
В случае Linux вы будете, проклиная всё на свете, собирать информацию по крупицам со 100500 ресурсов, форумов и новостных групп, а потом ещё и актуализировать её, потому что значительная её часть, конечно же, давно устарелая может что то упускаю, но в случае линукса у вас весь исходный код драйвера перед глазами. Более того через git вы можете отследить что, как и когда менялось. Разве это не лучшая документация для программиста? А что в случае windows?
Мало того, Linux-софт требует постоянной поддержки. Он очень быстро протухает и перестаёт запускаться на новых версиях системы. Вы не можете просто написать один раз, зарелизить и забыть на 15 лет, вам придётся постоянно тратить ваше время, просто чтобы оно не перестало работатьзависит от способа сборки бинарника. Так то и под windows если приложение требует условно .net 2.X, вы не запустите его на ос которая поддерживает только .net 1.x. Вам напомнить как они directx урезали на 7ке, а перед этим на XP?
я может что то упускаю, но в случае линукса у вас весь исходный код драйвера перед глазами. Более того через git вы можете отследить что, как и когда менялось.
Это не совсем так. В случае с драйверами, есть много с закрытым кодом и без документации. Если для какого-то устройства, всё же, есть драйвера в открытом доступе, то разбирать чужой код ещё то удовольствие. У каждого свой стиль и свои навыки. Разобрать код, конечно же, можно, но сколько это потребует времени — это вопрос.
Это не совсем так. В случае с драйверами, есть много с закрытым кодом и без документации.Неужели под windows эти самые драйвера доступны ввиде исходников? Под linux я имел ввиду вот эти исходники
У каждого свой стиль и свои навыки. Разобрать код, конечно же, можно, но сколько это потребует времени — это вопрос.а что под windows у всех один стиль написания драйверов?
Если нужно написать свой драйвер под определённое устройство (необязательно своё), то тут нужно искать в сети все документы и описание и эти данные не всегда есть или не всегда актуальные.
Что касается разбора исходного кода, то там мало зависит от ОС или языка.
Под Windows, признаюсь, драйверов делать не приходилось. Даже не знаю есть ли какие API или документации для этого.
Seth Kenlon is a UNIX geek, free culture advocate, independent multimedia artist, and D&D nerd.
Автор статьи не является «программистом». Все что он описывает касается «автоматизации», «написания несложных скриптов». Его аргументы не имеют никакого отношения к «программной инженерии», «разработке программного обеспечения (под какие бы то ни было платформы)».
Если вы занимаетесь чем-то (например мультимедиа), и любите автоматизацию — эта статья для вас, присмотритесь к Linux. Если вы хотите заниматься «программированием» (разработкой программного обеспечения) — проходите мимо.
Если вы хотите заниматься «программированием» (разработкой программного обеспечения) — проходите мимо.
Оу, спасибо за ваши аргументы, конечно же вы меня сразу убедили! (нет)
Да ну, статья как статья. Кроме того что снова разжигает бессмысленный холивар на пустом месте — ничего особенного. Копирайтеры в очередной раз вытащили из интернета случайную статью и перевели, но всем надо показать что его любимый фломастер зеленее.
"7 причин почему я ношу синюю пижаму по средам дома" — и каждый норовит возразить что лучше красную, по четвергам и не пижаму, а в кино ходить.
Ну нравится логи читать в консоли — да пожалуйста. Нравится код писать в Linux — пусть пишет!
Хотел детально натыкать автора носом в то, где он пишет чушь, но это же споры с копипастой. Автор смешивает в одну кучу разработку ПО и написание скриптов для обработки десятка документов, а я начну докапываться, что системы управления зависимостями во всех ОС работают примерно одинаково, мавены-градлы там, ну смешно.
А под Виндовос как-то подругому? Разве что без полотенца лога и даже нет ключевых слов для погуглить.
Вообще, плюсы есть и там и там, линукс действительно требует задрачивать настройку и вечно красноглазить — но в последние годы он постабильней.
Не знаю, я тупо ставлю linux mint и работаю, без красноглазия.
Но да, работать вполне нормально что в windows что в ubuntu если привыкнуть к соответствующей ide. Но вот такие проблемы в обычных вещах — не делают Linux лучше windows для разработки ПО… Мелкие косяки, с которым мне приходилось сталкиваться во время разработки в новой ide и программными продуктами, бесили до жути. При этом за 4 месяца с покупки ноута на Windows и использованием там VS 2019 + mysql(разработка серверной части и десктопного приложения) проблем не было от слова совсем. Включил, установил, работаешь.
микрофон живет своей жизнь — он сам себе увеличивает громкость
Было такое в скайпе, кажется, раньше. Лечилось снятием галки "automatically adjust microfone settings". Посмотрите в хроме или на уровне системы что-нибудь похожее.
оказалось виноват встроенный опенспорсный драйвер на видеокарту нвидиа.
пробовали устанавливать пропиетарный-оригинальный драйвер от нвидиа? click
Mint при очередном обновлении угробил видеодрайвер — началось адовое мерцание экрана — глаза покраснели сами по себе. Пришлось тащить драйвер с сайта amd и ставить ручками. А после этого и mint выкатил новую версию драйвера. Только теперь они конфликтуют при обновлении и любое обновление падает с ошибкой. Вполне себе линукс вей.
Уже довольно давно в линуксе нет текстовых логов (вернее они опциональны), а стандартное средство просмотра логов — journalctl.
Стандартный способ репорта об ошибках — stderr. Ну ещё вызов syslog. И туда направляется именно текст, может быть с какими-то вспомогательными метаданными (важность и т.д.). На этом всё, пули вылетели!
Куда оно пойдёт и где осядет дальше, и какой тулзой вы будете всё это просматривать — это уже не задача приложения, чем и обеспечивается гибкость.
не в виде терминального окна с вырвиглазными огромными белыми буквами на черном фоне с терминальным же шрифтомЦвета и шрифт можно менять как вздумается. Хотите чёрный по белому с Comic Sans — пожалуйста.
Использование текстового редактора для просмотра логов- ужасно, это прошлый век.Ну используйте графический, если вам текстовый не нравится для просмотра текстов. Мне Gnome при падении какой-нибудь программы выдаёт вполне себе графическое окошко с кнопочками, даже предлагает багрепорт создать.
дальше текстового лога не ушлиА что может быть «вместо»? бинарный? systemd уже, вроде, давно в бинарном пишет, приходится journalctl использовать вместо любого из текстовых инструментов.
А в целом, если я всё правильно понял, вы не прониклись Unix-стилем, когда каждая программа делает что-то одно, но хорошо, с вытекающими пайпами.
> tail, head, grep, awk, sort
а в procmon достаточно кликнуть на фильтр и указать интересующее слово. Например, имя файла процесса. Потом кликнуть на кнопку включения мониторинга. Когда надо выключаешь. И интересующая тебя информация перед глазами. Причем этот мониторинг на уровне операционной системы. Я уж не говорю про мощную службу журналирования Windows.
С программой, которая не ведет логи придется поступать так же как и в Виндовс — смотреть на сисколы, например, strace. Им же можно цепляться и к работающему процессу. С ini файлом, думаю, что проблемы будут и у вас, разве что вы не про реестр говорите. Реестр — не ini файл. И так ли хорош подход реестра — отдельная тема для холиваров.
Возможностей фильтрации и агрегации логов в командной строке больше чем в UI.
В подавляющем большинстве эти возможности не востребованы. Достаточно того, что обеспечивает UI. Это экономит массу времени и требует минимум усилий для освоения инструмента. Мало того, в отличие от командной строки, UI обеспечивает выбор доступных рабочих вариантов и ограничивает количество ошибочных. Командная строка всегда следствие отсутствия адекватных инвестиций в ПО, за что платит своим временем пользователь. Серьезные коммерческие продукты с командной строкой не делают.
Про strace уже сказали. А как вам возможность повесить хук на вызов и завершение любой функции с чтением аргументов/возвращаемого значения? Как возможность в любой момент (без перекомпиляции) загрузить в ядро программу, которая будет выполнять какие-то действия в ответ на определённые события? И такую программу можно воткнуть практически в любое место любой другой программы, не перезапуская её или так же, "на горячую", в любое место ядра.
Вообще-то если программа НЕ ВЕДЁТ логи, с ней сложно что-то существенное делать под любой ОС. Отследить, какие файлы открывает и системные вызовы делает — да, но обычно не более того. Но надо понимать, что в обоих случаях это некие сторонние тулзы (руссинович под виндой, strace/bpftrace под линуксом). И в обоих случаях это "мониторинг на уровне файловой системы". Ну и про мощную службу журналирования говорить не стОит, покуда — ну, так же она есть и под никсами. Т.е. возражение в целом непонятно; чем одно "качественно лучше" другого? На обоих системах можно как работать с логами (если приложение их ведёт), так и анализировать поведение профилировщиками/трейсерами.
Вместо того, чтобы задавать дурацкие вопросы, наберите в гугле «process monitor». Может, оцените качество проработки интерфейса этой утилиты по сравнению с любой терминальной программой. Я не собираюсь заявлять, что эта утилита панацея, но свои задачи она выполняет прекрасно и пользоваться ей удобно.
Я вполне нормально работаю с линуксом как пользователь, в том числе на работе у меня заведена небольшая виртуалка с линуксом для «личных», не относящихся к работе дел. Одно время даже пытался дома полностью перейти, просидел где-то полгода и вернулся на винду. Хотя почти для всего софта подобрал аналоги. Да, мелкие баги и недоделки тоже раздражают, но главное — именно из-за отсутствия Студии, в том числе ее отладчика.
Qt Creator неплох, но он далеко не идеален. Родные линуксовые IDE… даже не знаю. Как-то помню, давно это было, запустил KDevelop, куда-то щелкнул — и он упал. В общем вот так.
Главная причина, почему я НЕ сижу на Linux — отсутствие там среды разработки уровня Visual Studio.
Есть прекрасные IDE от JetBrains.
А VS идеальна?
Все мои попытки завести PyCharm и CLion оказались безуспешны
А можно подробнее? У меня на Ubuntu нормально работают IDEA, PyCharm, PhpStorm. CLion когда-то тоже запускал, правда, давно.
Большой проект:
- несколько сотен файлов на смеси python, c++ и автогенерация из protobuf,
- необходимость собирать и редактировать на удаленной машинке
- есть всякие извращения вроде подгрузки модулей из билд директорий
- несколько нестандартная настройка linter-а для обоих языков
- scons в качестве билдсистемы
В "идее" (тут я пробовал вроде clion с плагином для питона, может стоит наоборот) все равномерно красное и лаг в несколько секунд при попытке редактировать.
Visual Studio Code сложно сравнивать с CLion. Первая — продвинутый текстовый редактор со свистелками. Вторая — именно IDE.
Так-то да. Причём не просто в текстовый редактор, а весьма тормозной. Если не использовать его возможности как IDE, то смысла особого в нём нет. Разве что ради работы с vcs. Но тут, думаю, проблема больше не в нём как таковом, а в том, что он не умеет со скунсом. Я сам ради этого перетащил один проект на cmake, уж очень хотелось в нём комфортно шариться (и, кстати, перетащилось достаточно "линейно", даже с тестами. В смысле, не рокет-сайенс, а достаточно механическое переписывание кода с питона на cmake).
У Visual Studio есть несколько киллер-фич:
Современная Visual Studio Community бесплатна, причём даже для коммерческого использования. При этом Community-версия полнофункциональна и лишена только фич, которые востребованы в кровавом энтерпрайзе. А вот у Rider нет бесплатной лицензии. Да, ничто не мешает пользоваться EAP-версиями или каждый месяц сбрасывать триал, но это немного извращение.
Visual Studio поддерживает полноценную работу с несколькими языками одновременно. Например, можно одновременно разрабатывать библиотеку на C++ и графический интерфейс на C#, который эту библиотеку использует. Также возможна одновременная отладка кода на C++ и C#. А вот с JetBrains такой фокус не прокатывает: вы отдельно пишете C++-библиотеку в CLion и отдельно интерфейс в Rider.
Отладка кода в Visual Studio, с моей точки зрения, сделана намного лучше. Например, Expression Evaluation в студии удобнее.
IDE от JetBrains не тот уровень?
Меня удовлетворяет качество их продукции. Тем более с одной лицензией я могу запускать их средства разработки как на Windows, так и на Linux.
Есть один пунктик к С/С++ — система сборки. CLion отлично работает, даёт кучу свистелок, подсветку синтаксиса и т.д., когда весь проект в целом собирается с помощью cmake. А если там autotools, скунс или вообще голый баш-скрипт или мейкфайл — увы. Что-то с мёртвой точки в этом направлении стало сдвигаться лишь в последний год-полтора.
Ну и помимо этого есть особенности в производительности. Студия, скажем так, гооораздо шустрее, особенно на больших файлах. Но зато clion не изобретает велосипедов и использует для анализа стоковый clangd, который тоже умеет очень многое.
Да, инструменты рефакторинга кода пока слабо развиты, но как минимум Go To Definition хорошо работает.
Ну кому что кому ехать а кому шашечки
У Линукса как и у всего в этом мире есть свои недостатки, как и свои плюсы по сравнению с альтернативами. Поэтому и все эти холивары будут бесконечными. Уже то хорошо, что у нас есть альтернатива, было-бы печально жить в мире, в котором есть только одна Винда.
Что касается Windows,… Хотите написать драйвер? Без проблем, вас научат пошагово, покажут кучу примеров и даже намекнут на подводные камни.
Так вот ты какой, северный олень писатель драйверов для Windows...
А также прекрасно работают пакетные инструменты Adobe, которые под Linux не взлетят.
Открытость кода рабочих программ тоже никак не связана с операционкой.
И там и там есть разные типы софта.
При чём тут Linux?
А программировать это в принципе удовольствие )) Независимо от среды.
Привет вам из 1996 года когда еще в DOS RAM-диск был.
Зато в линуксе добавил одну строчку в настройках(в винде еще надо танцы с отдельными прогами) и диск сам подключается.
На линукс 300 мб оперативки под систему, остальная память для работы.
Без GUI — да, памяти немного ест. А вот в GNOME у меня Firefox и SublimeText выедают примерно 5-7 Гб на двоих.
Винда меня поражает не запросами к памяти, а вот требованию к дискам — сколько ни дай — все мало. Отвел 100Гб на диск C: — папка Windows растет и растет. :(
Захотел поставить VisualStudio — попросило 3Гб и еще каких-то дополнений накачало на хз сколько.
Это я еще в игры не играю...
Среда разработки под андроид есть не только под винду.
Ну, тут каждому своё, я полагаю. Поэтому, нельзя однозначно сказать какая ОС лучше. Нужно попробовать и решить для себя.
Как вы думаете, на какой ОС работает веб-сайт, на котором вы оставили свой комментарий?
Ну и на какой же, по вашему мнению?
Лень долго искать, взял первые релевантные результаты из гугла по поиску "habr статистика ос":
https://habr.com/ru/post/357646/ — 2016 год, "… статистика со Stack Overflow"
https://habr.com/ru/post/243183/ — 2014 год, "Под какой ОС и на чем вы программируете?"
Android?
Как вам там в 2000 году?
В 2021, если вы собираетесь делать коммерческое приложение, вам надо будет выбрать, писать сначала под веб или под мобилки. Если выберете мобилки, то надо определится, будет ли первым Андроид или iOS.
Потом уже речь пойдет про десктоп — под Windows, где много неплатежоспособных, или под Мак, где пользователей мало, но они любят покупать.
И где-то тут появится светлая мысль покрыть максимальное количество платформ, написав ваш софт на электроне.
И вот так мы получили тот софт, который имеем сейчас ...
Ну логика понятна теперь. "Я пишу на 1С, мне удобнее Windows, значит все должны сидеть под Windows?". Океу.
2) Пора наконец признать, что 1С нужен только в РФ и СНГ, а всякие JavaScript/PHP/C++/Java и т.д. — во всём мире Если уж вам так дорого программирование под всякими ERP и прочим, перейдите на ABAP и получайте ещё больше в SAPе.
5 причин, по которым я люблю программировать в Linux