O>>С ней ровно две проблемы — бинарники получаются жирные и апдейтятся только целиком.
CC>Ни одна из этих "проблем" уже очень давно не является проблемой от слова совсем.
ага, и потому придумали статическую линковку набора динамически слинкованных образов — инсталлер
а потом подумали и придумали динамическую линковку статической линковски набора динамически слинкованных образов — пакетный менеджер
а потом подумали и придумали статическую линковску динамической линковки статической линковски набора динамически слинкованных образов — LXC
а потом подумали и придумали динамическую линковку статической линковски динамической линковки статической линковски набора динамически слинкованных образов — докер
как видим, прогресс борьбы с DLL hell и в линуксе не стоит на месте

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

SVZ>А в Винде пока еще недостаточно распространено. Нужных пакетов не найти, поэтому пользоваться невозможно

OFF: вот он, предел инженерной мысли и эстетики всё остальное от лукавого

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

vsb>Не знаю, как устроен MSI. Но хорошая система пакетов лучше. Например в Linux пакет это архив с файлами, которые раскладываются по нужным каталогам. Таким образом менеджер пакетов всегда знает, какой файл к какому пакету относится, всегда знает, какие файлы нужно удалить, чтобы удалить пакет, легко можно проверить, какие файлы в системе были изменены (важно для аудитов безопасности). Т.е. это гораздо более структурировано, чем система, когда инсталлятор и деинсталлятор делают в системе что хотят и остаётся только надеяться на их хорошую работу.
А не нужно какашки по каталогам раскладывать, тогда и знать ничего не нужно будет.

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?

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

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?

Потому что overenginering и не осилили. Софт должен быть простым настолько, насколько это возможно. Но не проще.
Манагер пакетов он простой как пыль: список зависимостей, скрипты инициализации и пожалуй хватит. Ну можно ещо конфиги по умолчанию.
А не так как в винде
https://rsdn.org/forum/flame.comp/6297942

Автор: Нахлобуч
Дата: 03.01.16

https://rsdn.org/forum/flame.comp/5245011

Автор: Нахлобуч
Дата: 29.07.13

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

S>Потому что overenginering и не осилили. Софт должен быть простым настолько, насколько это возможно. Но не проще.
S>Манагер пакетов он простой как пыль: список зависимостей, скрипты инициализации и пожалуй хватит. Ну можно ещо конфиги по умолчанию.

Если уж на то пошло, то это тоже overengineering и боль, попробуй что-нибудь деплоить на кучу разных линуксов и познаешь ее сполна (зависеть от пакетов из пакетного менеджера ОС это работа, много работы), оптимальный вариант — делать standalone пакеты, которые запускаются везде, т.к. все включая libc слинковано статически, либо упаковывать в контейнеры и запускать(trollface jpg), желательно чтобы вообще было фиолетово, ставится твой пакет через yum или через apt-get, т.к. твой пакет ничего кроме твоего бинарника не содержит а секция Depends: в deb пакете отсутствует.

С точки зрения разработки зависеть от пакетного менеджера тоже говно а не жизнь, gcc/clang старые, все зависимости тоже древние и зависят от libc системной, так просто не впилишь статическую libc и тд. Идеальный вариант здесь, это монорепозиторий, в котором живут все зависимости, код приложения, скрипты для деплоя и CI и тд, и все вместе мейнтейнится и собирается единообразно. Это очень далеко от махрового linux-way но это то что используют большие компании вроде Google, FB и Yandex.

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

O>Менеджер пакетов удобен — единая точка входа и поиска нужных программ.

Для этого не нужен менеджер пакетов, для этого достаточно магазина.

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?

Потому что есть такой рефлекс: когда собаке делать нечего, она яйца лижет. Ну нечем занять школоту в мелкософте — на серьёзные проекты они ещё ламеры, а фигню всякую писать — только в путь! Заимствуют из Линукса то, что ТАМ работает, но является пятой ногой в Венде. Вот и вызывает недоумение их якобы "прогресс"!

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

P>А не нужно какашки по каталогам раскладывать, тогда и знать ничего не нужно будет.
Не используйте микрософт

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

K>Потому что есть такой рефлекс: когда собаке делать нечего, она яйца лижет. Ну нечем занять школоту в мелкософте — на серьёзные проекты они ещё ламеры, а фигню всякую писать — только в путь! Заимствуют из Линукса то, что ТАМ работает, но является пятой ногой в Венде. Вот и вызывает недоумение их якобы "прогресс"!

Я правильно понял твою мысль, что основные проблемы венды проистекают из того, что ее молодые разработчики не дотягиваются языком до яиц?

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?

Менеджеры пакетов не нужны. Концептуально это убогое говно, которое еще хуже бесконтрольных инсталляторов.

P.S. Кстати, кто-нибудь знает дистрибутив линукса БЕЗ менеджера пакетов? Для друга надо (с)

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

S>Правильно ли я понимаю что пункт "обновить у себя пакет до свежей версии" даже не рассматривается?
"Обновление как процесс самоудовлетворения"
Но боюсь, что это может быть близко скорее админам, но никак не программистам (разработчикам)

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

CK>С точки зрения разработки зависеть от пакетного менеджера тоже говно а не жизнь

