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

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

Z>>Эээ... Стесняюсь спросить, сколько по вашему самый древний и слабый процессор,
Z>>допустим двухядерный Atom с частотой в 1ГГц сможет распарить пакетов из нескольких килобайт?
CC>Ты путаешь "сколько может" и как быстро наговнокоженное месиво из python, sh, grep, awk, whatever на самом деле работает.

И откуда это месиво взялось? gdb написан на С, те кто с ним общаются на C++(QtCreator)
или Java (NetBeans/CLion). sh/grep/awk могут быть в скриптах сборки,
но скрипты сборки на то и скрипты сборки, что выполняются во время сборки,
а не во время работы программы.

Z>>Если что, то VSCode более чем полностью на похожем принципе построена
CC>VSCode это лютое говно и вижуалкой не считается.

А где я утверждал что VSCode и Visual Studio одно и тоже?

A>Тебя просили словами объяснить. А ты не можешь.
A>Большинство линуксоидов с Виндой обычно знакомы.
A>И знают, что "удобно" — это не более, чем привычка, которая легко меняется.
Вот идешь в магазин покупать себе кресло, садишься в одно — удобно, садишься в другое — чтото не то. Вроде словами объяснить не можешь, но жопа упорно сигнализирует что неудобно, и привыкать не желает)
Тут тоже самое.

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

Pzz>Если в виде исходников
В виде бинаря и ТОЛЬКО бинаря. Никакой пользователь не будет ничего собирать.

Pzz>Но в общем и целом, меня волнует только судьба моего софта. Тот, что входит в состав дистрибутива, не моя забота его до ума доводить.
And it shows...

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

M>Где-то даже логично, если помнить, что корни vim растут из vi, еще в 70-х, работавшего на таких терминалах, где даже клавиш курсора не было.
Ну т.е. это палка копалка к которой синей изолентой прикрутили складной приклад.

Здравствуйте, Sheridan, Вы писали:
S>Нууу, я бы не стал рисковать на производстве, устанавливая пиратку.

чё? производство рухнет?

ты в какой стране живёшь? сказали вендекапец, значит вендекапец!

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

Pzz>>Если в виде исходников
CC>В виде бинаря и ТОЛЬКО бинаря.

В виде бинаря все, что нужно, есть в составе дистрибутива.

CC>Никакой пользователь не будет ничего собирать.

Я б поспорил...

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

A>Большинство линуксоидов с Виндой обычно знакомы.
A>И знают, что "удобно" — это не более, чем привычка, которая легко меняется.

Мне, например, в венде люто неудобно. В отличии от.

Аттракцион неслыханная щедрость: микрософт перестает брать деньги!

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

Pzz>В виде бинаря все, что нужно, есть в составе дистрибутива.
ЛОЛ!

Pzz>Я б поспорил...
Поспорь.
Вот именно что пользователи как раз ничего не пересобирают. У них даже компилера не установлен.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>QtCreator — своеобразный. Настройки — лютое шаманство.
Не преувеличивай.

SVZ>Но через какую-то задницу умеет читать CMake'и
Как часы работает.

SVZ>, может ли это новая MSVS — не знаю, не пробовал — не было нужды.
Может, с 2017 начиная.

SVZ>Кстати, сейчас тоже не доступен для скачивания и установки. Но работает, если утянуть установленную копию.
Даже не рассматривая 1.репозитории lin дистрибутивов и 2.vpn, исходники открыты:
https://github.com/qt-creator/qt-creator
собираешь и работаешь.

И, кстати, креатор меня абсолютно устраивает, после более чем 20 лет работы со студией, которая своей тормознутостью года так с 2015 откровенно задалбывать стала.
И с плюшками разными, типа автодополнения и навигации по коду, при включённом clangd и clang-tidy у креатора всё в порядке.

SVZ>Привычки, удобство.
SVZ>Юзабилити — великая вещь, маньякам-линуксистам сие неведомо
Ну да, ну да.

2Sheridan: по накопленному опыту все аргументы и нытьё тех коллег из моего окружения, которых переход win -> lin не устраивает, сводятся к одному — "здесь не так, как в винде". Всё.
Ничего, привыкнут.

CC>Вот именно что пользователи как раз ничего не пересобирают. У них даже компилера не установлен.
Пользователь может даже и не знать, что софт пересобрался, если система пакетирования сама установит компилятор и сборочные зависимости, соберет софт, а потом удалит компилятор и сборочные зависимости

ПС. Понятное дело, что без толстого канала и мощного компа такой подход не имеет права на жизнь.

CC>Напомни какова вероятность что софт, написанный под другой дистр, станет сразу, без допиливания, работать на другом?
Близкая к ста процентам, если "другой дистр" — это Арч.
Brave Browser под него, например, официально не выпускается, а установить без компиляции можно.

PS. В этот момент я, разумеется, немножко троллю и кривлю душой, ибо грубо наплевал на пункт "без допиливания", однако:

1. Почти для всего, что шевелится из мира Линукса, подобные порты (пкг-билды в терминологии Арча) уже написаны.

