Ломка виндовозника при соприкосновении с линуксом

Уверен? Хорошо, скажи как. Буду пользоваться. А еще интересно, как к нему прикрутить Emacs-подобные хоткеи и Zsh-подобное дополнение

Все в $PATH - это хорошо.

Точно также «хорошо» как и ставить все программы и библиотеки в windows/system32

Не зря же существует /opt.

Существует, а толку то? Репозитории, включая сторонние, всё равно гадят по всему /usr.

А для пользователя удобно, чтобы все в $PATH было

Для пользователя важно удобство запуска. С path это никак не связано.

Документацию надо читать, мне это не нужно, я использую консоль как консоль, а гуй как гуй и их друг с другом не смешиваю. У меня даже в мыслях никогда не было запускать офис или браузер из консоли. В любом случае, powershell скрипт можно запустить откуда хочешь, в том числе и из zsh.

И это нормально, поскольку пакетный менеджер следит за каждым файлом. В случае использования же чего-то выходящего за рамки системного пм используется opt (Android sdk) или home (steam).

Связано. Это позволяет использовать шелл для запуска всего. И это очень удобно, например у меня при запуске okular идет фильтр дополнения по pdf & dejavu

это нормально, поскольку пакетный менеджер следит за каждым файлом.

А толку то, если в path могут оказаться два файла с одним и тем же именем?

В случае использования же чего-то выходящего за рамки системного пм используется opt (Android sdk) или home (steam).

Всё пользовательское ПО выходит за рамки системного.

Не удобно. Во-первых, имя исполняемого файла != имени приложения. Во-вторых, нет нормального поиска. В-третьих, надо использовать костыли, чтобы программу отвязать от терминала и перенаправить вывод. Консоль удобна только для консольных приложений и команд.

Я уже давно прекратил такие опусы читать. Как и перестал смеяться над их авторами. Глупо подходить со своим закостенелым мировоззрением к совершенно другой системе. Причем так же я перестал читать и повествования линуксоидов о винде. Чаще всего в тех проблемах виноват бывает подход, именно закостенелые мозги, которые не могут по-другому. Короче, мне не нравится такое.

А что не так-то? Ну да, настраивать линух впервые — занятие совсем не для слабонервных. Я вот на своём старом компе так и не сумел сделать так, чтобы иксовый экран не уезжал влево на сантиметр (на новом компе этой пакости вообще никогда не было).

Вот на виртуалках всё попроще. Но и там — пока сеть настроишь, помереть можно.

Какие такие костыли?

Как и перестал смеяться над их авторами.

Смеяться над неосиляторами не грех.

Все виндовые приложения сто лет как умеют принимать пути в формате Unix с прямыми слешами.

Рассказывай эти сказки тем, кто никогда в жизни не имел дела с виндой, ОК?

Майкрософт чинит 3rd party софт? Нет.

Микрософт обвешивает винду костылями вроде режимов совместимости, чтобы третьесторонний софт работал? Да.

Смеяться над неосиляторами не грех.

Если когда-нибудь будешь жаловаться на systemd, скастуй меня, я напомню тебе эти слова.

Ха! Я не жалуюсь на systemd. Она у меня пока работает (постучать по дереву).

nohup и т.п.

Она у меня пока работает

Все когда-то бывает впервые. Да и кроме systemd есть многое другое, что рано или поздно даст повод напомнить тебе о твоих словах.

К тому же, иногда имена именно приложений в винде не являются очевидными

Лол!

Вместо того чтобы разработчику собрать и выложить свою программу как во всех нормальных ОСях, в линуксе принято отдавать программу криворуким майнтейнерам,

Разработчики не хотят забивать голову такой ерундой как пакетирование. К каждому исходнику прилагается инструкция по сборке. А что и как там школо-мейнтейнеры собирают (хоть вдоль этой инструкции) - не их проблемы. Найдется нормальный сопровождающий, который и упакует по инструкции.

Майкрософт ведь не несёт ответственности за страданья пользователей по вине левого виндомастера Пети Петечкина. Тут всё также самое.

Найдется нормальный сопровождающий, который и упакует по инструкции.

Только почему-то реальности в каждом дистрибутиве (даже в помешанных на ванильности типа арча) даже «системные» пакеты обмазываются толстым слоем патчей, фиксящих различные моменты. И от дистрибутива к дистрибутиву наборы патчей разные.

Это так в инструкции прописано, или нормальных сопровождающих не существует?

Вообще всё пихать в path как в «ляликсе» это ущербная практика и источник глюков

Чушь несёшь.

Аргументы?

я уже привел, ты пропустил мимо ушей

Про пакетный менеджер, который следит за файлами? Этот «аргумент» смешен, тем более я его опроверг.

нет, про то, что разработчик ПО знает, нужна ли ему какая-то определенная версия чего-то из $PATH или же ему все равно

Примеры конфликтов/глюков в студию.

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

Не понял твоей мысли.

Я утверждаю, что а) если в /usr пишет только пакетный менеджер, то не может быть там два бинарника с одинаковым названием. По определению. б)Все в $PATH это хорошо, потому что из шелла вызывать удобно. Конечно, в некоторых случаях (когда не нужно подавать аргумент или я не знаю пути к файлу) - запуск через какой-нибудь семантический поиск вроде Spotlight выгоднее.