Это не зависимость от пакетного менеджера, это зависимость от OS. Каждая версия каждого дистра-это отдельная OS. Нет ничего сложного поддерживать несколько дистров. Что касается зависимости от штатных пакетов версии дистра-это требование разработки под данную OS. Попытка затащить в софт какой-то чуждый дистру компонент-это пилить сук на котором сидишь, выстрелить может где угодно и как угодно. ПМ тут выстыпает в роли блокера.

Здравствуйте, Sheridan, Вы писали:
S>Не используйте микрософт
Так в Windows и не принято их раскладывать, в том числе потому и менеджеры пакетов не нужны.

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?

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

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

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

CK>извини конечно, но cmake, clang и gcc — это не часть ОС, а софт, который мне нужен для разработки, и если в моей ОС до сих пор gcc 5 я не смогу собрать свой софт, который зависит от seastar

Эти все компоненты линкуются не с libastral, а с огромной кучей других компонентов о существовании которых ты даже не подозреваешь. Так что своим желаением какого-то комфорта, чтоб всё было модно и молодёжно, тупо нарушаешь целостность системы, затаскивая чужеродный хлам. Если хочется модного и молодёжного можно юзать распоследнюю бубунту. А если пилится ынтерпрайзный софт под centos или sles, то будь добр юзать штатные gcc и пр.

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

S>Потому что overenginering и не осилили. Софт должен быть простым настолько, насколько это возможно. Но не проще.
S>Манагер пакетов он простой как пыль: список зависимостей, скрипты инициализации и пожалуй хватит.

Это называется DLL Hell, он же — "зоопарк несовместимых линухов".

Вроде бы, именно тебе лет 10 назад подробно объясняли, что тут не так, не? ))

Здравствуйте, vdimas, Вы писали:
...
V>Это называется DLL Hell, он же — "зоопарк несовместимых линухов".
+100500
Да, DLL Hell!
Только исторически — он пришёл из Windows
Так что сначала был — "зоопарк несовместимых виндоусов"

O>>Статической линковке 100 лет в обед. С ней ровно две проблемы — бинарники получаются жирные и апдейтятся только целиком. Потому 99 лет в обед как придумали динамическую линковку.
CK>за 15 лет программирования на С++ я что-то узнал про динамическую линковку, как не удивительно, и не утверждаю что она не нужна
CK>то о чем я пишу, касается не всего софта, а только критичного. для такого софта я хочу использовать новейший компилятор и стандартную библиотеку, последний стандарт, собирать и последним гцц и клэнгом и тд, то бишь пакетный менеджер ОС уже не может мне это дать
Я за 20 лет программирования на всем, что под руку подворачивается пришел к выводу, что линковка при билде не нужна. Вообще, никакая — ни статическая, ни динамическая.
Софт должен собой представлять здоровый объектник, символы которые ему нужны — должны идентифицироваться хэшом, линковска как таковая должна происходить в рантайме по этому хэшу. Пр необходимости можно подгружать нужные функции из облака или там блокчейна какого нить.
Бонусом получаем супер-мега рандомизацию адресного пространства.

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

S>>Тебе нужен Gentoo
P>В магазине десятки только Ubuntu, Debian, Kali, SUSE. Вроде ьы еще Федору видел. Генту не завезли. Но как только...
А, вы из этих, псевдолинуксоидов. Ну, которые "я линупс знаю, итд!" а на деле разве что wsl и пользуют и то исключительно потому что админы подсказали что там ssh удобнее putty.

Будь мужиком, ставь генту на железо! )))
Ну а винду, так и быть, можешь потом в виртуалке поселить.

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

S>Эти все компоненты линкуются не с libastral, а с огромной кучей других компонентов о существовании которых ты даже не подозреваешь. Так что своим желаением какого-то комфорта, чтоб всё было модно и молодёжно, тупо нарушаешь целостность системы, затаскивая чужеродный хлам. Если хочется модного и молодёжного можно юзать распоследнюю бубунту. А если пилится ынтерпрайзный софт под centos или sles, то будь добр юзать штатные gcc и пр.

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

там же обычно такая ситуация получается, есть софт, который билдится под несколько ОС, есть клиенты на последней убунте, а есть клиенты на RHEL 5, предлагаешь использовать наименьший общий знаменатель — RHEL 5 для разработки?

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

CK>ну вот смотри, есть такой язык программирования Go, он умеет собирать бинарник, который ни от чего не зависит и делает системные вызовы напрямую

и ты поверил?

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

V>А линуха застряли на т.н. "семантических версиях" из 90-х.

Ну вот эта проблема и решается успешно при помощи менеджеров пакетов.

А стыдиться здесь — в Linux нечего.
Просто полная демократия, нет единого управляющего центра.

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

V>Но в виндах решили вопрос через токены совместимости и основанную на ней технологию SxS.
V>А линуха застряли на т.н. "семантических версиях" из 90-х.
V>Стыдно должно быть...

Угу. Ну и фактически, каждая программа приходит с полным комплектом своих собственных пожитков.

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

CK>ну вот смотри, есть такой язык программирования Go, он умеет собирать бинарник, который ни от чего не зависит и делает системные вызовы напрямую
Статической линковке 100 лет в обед. С ней ровно две проблемы — бинарники получаются жирные и апдейтятся только целиком. Потому 99 лет в обед как придумали динамическую линковку.

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

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