2. По сравнению с церемониальной ритуальностью апт-дистрибуции Арчевский подход тривиален, лаконичен, легко повторяем и адаптируем. Никаких вам Убунт над Дебианом и Минтов над Убунтами, все делается за считанные минуты и не требует развертывания монументальной инфраструктуры. Вот, например, тот самый допилочный скрипт для Брейва в 50 строчек: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=brave-bin

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

ZZ>если система пакетирования сама установит компилятор и сборочные зависимости, соберет софт
Вывалит тонну ошибок и ничего не соберёт.
Ну или собранное потом тупо не запустится.
Пусть уже тогда система пакетирования сразу ставит нужный дистр линуха

ZZ>ПС. Понятное дело, что без толстого канала и мощного компа такой подход не имеет права на жизнь.
Такой подход вообще не имеет права на жизнь.

CC>Вывалит тонну ошибок и ничего не соберёт.
CC>Ну или собранное потом тупо не запустится.
Не надо всех равнять по этому вашему кривоватому homebrew. Просто есть хорошие реализации концепции bsd-портов, а есть не очень хорошие.

CC>Такой подход вообще не имеет права на жизнь.
Ну да, ну да. Можно подумать полностью бинарная дистрибуция чего бы то ни было избавляет от проблем, равно как и дорого-бохатая проприетарность. Привожу пример из прошлогодней практики: этот ваш m1 mac mini застрял в bootloop. Причем не просто в bootloop, а в таком ядреном бутлуп бутлупыче, что и встроенный recovery-раздел с нескольких попыток не смог восстановить систему, падая на полпути, и Configurator 2 валился посреди дороги в процессе DFU-прошивки .ipsw по USB-шнурку! А неофициальный хацкерский idevicerestore из под линуха зашил и не поперхнулся.

PS. Доставив при этом лишь единственное неудобство: миник был в этот момент подключен по HDMI к телeвизору, на котором была выставлена высоченная громкость, и в процессе заливки ipsw этот самый миник на несколько секунд запулил по этому самому HDMI такие садистские аудиовизуальные помехи, что чуть меня не оглушил))) Но спустя пару минут завелся как новенький.

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

S>Ну в отношении линупса я тебе чётко могу сказать что мне нравится: возможность настроить систему так, как хочется именно мне, а не так,как придумала корпорация. Это — ключевое.

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

S>Второстепенное: мощная командная строка, большой выбор альтернатив, лёгкая разработка.

в винде есть тот же powershell, только это вещь опциональная, если нужно.
В линуксе без командной строки и дня не проживёшь.
Там где в винде в программе сделают окно настроек и ты просто галочку ставишь, в линуксе нормальным будет требовать от пользователя лезть в файл конфига и что-то прописывать или команду какую-то выполнять.
Лёгкая разработка и выбор альтернатив друг другу противоречат.
Как раз разработка усложняется тем, что на каждом компе свой зоопарк.

S>Что сможешь сказать про "удобство" студии?

Если брать C#, то какая альтернатива? Ну, код в чём-то можно написать, а Profiler? Только в Rider наверно и есть.
Если сравнивать просто как IDE, то из последнего своего опыта могу сравнить студию + C# + ASP .NET и Netbeans + Java + Spring Boot.
Студию установил, в ней же создал новый проект ASP .NET с нужными настройками, через NuGet добавил зависимости и всё прекрасно работает, собирается.
В Netbeans шаблона проекта для Spring Boot нет, нужно зайти на сайт и там сгенерировать
Я так понимаю, что разработчикам Spring Boot не интересно легко разрабатывать под большой выбор альтернатив IDE и проще у себя сайт-генератор намутить.
Сделал. Скачал проект. Не собирается. Пришлось гуглить и что-то там в конфиге Netbeans прописывать.
Стало собираться. Правда сборок через 5 он перестаёт это делать с непонятными ошибками. Перезапускаешь IDE — опять собирает.
Какие-то библиотеки подключить нужно — прописывай вручную в maven/gradle.
В итоге я опять полез в браузере открывать maven repository, чтобы там искать нужные библиотеки, смотреть как они подключаются и какая версия актуальна на сегодня.
Подозреваю, что всё это можно сделать через "мощную командную строку", но в студии это делается через дружелюбный GUI в 3 клика.
В итоге для кодинга VS Code оказался куда приятнее и в ней не было проблем с отваливающейся сборкой, просто периодически плагин Java отваливается, но это сильно реже происходит.
Со студией я с 6 версии работаю. Проблем хватает, но как-то в целом дружелюбно всё.
Со всеми этими Eclipse, Netbeans и т.п. лет 15 назад возился и плевался (на моём дохлом Celeron они уж очень неторопливо ворочались),
надеялся, что за эти годы что-то изменилось, но осталось всё так же медленно, криво, косо и нужно допиливать напильником.
По ощущениям, у них даже интерфейс не особо поменялся за эти годы.

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