Но если я точно знаю путь к файлу, и что я хочу открыть - с консолью это тупо быстрее. У zsh дополнение позволяет мне указать что-то вроде ~/D///math/с и если таб нажать и у меня там в дропбоксе, скажем, есть папка combinatorics, он предложит мне такой вариант. Это ОЧЕНЬ быстро и удобно на практике - я могу открывать любой файл, к которому я примерно знаю путь (хотя бы одно точное название директории) с помощью того, чего я хочу. Быстрее семантического поиска. А теперь расскажи, как мне это реализовать в винде.

а) если в /usr пишет только пакетный менеджер, то не может быть там два бинарника с одинаковым названием.

С чего бы это? Как пакетный менеджер это гарантирует?

б)Все в $PATH это хорошо, потому что из шелла вызывать удобно.

Тебе удобно, пользователям не удобно, да еще и на стабильности сказывается.

А теперь расскажи, как мне это реализовать в винде.

Ты мыслишь от программы (даже от исполняемых файлов!), это не верно, пользователь не знает что такое программа (и тем более исполняемый файл), он работает с документами. Поэтому пользователю никогда не придет в голову вызывать программу с аргументом-файлом, он просто введет имя (не обязательно целиком) файла-документа в «пуске» и нажмет enter и у него всё будет.

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

да еще и на стабильности сказывается.

Как?

С чего бы это? Как пакетный менеджер это гарантирует?

Пакеты с одинаковыми программами, но разными версиями, либо конфликтуют, либо имеют разные имена исполняемых файлов, либо в дистрибутиве предусмотрен инструмент выбора версии по умолчанию, вроде eselect.

Как?

Прилетает бинарь или библиотека, которая уже имеется в системе, но чуть-чуть кривая. Например, Вася Пупкин в своем пакете мега-программы может положить свою сборочку gtk в /usr/local/lib, который обычно имеет приоритет выше чем /usr/lib и тоже имеется в ld_library_path.

Пакеты с одинаковыми программами, но разными версиями, либо конфликтуют, либо имеют разные имена исполняемых файлов, либо в дистрибутиве предусмотрен инструмент выбора версии по умолчанию, вроде eselect.

Если они лежат по разным путям, то как они будут конфликтовать?

Не пишет никто в пакетах в /usr/local/ - за это руки вырывают. Нигде такого нет! Такая ситуация невозможна.

Гипотетически, конечно, возможна. Но покажи мне хотя бы один пакет, в одном дистрибутиве, в официальных репозиториях или _одобренных_ репозиториях сообщества, который ТАК делает (вообще пишет в /usr/local/)

Не пишет никто в пакетах в /usr/local/ - за это руки вырывают.

Во-первых, пишут. Во-вторых, кроме /usr/local в path и ld_library_path много других директорий.

Нигде такого нет!

В официальных репозиториях нет (пока нет?), в сторонних эта ситуация типична.

Такая ситуация невозможна.

Тогда я еще раз повторю свой вопрос. Какой механизм обеспечивает эту невозможность?

в официальных репозиториях

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

_одобренных_ репозиториях сообщества

А это еще что такое? То есть если моя фирма собирает софт и выкладывает его в мои собственные репозитории, то я должен у кого-то одобрение получить? Если так, то как отличить одобренный репозиторий от неодобренного?

одобренные - это universe в убунте например, или community/extra в арче. Алсо, расскажите мне про хотя бы один пакетище, который пишет в /usr/local/. Хоть где-нибудь, от Oracle например... ну только не у третьеклассника Васи.

одобренные - это universe в убунте

Это не репозиторий сообщества, а часть официального репозитория. Отличие от main в отсутствии поддержки.

Алсо, расскажите мне про хотя бы один пакетище, который пишет в /usr/local/.

Никогда из ppa софт не ставил?

Хоть где-нибудь, от Oracle например...

От oracle и т.п. пишут в /opt/program_name и не прописываются в переменных окружения. Как раз по тем самым причинам о которых я говорю.

Так вот, я за то, чтобы система была отдельно, а софт отдельно. В окружении только системное окружение, софт никак на него не влияет и наоброт. Если пользователь хочет видеть сторонний софт в окружении, то он сам на свой страх и риск его туда прописывает. Это во-первых, повысило бы стабильность системы, во-вторых, упростило бы жизнь как пользователям так и разработчикам. К сожалению, механизма, который бы это обеспечил в линуксе нет, в линуксе принято котлеты есть вместе с мухами, в результате имеем то что имеем

За пять лет не встречал. Пользовался apt, aur.

Во-вторых, кроме /usr/local в path и ld_library_path много других директорий.

За LD_LIBRARY_PATH руки отрывать надо.

Нужен просто механизм для отделения мух от котлет, тогда и руки никому отрывать не придется.

Нет, предыдущий оратор просто псевдоэлитарный паникёр-пессимист. Всякого хватает, включая историй успеха линуксоидов.

И Вы правы )

Предлагали уже кучу вариантов и были попытки разделить и отделить пользовательский софт и системный и это верно IMHO... но появляется куча нытиков в СПО у которых шаблоны рвутся и часть тела предназначенная для стабильного положения индивида в пространстве... лет через 5 или 10 может или может «космонавт» осилит таки свои задумки, или тот кто якобы придумал пыш-пыш аудио вместе с создателем Гордена Фримена доведет таки линь до десктопа...