Зависит от масштаба. Для среднестатистического localhost-а это не проблема, а когда тебе надо разложить гиговый бинарь на десяток тысяч серверов за разумное время или запустить его на устройстве с лимитированными ресурсами, начинаются интересные пляски.

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

ARK>P.S. Кстати, кто-нибудь знает дистрибутив линукса БЕЗ менеджера пакетов? Для друга надо (с)

LFS, Buildroot.

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

AG>Вот что мешает той же M$ сделать свой пакетный менеджер для продуктов на базе их (микросовтовских) технологий?

Они в десятке магазин сделали. Зачем еще что-то?
Если кому надо пакетный менеджер, можно установить из этого магазина Линукс (раньше была только Убунта, сейчас можно выбрать) и использовать его пакетный менеджер.

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?
Вообще ортогональные вещи.
Инсталлятор — это про способ превращения "система без компонента Х" в "систему с компонентом X". Есть множество разных подходов — от "всё сводится к копированию файлов" до "нам нужна возможность делать rollback произвольных скриптов, меняющих состояние системы".
Пакетный менеджер — это про зависимости: их проверка и разрешение (которое resolving, а не permission и не definition).
В MSI, к примеру, зависимости крайне убоги: да, можно сконфликтоваться с компонентом, можно потребовать компонент. Ну и всё — дальше, дорогой пользователь, #ись как хочешь.
В девяностые казалось, что ничего лучше уже не сделаешь: инсталлятор же не может волшебно всунуть в дисковод дискету с недостающим фрагментом. И даже если есть интернет — а если компонент платный?
Потому-то и появились пакетные менеджеры в линухах, что там проблема не в том, "как купить", а в том, откуда и что вытащить.

Зато это офигенно удобно в разработке — сдёрнул нужную тебе библиотеку, и она сама притащила за собой всё, что нужно.
После этого реальности начала 200х вспоминаются как страшный сон — отдал тебе заказчик исходник "почти готового проекта", и первую неделю ты ищешь способ его собрать — потому как каждая запчасть лежит в отдельном углу. Что-то — бесплатное, что-то — за деньги; что-то уже крякнутое. Что-то устарело с тех пор, как отцы-основатели притащили это в проект, и той версии нету уже даже на сайте производителя.

То же самое с любым "примером из интернета".

То ли дело сейчас — качнул проект, сделал dotnet restore — оп-ля! Он тебе стянул гигабайт добра и собрался. Лепота.

Комментарии в треде про магазины приложений — это вообще третья ортогональная ось: она не про зависимости и не про инсталляцию, а про discovery, пробы, принятие решений и оплату.
Магазин приложений может прекрасно работать безо всяких пакетных менеджеров и инсталляторов (к примеру, если каждый app идёт эдаким appliance, который тащит предварительно настроенную песочницу со всеми запчастями).
А может с ними взаимодействовать — особенно если инсталлятор умеет advertize, а менеджер пакетов умеет accept EULA, terms, and conditions.

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


S>>То ли дело сейчас — качнул проект, сделал dotnet restore — оп-ля! Он тебе стянул гигабайт добра и собрался. Лепота.
C>Вот только некоторые редиски берут и удаляют старые версии nuget библиотек с сайта.
C>Клиент просит патч, а собрать полугодовой билд уже корректно не получается — эта версия тянёт уже более новый компонент, так как версия, указанная в проекте, уже недоступна.

Правильно ли я понимаю что пункт "обновить у себя пакет до свежей версии" даже не рассматривается?

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?


Не знаю, что там в MS, давно не нюхал. Но если речь о пакетных менеджерах из мира free *NIX, кратко: в основном из-за опенсорса. В насквозь проприетарной системе, в которой каждый компонент анально огорожен от других, со всем своим носимым с собой, в которой объединение только на уровне системного API (или JVM или CLI — без разницы) (а ля корпорасты из 80х) — в такой системе пакеты не нужны, т.к. заведомо нельзя сделать что-то типа:

$ apt-get source ThatSuperMegaLib
$ <here we modify ThatSuperMegaLib and rebuild it for our needs>

или даже банальный:

$ apt-cache search SomeFile

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

ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?

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

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?

Отдельные самодостаточные инсталляторы это наследие доинтернетной эпохи.
Пакетные манагеры это их логичное развитие.

Правда кривоооое...
Взять, к примеру, LSB, без которого софт не запустить.
В убунте LSB ставится из пакета "lsb-core", а в Красношапке — из "redhat-lsb". И смотри, мля, не перепутай!
Типа стандарт, но из коробки оно не ставится ни там, ни там.

А в Винде пока еще недостаточно распространено. Нужных пакетов не найти, поэтому пользоваться невозможно

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

S>Не используйте микрософт

Дак заказчики на нем десятилетиями сидят. И нам приходится. А так я сидел бы на Полуоси, но IBM ее продавать не умела.

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

P>А так я сидел бы на Полуоси, но IBM ее продавать не умела.
Кто хочет, тот ищет возможности. У меня товарищ до сих пор под ecomstation софт пишет

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

S>Кто хочет, тот ищет возможности. У меня товарищ до сих пор под ecomstation софт пишет