CC>>Такой подход вообще не имеет права на жизнь.
ZZ>Ну да, ну да. Можно подумать полностью бинарная дистрибуция чего бы то ни было избавляет от проблем, равно как и дорого-бохатая проприетарность.
Не формат дистрибуции помогает уменьшить колво проблем а backward compatibility поддержка в ОС.
В линухах на неё забили большой и толстый, как в общем то и на совместимость между дистрами.

ZZ>встроенный recovery-раздел с нескольких попыток не смог восстановить систему, падая на полпути
Что то на диске похоже оказалось расхреначено. Без логов сложно сказать.

ZZ>Configurator 2 валился посреди дороги в процессе DFU-прошивки
Я хз насколько этот тул поддерживает DFU, мы для него пользуем совсем другие тулы и другие кабеля.
Чот мне кажется что версия тула скорее всего была не актуальная для заливаемой прошивки.

ZZ> по USB-шнурку! А неофициальный хацкерский idevicerestore из под линуха зашил и не поперхнулся.
И? Я этих прошивок уже залил больше чем ты в жизни воробьёв видел, все из под мака, никаких линухов

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

M>Не все так плохо конечно. Но это надо помнить или иметь листок с типовыми командами. В принципе кто часто работает запоминает.

M>Где-то даже логично, если помнить, что корни vim растут из vi, еще в 70-х, работавшего на таких терминалах, где даже клавиш курсора не было.


О чем и речь. Надо держать листок с типовыми командами.
А упомянутый мною xedit этого не требовал. Я до сих пор помню, что выход из него делался по F3, а выход с сохранением по F4. На ЕС ЭВМ это было вполне логично, еслм приняит во внимание расположение функциональных коавиш. И когда xedit портировали на PC, все оставили, как было. Но кого не устраивает, можно переопределить.
И, повторю, листок с командами не нужен для него. Пальцы сами все запоминают. И ноги у xedit растут от edit, который появился в те же 70-е.

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

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

M>>Где-то даже логично, если помнить, что корни vim растут из vi, еще в 70-х, работавшего на таких терминалах, где даже клавиш курсора не было.
CC>Ну т.е. это палка копалка к которой синей изолентой прикрутили складной приклад.

Не, это вполне нормальный редактор, просто у него необычная сейчас парадигма с разделением на командный и текстовый режим. У такого разделения есть свои плюсы и минусы. Плюсы — что очень легко внутренние и внешние скрипты навешивать. https://rus-linux.net/MyLDP/BOOKS/Vim/prosto-o-vim-15.html и с помощью них делать довольно нетривиальные для других редакторов вещи.

Однако не все могут привыкнуть, я вот как-то несколько раз пытался использовать Vim, согласен, что это довольно крутая штука в принципе, но испорчен гуевыми редакторами Мне как-то ментально проще в Kate работать, он послабее будет, но там тоже можно подключить макросы-сценарии под названием сниппеты и т.д. https://rus-linux.net/MyLDP/BOOKS/Vim/prosto-o-vim-15.html

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

CC>Вот именно что пользователи как раз ничего не пересобирают. У них даже компилера не установлен.

Зависит от мотивации Например, для какого-то процента программирование вообще началось с ковыряния в любимых игрушках, написания к ним модов и т.д.

CC>Не формат дистрибуции помогает уменьшить колво проблем а backward compatibility поддержка в ОС.
Поконкретнее пожалуйста. Что именно имеется в виду? ABI ядра? Тряхомудия с версиями libc? Или что-то еще? Если второе, то избавление от этой проблемы элементарное. Если первое, то да, увы и ой. Но оно случается только в мажорных релизах. И да, можно подумать в макоси не отваливается старый добрый крутой софт. После того, как вы прекратили поддержку великолепного, прямо-таки знакового Aperture, и через несколько версий он перестал нормально работать и отвалился, вас всех хорошо бы полным составом в отпуск в талибскую деревню отправить, или куда там сейчас еще актуально? В Нигер какой-нибудь ))

CC>В линухах на неё забили большой и толстый, как в общем то и на совместимость между дистрами.
Про совместимость расскажи-ка лучше разрабам Xcode'а, которые поднимают требование к мажорной версии макоси настолько часто и настолько ни с хрена, просто потому что так захотелось, что складывается впечатление, что они это делают для того, чтобы новые маки чаще покупали...

ZZ>>встроенный recovery-раздел с нескольких попыток не смог восстановить систему, падая на полпути
CC>Что то на диске похоже оказалось расхреначено. Без логов сложно сказать.
Определенно. Но да, что именно — уже не представляется возможным узнать.

ZZ>>Configurator 2 валился посреди дороги в процессе DFU-прошивки
CC>Я хз насколько этот тул поддерживает DFU, мы для него пользуем совсем другие тулы и другие кабеля.
CC>Чот мне кажется что версия тула скорее всего была не актуальная для заливаемой прошивки.
Конфигуратор был на тот момент свежайший. Проблема возникала скорее всего не в нем самом, а ниже. Печально известные "номерные ошибки", которые часто проявляются и при прошивке телефонов.

CC>И? Я этих прошивок уже залил больше чем ты в жизни воробьёв видел, все из под мака, никаких линухов
Ответ из серии "у меня такая же нога, и не болит".