Ты показывал как-то. Что-то в этом есть.
Но Винда за последние 25 лет подтянулась. Я не очень страдаю. Во времена Чикаги я сидел в 3.1 и Полуоси. А дальше я не стал изображать "я не такой, как все".

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

P>Здравствуйте, Sheridan, Вы писали:
S>>Не используйте микрософт
P>Так в Windows и не принято их раскладывать, в том числе потому и менеджеры пакетов не нужны.

C:\Windows\SxS, C:\Program Files, C:\ProgramData, %USERPROFILE%\AppData\Local, %USERPROFILE%\AppData\Roaming, Registry, Start Menu links, Desktop links. Это не принято?

Я бы ещё понял про макось такое (хотя и там мусора хватает).

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

S>Здравствуйте, chaotic-kotik, Вы писали:

CK>>С точки зрения разработки зависеть от пакетного менеджера тоже говно а не жизнь

S>Это не зависимость от пакетного менеджера, это зависимость от OS. Каждая версия каждого дистра-это отдельная OS. Нет ничего сложного поддерживать несколько дистров.

извини конечно, но cmake, clang и gcc — это не часть ОС, а софт, который мне нужен для разработки, и если в моей ОС до сих пор gcc 5 я не смогу собрать свой софт, который зависит от seastar

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

S>и ты поверил?

я проверил

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

V>>Это называется DLL Hell, он же — "зоопарк несовместимых линухов".
AG>+100500
AG>Да, DLL Hell!
AG>Только исторически — он пришёл из Windows

Но в виндах решили вопрос через токены совместимости и основанную на ней технологию SxS.
А линуха застряли на т.н. "семантических версиях" из 90-х.
Стыдно должно быть...

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

V>>А линуха застряли на т.н. "семантических версиях" из 90-х.
AG>Ну вот эта проблема и решается успешно при помощи менеджеров пакетов.

Если пакеты помечены только семантическими версиями, то не решается от слова никак.


AG>А стыдиться здесь — в Linux нечего.
AG>Просто полная демократия, нет единого управляющего центра.

Да пофик.
С тех пор как в Windows появилась технология SxS, в линухах продолжали возникать новые пакетные менеджеры.
А толку ноль.

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

SVZ>Отдельные самодостаточные инсталляторы это наследие доинтернетной эпохи.
SVZ>Пакетные манагеры это их логичное развитие.

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


SVZ>Правда кривоооое...
SVZ>Взять, к примеру, LSB, без которого софт не запустить.
SVZ>В убунте LSB ставится из пакета "lsb-core", а в Красношапке — из "redhat-lsb". И смотри, мля, не перепутай!
SVZ>Типа стандарт, но из коробки оно не ставится ни там, ни там.

У меня на Ubuntu 18.04:
sudo apt-get install lsb-core
— и всё здесь (без проблем)...


В чём кривость пакетных менеджеров? Вроде как всё отлично с ними.

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

AG>Открою секрет Полишинеля:
AG>Пакетные манагеры — умеют обновлять пакеты не только из интернета, но и с DVD-диска.

И чтобы воспользоваться этим потребуется погрузиться в чтение документации и набор магических команд в консоли.
Это не тебе не дважды кликнуть по иконке, тут интеллект нужен!

SVZ>>Правда кривоооое...
SVZ>>Взять, к примеру, LSB, без которого софт не запустить.
SVZ>>В убунте LSB ставится из пакета "lsb-core", а в Красношапке — из "redhat-lsb". И смотри, мля, не перепутай!
SVZ>>Типа стандарт, но из коробки оно не ставится ни там, ни там.

AG>У меня на Ubuntu 18.04:
AG>sudo apt-get install lsb-core
AG> — и всё здесь (без проблем)...
AG>

Да, всего-то нужно знать, что:
1. из коробки этот пакет не установлен
2. Если при запуске приложения получаешь сообщение "<filename> не является исполняемым ELF файлом", то нужно доставить пакет с LSB
3. Вообще знаешь о существовании этого клятого LSB
4. Знаешь, как называется пакет в твоём дистрибутиве. Потому что одни и те же пакеты на разных системах обзываются по-разному.

AG>В чём кривость пакетных менеджеров? Вроде как всё отлично с ними.

А в остальном, Прекрасная Маркиза, всё хорошо.

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

SVZ>2. Если при запуске приложения получаешь сообщение "<filename> не является исполняемым ELF файлом", то нужно доставить пакет с LSB
Какого приложения? Если приложение поставлено пакетным менеджером, то у него будет зависимость на LSB и он поставится автоматически. Если это не произошло, это бага в пакете приложения.

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

CK>>ну вот смотри, есть такой язык программирования Go, он умеет собирать бинарник, который ни от чего не зависит и делает системные вызовы напрямую

S>и ты поверил?

Я проверил.

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

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

O> Потому 99 лет в обед как придумали динамическую линковку.
И открыли такую гигантскую банку с червями что до сих пор оттуда обильно лезет.

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

CK>извини конечно, но cmake, clang и gcc — это не часть ОС, а софт, который мне нужен для разработки, и если в моей ОС до сих пор gcc 5 я не смогу собрать свой софт, который зависит от seastar

Прошу прощения за оффтопик, а зачем вам Seastar? Это та самая Seastar, которая с DPDK?

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

Pzz>Я правильно понял твою мысль, что основные проблемы венды проистекают из того, что ее молодые разработчики не дотягиваются языком до яиц?

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

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

V>>Но в виндах решили вопрос через токены совместимости и основанную на ней технологию SxS.
Pzz>Угу. Ну и фактически, каждая программа приходит с полным комплектом своих собственных пожитков.

Необязательно.
Зависимости могут быть указаны в требованиях.
Пакетные менджеры лишь автоматизируют удовлетворение зависимостей.

И еще момент — пакетные менеджеры могут жить лишь в рамках некоей экосистемы.
Например, в экосистеме бесплатного ПО или в экосистеме платных продуктов некоей конторы.

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?

Олдскул инсталляторы под Windows работают потому, что Microsoft тщательно обеспечивала обратную совместимость системных библиотек. Нет проблемы "приложению нужна libxxx.1.2.3, в системе стоит libxxx1.2.2, на неё завязано 100500 других либ и ядро системы" — в винде новая версия библиотеки полностью совместима со старой.

Потом у юзеров появились большие диски, много RAM и интернет, что позволило заменить дорогущий процесс тестирования обратной совместимости на "пакетный менеджер" и хранение конкретных версий всех зависимостей каждого приложения.

И hype-driven development, конечно. Юзеры хотят npm под винду — будет им npm под винду.

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

vsb>C:\Windows\SxS, C:\Program Files, C:\ProgramData, %USERPROFILE%\AppData\Local, %USERPROFILE%\AppData\Roaming, Registry, Start Menu links, Desktop links. Это не принято?
В большинстве из этих мест установочный пакет создает каталог имени себя, в отличие от..., в остальных все удаляется если нужно деинсталлятором без пакетного менеджера. И да, в Винде правила не раскидывать какашки придерживаться тоже нужно.

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

O>Статической линковке 100 лет в обед. С ней ровно две проблемы — бинарники получаются жирные и апдейтятся только целиком. Потому 99 лет в обед как придумали динамическую линковку.

за 15 лет программирования на С++ я что-то узнал про динамическую линковку, как не удивительно, и не утверждаю что она не нужна
то о чем я пишу, касается не всего софта, а только критичного. для такого софта я хочу использовать новейший компилятор и стандартную библиотеку, последний стандарт, собирать и последним гцц и клэнгом и тд, то бишь пакетный менеджер ОС уже не может мне это дать
далее, я не хочу полагаться на пакетный менджер ОС для доставки критичных обновлений и ждать, когда там зарелизят новый openssl, я хочу просто пересобрать свой софт на CI (как только система поймет что вышла новая версия openssl) протестировать софт на CI и задеплоить его, опять же через CI.

Я могу собрать софт, который зависит от openssl из пакетного менеджера, а потом админ моего клиента не будет пол года обновлять его. Зачем это нужно? И если у меня уже есть CI, который собирает все что нужно для проекта, начиная от компиляторов и заканчивая openssl, а также трекает CVE, то никаких проблем кроме вполне решаемой проблемы размеров бинарников статическая линковка не создает.

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

С>Прошу прощения за оффтопик, а зачем вам Seastar? Это та самая Seastar, которая с DPDK?

да, та на которой сделали ScyllaDB
нужна по прямому назначению

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

scf>Олдскул инсталляторы под Windows работают потому, что Microsoft тщательно обеспечивала обратную совместимость системных библиотек. Нет проблемы "приложению нужна libxxx.1.2.3, в системе стоит libxxx1.2.2, на неё завязано 100500 других либ и ядро системы" — в винде новая версия библиотеки полностью совместима со старой.

msvcrt120.dll

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

MH>ведь есть куча инсталляторов, давным давно существующих и развивающихся?..
MH>и даже Microsoft недавно сделал свой менеджер для софта, чем не устроил их ихний же msi engine?

Зачем нужен инсталлятор ? Чем он лучше ?

Менеджер пакетов удобен — единая точка входа и поиска нужных программ. Раньше были и сейчас есть сайты куда люди ходили чтобы найти нужный инсталлятор, своеобразная замена пакетного менеджера, сейчас это интегрированно в систему.
Также удобно обновление программ — сразу видно какие программы вышли в новой версии и возможность удобно их обновить при желании.

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

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

scf>>Олдскул инсталляторы под Windows работают потому, что Microsoft тщательно обеспечивала обратную совместимость системных библиотек. Нет проблемы "приложению нужна libxxx.1.2.3, в системе стоит libxxx1.2.2, на неё завязано 100500 других либ и ядро системы" — в винде новая версия библиотеки полностью совместима со старой.

H>msvcrt120.dll

Это не системная библиотека, в отличие от msvcrt.dll из VS6, которая в неизменном виде есть во всех версиях Windows как минимум с win2k

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

S>Потому что overenginering и не осилили.

как в генте

> Софт должен быть простым

как в генте

> настолько, насколько это возможно.

как в генте

> Но не проще.

как в генте

S>Манагер пакетов он простой как пыль:

как в генте

> список зависимостей,

как в генте

> скрипты инициализации

как в генте

> и пожалуй хватит. Ну можно ещо конфиги по умолчанию.

как в генте

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

scf>в винде новая версия библиотеки полностью совместима со старой.

Извините за жаргон, но ржал аки лошадь чалая...

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

U>как в генте
Ну во первых, в генте это всё действительно очень просто.
А во вторых, такое впечатление что генту у тебя жену увела...

Здравствуйте, vdimas, Вы писали:
...
V>И еще момент — пакетные менеджеры могут жить лишь в рамках некоей экосистемы.

Это скорее вопрос политики той или иной компании.
Она зависит от Модели Распространения ПО.

V>Например, в экосистеме бесплатного ПО или в экосистеме платных продуктов некоей конторы.

Вот что мешает той же M$ сделать свой пакетный менеджер для продуктов на базе их (микросовтовских) технологий?

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

CK>за 15 лет программирования на С++ я что-то узнал про динамическую линковку, как не удивительно, и не утверждаю что она не нужна
CK>то о чем я пишу, касается не всего софта, а только критичного. для такого софта я хочу использовать новейший компилятор и стандартную библиотеку, последний стандарт, собирать и последним гцц и клэнгом и тд, то бишь пакетный менеджер ОС уже не может мне это дать
CK>далее, я не хочу полагаться на пакетный менджер ОС для доставки критичных обновлений и ждать, когда там зарелизят новый openssl, я хочу просто пересобрать свой софт на CI (как только система поймет что вышла новая версия openssl) протестировать софт на CI и задеплоить его, опять же через CI.

CK>Я могу собрать софт, который зависит от openssl из пакетного менеджера, а потом админ моего клиента не будет пол года обновлять его. Зачем это нужно? И если у меня уже есть CI, который собирает все что нужно для проекта, начиная от компиляторов и заканчивая openssl, а также трекает CVE, то никаких проблем кроме вполне решаемой проблемы размеров бинарников статическая линковка не создает.

Тебе нужен Gentoo

U>>как в генте
S>А во вторых, такое впечатление что генту у тебя жену увела...
а тебя она (оно?) похоже увело от жены..

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

U>>>как в генте
S>>А во вторых, такое впечатление что генту у тебя жену увела...
O>а тебя она (оно?) похоже увело от жены..
Нет, зачем?
Или ты наслушался баек про "генту отнимает много времени, блаблабла..."?

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

V>>Например, в экосистеме бесплатного ПО или в экосистеме платных продуктов некоей конторы.
AG>Вот что мешает той же M$ сделать свой пакетный менеджер для продуктов на базе их (микросовтовских) технологий?

Для Офиса был в своё время придуман MSI, напомню.

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

S>Тебе нужен Gentoo

В магазине десятки только Ubuntu, Debian, Kali, SUSE. Вроде ьы еще Федору видел. Генту не завезли. Но как только...

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

S>Эти все компоненты линкуются не с libastral, а с огромной кучей других компонентов о существовании которых ты даже не подозреваешь. Так что своим желаением какого-то комфорта, чтоб всё было модно и молодёжно, тупо нарушаешь целостность системы, затаскивая чужеродный хлам. Если хочется модного и молодёжного можно юзать распоследнюю бубунту. А если пилится ынтерпрайзный софт под centos или sles, то будь добр юзать штатные gcc и пр.
smeeld, как всегда, не в теме совсем. И не знает даже про RHSCL.

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

CK>>ну вот смотри, есть такой язык программирования Go, он умеет собирать бинарник, который ни от чего не зависит и делает системные вызовы напрямую
S>и ты поверил?

cyberax@CybMac:~/aurora/terra$ GOOS=linux go build -o canary-run canary/main/canary.go
cyberax@CybMac:~/aurora/terra$ file canary-run
canary-run: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=nFN1C_Wpim3kdAeNVoW7/fIhH4yeKvB_HyGv3sJ1b/B91qqWsvKUprW2vwgzEW/pjOJTJ5Vtr5MohXoKUCH, not stripped

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

S>То ли дело сейчас — качнул проект, сделал dotnet restore — оп-ля! Он тебе стянул гигабайт добра и собрался. Лепота.
Вот только некоторые редиски берут и удаляют старые версии nuget библиотек с сайта.
Клиент просит патч, а собрать полугодовой билд уже корректно не получается — эта версия тянёт уже более новый компонент, так как версия, указанная в проекте, уже недоступна.

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

S>А, вы из этих, псевдолинуксоидов. Ну, которые "я линупс знаю, итд!" а на деле разве что wsl и пользуют и то исключительно потому что админы подсказали что там ssh удобнее putty.

И когда я себя позиционировал мегазнатоком Линукса? Я только писал, что на одной из моих железок стоит Убунта.
Ты, наверное, знаешь, что сейчас существуют конторы, занимающиеся администрированием, системной интеграцией и т. п. вещами. Я недавно разговаривал с админом, работающим в такой конторе. Чтобы не было вопросов, замечу сразу: админ нормальный. Из тех, которые друзья разработчиков. Он говорит: они не берут на саппорт конторы, в которых на компах пользователей стоит Линукс. Потому что бывали случаи, когда кто-то что-то где-то в коде допишет, а админы потом то, что получилось, не могут заставить работать. Опенсорс, он такой! И, как ты понимаешь, дело вовсе не в том, что админы чего-то там не знают. Кроме, конечно, доработок, сделанных местными колхозниками-Самоделкиными. Речь идет о коде ядра или загружаемых модулей.

S>Будь мужиком, ставь генту на железо! )))

У меня сейчас что на работе, что дома: все железо с предустановленной десяткой, заточенной на конкретную модель. Работает, как часы. Зачем ломать налаженный механизм?
Я по работе с Линуксом никак не связан. Даже кроссплатформенность от меня никто не требует. А ставить "шоб було" — разве что место на диске зарезервировать. Чтобы почистить, когда понадобится. Я так делал еще в 2003 году.

S>Ну а винду, так и быть, можешь потом в виртуалке поселить.

Лмнукс, так и быть, я когда-нибудь там и поселю. Но когда — вопрос. Пока Линукс не нужен.

Здравствуйте, Clerk, Вы писали:
C>Клиент просит патч, а собрать полугодовой билд уже корректно не получается — эта версия тянёт уже более новый компонент, так как версия, указанная в проекте, уже недоступна.
Вот это они зря.

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

S>>То ли дело сейчас — качнул проект, сделал dotnet restore — оп-ля! Он тебе стянул гигабайт добра и собрался. Лепота.
C>Вот только некоторые редиски берут и удаляют старые версии nuget библиотек с сайта.
C>Клиент просит патч, а собрать полугодовой билд уже корректно не получается — эта версия тянёт уже более новый компонент, так как версия, указанная в проекте, уже недоступна.
Кеш поставьте свой. Он будет хранить использованные вами версии сколько угодно вам, а не всяким редискам.

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

S>>А, вы из этих, псевдолинуксоидов. Ну, которые "я линупс знаю, итд!" а на деле разве что wsl и пользуют и то исключительно потому что админы подсказали что там ssh удобнее putty.

P>И когда я себя позиционировал мегазнатоком Линукса? Я только писал, что на одной из моих железок стоит Убунта.
P>Ты, наверное, знаешь, что сейчас существуют конторы, занимающиеся администрированием, системной интеграцией и т. п. вещами. Я недавно разговаривал с админом, работающим в такой конторе. Чтобы не было вопросов, замечу сразу: админ нормальный. Из тех, которые друзья разработчиков. Он говорит: они не берут на саппорт конторы, в которых на компах пользователей стоит Линукс. Потому что бывали случаи, когда кто-то что-то где-то в коде допишет, а админы потом то, что получилось, не могут заставить работать. Опенсорс, он такой! И, как ты понимаешь, дело вовсе не в том, что админы чего-то там не знают. Кроме, конечно, доработок, сделанных местными колхозниками-Самоделкиными. Речь идет о коде ядра или загружаемых модулей.
Не берут потому что очевидно что у админов потенциального клиента больше опыта, чем у саппортеров.
С другой стороны, подобные клиенты должны быть более адекватные — можно разговаривать с админами прямым текстом, не начиная с "командная строка рута это когда # в конце строки приглашения"
С третьей стороны "я дописал а оно не заработало — памагите" это признак неопытного, сильно неопытного админа. Который бэкапы не только не проверяет но ещо и не делает.

S>>Будь мужиком, ставь генту на железо! )))
P>У меня сейчас что на работе, что дома: все железо с предустановленной десяткой, заточенной на конкретную модель. Работает, как часы. Зачем ломать налаженный механизм?
P>Я по работе с Линуксом никак не связан. Даже кроссплатформенность от меня никто не требует. А ставить "шоб було" — разве что место на диске зарезервировать. Чтобы почистить, когда понадобится. Я так делал еще в 2003 году.
Это был сарказм ))))

S>>Ну а винду, так и быть, можешь потом в виртуалке поселить.
P>Лмнукс, так и быть, я когда-нибудь там и поселю. Но когда — вопрос. Пока Линукс не нужен.
Тебе и wsl хватит, я более чем уверен.

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

S>Не берут потому что очевидно что у админов потенциального клиента больше опыта, чем у саппортеров.

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

S>С третьей стороны "я дописал а оно не заработало — памагите" это признак неопытного, сильно неопытного админа. Который бэкапы не только не проверяет но ещо и не делает.

Да. Потому что вменяемый админ не полезет в код ядра ОС чего-то там допиливать. У него других проблем хватает.

S>>>Будь мужиком, ставь генту на железо! )))

S>Это был сарказм ))))

Я всегда знал, что ты виндовоз. Но продолжай рассказывать про Генту.

S>Тебе и wsl хватит, я более чем уверен.

И даже он не нужен.

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

S>>Не берут потому что очевидно что у админов потенциального клиента больше опыта, чем у саппортеров.
P>У потенциального клиента нет своих админов. Видишь ли, небольшой офис, к примеру, адвокатская контора или частная стоматология, просто не потянут штат админов. Поэтому и обращаются в специализированные конторы. Откуда там берутся Самоделкины с перепиленным Линуксом, я не знаю, но оснований не доверять админу, с чьих слов мне известно о подобных вещах, у меня нет.
В таком случае делаю проще: при взятии на обслуживание тратят больше времени на перепиливание этих небольших контор. Проволят аудит железа, используемого ПО, определяют что клиенту нужно и перепиливают. Да, дороже выходит первый этап. Но зато имеем ещё одного клиента.


S>>С третьей стороны "я дописал а оно не заработало — памагите" это признак неопытного, сильно неопытного админа. Который бэкапы не только не проверяет но ещо и не делает.
P>Да. Потому что вменяемый админ не полезет в код ядра ОС чего-то там допиливать. У него других проблем хватает.
У хорошего админа проблем нет. Хороший админ на работе каждый день сталкивается с сложной задачей "чего бы сегодня интересного сделать?". Ибо алерты, логи, метрики — всё под рукой и бОльшая часть автоматизирована.


S>>>>Будь мужиком, ставь генту на железо! )))
S>>Это был сарказм ))))
P>Я всегда знал, что ты виндовоз. Но продолжай рассказывать про Генту.
Я не знаю почему тебе нравится так думать, но да магистры с тобой, думай так если тебе нравится

S>>Тебе и wsl хватит, я более чем уверен.
P>И даже он не нужен.
Этот скорее нужен, так как сейчас даже стойкие виндопрограммеры начинают в линукса уходить. Вот как раз я в одной такой конторе и работаю. 10 лет виндософта, но всётаки пошли и линупс захватывать.

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

S>В таком случае делаю проще: при взятии на обслуживание тратят больше времени на перепиливание этих небольших контор. Проволят аудит железа, используемого ПО, определяют что клиенту нужно и перепиливают. Да, дороже выходит первый этап. Но зато имеем ещё одного клиента.

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

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

Админ по работе часто сталкивается с массой разных задач. Хороший админ никогда не занимается отсебятиной типа "чтобы тут еще такого сделать".

S>Я не знаю почему тебе нравится так думать, но да магистры с тобой, думай так если тебе нравится

Я админ, я профессиональный виндовоз

Автор: Sheridan
Дата: 07.11.11

. Это ты сам сказал. Проболтался?

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

Не нужен. Даже на серверах. Впрочем, ходят слухи, что MS вкладывается в Linux, так что возможно все. Специально подтверждений я не искал. Но Убунта, Дебиан и другие зачем-то в магазин попали.

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

P>А ты методикой делиться не хочешь.
Дьявол в мелочах. Но часто его вызывать не нужно.

S>>У хорошего админа проблем нет. Хороший админ на работе каждый день сталкивается с сложной задачей "чего бы сегодня интересного сделать?". Ибо алерты, логи, метрики — всё под рукой и бОльшая часть автоматизирована.
P>Админ по работе часто сталкивается с массой разных задач. Хороший админ никогда не занимается отсебятиной типа "чтобы тут еще такого сделать".
Задачи заканчиваются по мере их автоматизации. У меня куча опыта про организацию IT с нуля. Сначала работы много, потом становится скучно потому что делать уже нечего.

S>>Я не знаю почему тебе нравится так думать, но да магистры с тобой, думай так если тебе нравится
P>Я админ, я профессиональный виндовоз

Автор: Sheridan
Дата: 07.11.11

. Это ты сам сказал. Проболтался?
А, ты в суть до сих пор так и не вник. Ну ок


S>>Этот скорее нужен, так как сейчас даже стойкие виндопрограммеры начинают в линукса уходить. Вот как раз я в одной такой конторе и работаю. 10 лет виндософта, но всётаки пошли и линупс захватывать.
P>Не нужен. Даже на серверах. Впрочем, ходят слухи, что MS вкладывается в Linux, так что возможно все. Специально подтверждений я не искал. Но Убунта, Дебиан и другие зачем-то в магазин попали.
Хорошо-хорошо. Не нужен. Хорошо. Всёоо хорошо.

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

S>Дьявол в мелочах. Но часто его вызывать не нужно.

Я ж не про мелочи. Я про общие положения. Тебе, возможно, после опубликования методики сразу премию Тьюринга и место профессора информатики в МИТе дадут. Или мелочей слишком много. Там минутка, здесь минутка, и ночь растягивается до полярной.

P>>Админ по работе часто сталкивается с массой разных задач. Хороший админ никогда не занимается отсебятиной типа "чтобы тут еще такого сделать".
S>Задачи заканчиваются по мере их автоматизации. У меня куча опыта про организацию IT с нуля. Сначала работы много, потом становится скучно потому что делать уже нечего.

Это ты к чему сказал? Какая связь между моим тезисом про отсебятину и твоим про "сначала работы много"?

S>А, ты в суть до сих пор так и не вник. Ну ок

А чего там вникать? Виндовоз — он и на Марсе виндовоз.

S>Хорошо-хорошо. Не нужен. Хорошо. Всёоо хорошо.

Во! Наконец-то ты к этому пришел!

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

P>Но боюсь, что это может быть близко скорее админам, но никак не программистам (разработчикам)


О хосспади, какие нафталиновые понятия... нынче в 21 веке девопсы, и кто из них программист, а кто админ, а кто интегратор иногда невозможно определить. До 12 он смотрит патчи в мейнлайне, а после 12 готовит билд с нужными ему правками в своей кастомной системе. А для тех, у кого мало ресурсов для собственного дистра, есть LTS релизы и всегда есть право на лево (проприетарный блоб/архивчик).