The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Инициатива по сокращению зависимостей у libsystemd, opennews (??), 03-Апр-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


46. "Инициатива по сокращению зависимостей у libsystemd"  +2 +/–
Сообщение от Аноним (21), 03-Апр-24, 14:10 
И будет каждый бинарь по килограмму весить, еще и обновлять их все вместо одной либы.
Ответить | Правка | Наверх | Cообщить модератору

55. "Инициатива по сокращению зависимостей у libsystemd"  +4 +/–
Сообщение от НяшМяш (ok), 03-Апр-24, 14:32 
Не будут, если разрабы хоть немного поизучают свои компиляторы

https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vla...

Ответить | Правка | Наверх | Cообщить модератору

216. "Инициатива по сокращению зависимостей у libsystemd"  +1 +/–
Сообщение от Аноним (216), 03-Апр-24, 21:11 
Спасибо, но с вас новые глаза.
Ответить | Правка | Наверх | Cообщить модератору

69. "Инициатива по сокращению зависимостей у libsystemd"  +3 +/–
Сообщение от _oleg_ (ok), 03-Апр-24, 14:48 
Да кошмар, вообще. И дырку не завезёшь установкой поломанной .so-либы.
Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

121. "Инициатива по сокращению зависимостей у libsystemd"  +1 +/–
Сообщение от Аноним (121), 03-Апр-24, 17:00 
Дурак? Тебе через *.a дырку завезут точно так же, а вот пофиксить будет в сто раз сложнее
Ответить | Правка | Наверх | Cообщить модератору

141. "Инициатива по сокращению зависимостей у libsystemd"  +2 +/–
Сообщение от _oleg_ (ok), 03-Апр-24, 17:47 
> Дурак? Тебе через *.a дырку завезут точно так же, а вот пофиксить
> будет в сто раз сложнее

Ты хоть бы молчал, если нихрена не понимаешь.
_Точно так же_ легко не завезут. Одним обновлением .so мне поломают все связанные с ней программы. За раз. Привет liblzma. А если дырка в .a, с которым какие-то программы слинкованы, то они очень просто пересобираются. Для хомячка с apt-get это выглядит как apt-get update && apt-get upgrade.

Я уж молчу про другие минусы .so и надуманные плюсы.

Ответить | Правка | Наверх | Cообщить модератору

155. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (121), 03-Апр-24, 18:23 
> apt-get update && apt-get upgrade

И это потребует обновления ВСЕГО забагованного софта. В случае со статической либо, нужно обновить только одну либу. Это и называется проще. Насчет что дырки завезут, это вообще ортогонально к типу линковки - хоть в статику, хоть в динамику, какая разница то?

Ответить | Правка | Наверх | Cообщить модератору

162. "Инициатива по сокращению зависимостей у libsystemd"  +1 +/–
Сообщение от _oleg_ (ok), 03-Апр-24, 18:46 
>> apt-get update && apt-get upgrade
> И это потребует обновления ВСЕГО забагованного софта. В случае со статической либо,
> нужно обновить только одну либу. Это и называется проще. Насчет что
> дырки завезут, это вообще ортогонально к типу линковки - хоть в
> статику, хоть в динамику, какая разница то?

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

Вот именно, что без разницы. Но so-либа это палка о двух концах. Легко обновить и так же легко занести бяку. Плюс он же и минус. Поэтому нет смысла его приводить как аргумент.

Ответить | Правка | Наверх | Cообщить модератору

198. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от n00by (ok), 03-Апр-24, 20:22 
Вот это вообще забавная ситуация: дистрибутивы систематически обновляют по гигабайту непонятно ради чего, а пересобрать и обновить несколько приложений - это что-то ужасное.
Ответить | Правка | Наверх | Cообщить модератору

200. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (200), 03-Апр-24, 20:28 
А еще динамические либы экономят место и память
Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

268. "Инициатива по сокращению зависимостей у libsystemd"  +1 +/–
Сообщение от n00by (ok), 04-Апр-24, 09:13 
> А еще динамические либы экономят место и память

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

Ответить | Правка | Наверх | Cообщить модератору

311. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (-), 05-Апр-24, 06:04 
> Эту мантру повторяют те, кто никогда не смотрел ассемблерные листинги и вообще
> смутно представляет, сколько памяти и подо что расходуется.

Ну влинкуй себе в каждую программу по libqt6 статически, заодно и посмотрим на сколько у тебя там памяти хватит... никогда не видел бинарничек 50 мегов? А если так в каждой проге сделать - нормалек будет? :)

И не - это не будет shared сегментом памяти у разных прог. А вот в .so - таки вполне себе. Ибо RCU же. Как минимум в линухе.

Ответить | Правка | Наверх | Cообщить модератору

314. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от n00by (ok), 05-Апр-24, 07:24 
>> Эту мантру повторяют те, кто никогда не смотрел ассемблерные листинги и вообще
>> смутно представляет, сколько памяти и подо что расходуется.
> Ну влинкуй себе в каждую программу по libqt6 статически

Зачем мне линковать это к твоему любимому bash? Что бы удовлетворить твою потребность быть наконец-то удовлетворённым результатами демагогии?

> заодно и посмотрим на сколько у тебя там памяти хватит...

Если тебе надо что-то посмотреть, но ты сам не можешь, советую тебе формулировать просьбу ко мне несколько иным образом.

> никогда не видел бинарничек 50 мегов?
> А если так в каждой проге сделать - нормалек будет? :)

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

> И не - это не будет shared сегментом памяти у разных прог.
> А вот в .so - таки вполне себе. Ибо RCU же.
> Как минимум в линухе.

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

Ответить | Правка | Наверх | Cообщить модератору

321. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (-), 05-Апр-24, 08:48 
> Зачем мне линковать это к твоему любимому bash?

Вы уверены что вы сегодня вменяемы и трезвы, сэр? Если речь про qt6 - это гуйная прога. Ну вон клиент биктоина можете взять. Порядка 40 мегов весит в таком виде.

> Что бы удовлетворить твою потребность быть наконец-то удовлетворённым результатами демагогии?

Ваш пассаж выше открывает новые горизонты в этом направлени, но такой полет мысли для меня слишком крут. Не понимаю как можно привязать bash к qt6. Что у вас в голове?

> Если тебе надо что-то посмотреть, но ты сам не можешь, советую тебе
> формулировать просьбу ко мне несколько иным образом.

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

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

В таких штуках обычно squashfs какой-нибудь если авторы не совсем ламы, он целиком в память не грузится и пользуется обыным page cache. К тому же инсталл оси работает единолично. А на более обычном десктопе можно и десяток программ запустить.

Что таокго запустить плеер на основе кути, кад на основе кути, клиент битка какой, калькулятор на основе кути, просмотрщик пдф на ней же... и мне как, им всем по дишних 50 метров в памяти подарить на код?

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

Если вы линкуете статически - шаринг памяти между инстансами либ вколочеными прямо в бинарт, в частности, и той же кути - не случается. И каждая жрет по отдельному куску рамы на себя любимую. А с SO'шкой она таки одна будет замаплена в память всех исполняемых, и это будет ОДИН регион памяти на всю ораву. Куда как меньше жора, особенно если это что-то размером с куть.

Да, это не халявно и ессно вызов функций может получиться менее оптимальным в энных случаях. Но что куть что сабж типа sd-notify это может пережить, там никакого перфоманса операций не надо.

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

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

Ответить | Правка | Наверх | Cообщить модератору

337. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от n00by (ok), 05-Апр-24, 12:19 
>> Зачем мне линковать это к твоему любимому bash?
> Вы уверены что вы сегодня вменяемы и трезвы, сэр?

Совершенно уверен.

> Если речь про qt6 - это гуйная прога.

С чем тебя и поздравляю.

Когда протрезвеешь, перечитай свой наброс: Ну влинкуй себе _в_ _каждую_ программу по libqt6 статически

Ответить | Правка | Наверх | Cообщить модератору

284. "Инициатива по сокращению зависимостей у libsystemd"  +1 +/–
Сообщение от _oleg_ (ok), 04-Апр-24, 12:19 
> А еще динамические либы экономят место и память

А ещё они тормозят на этапе связывания на старте и т.п. Место - смешно. Сейчас диски вполне позволяют лишние 100Мб разместить. Да и там не совсем так всё в лоб (то, что реально нужно всем и большое, реализуется по другому нежели просто библиотека).

Ну а если же брать экономию оперативы, например, на кучи одинаковых процессов, то я проверял когда-то - статический бинарь обгоняет по экономии оперативы динамический уже на кол-во процессов больше 5 (благодаря общему использованию .text-сегмента, но знают ли об этом ньюфаги и прочие смузихлёбы?..). А когда их сотни и тысячи, то выбор очевиден. Где-то были даже графики - https://files.fm/f/8rdpprtpdr .

Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

327. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (329), 05-Апр-24, 10:03 
>> А еще динамические либы экономят место и память
> А ещё они тормозят на этапе связывания на старте и т.п.

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

> Место - смешно. Сейчас диски вполне позволяют лишние 100Мб разместить.

И оператива резиновая, бесплатная и занять ее нечем. SOшник то в память мапится 1 раз на всю толпу процессов, потом RCU только отличия копирует - коих мизер.

> то я проверял когда-то - статический бинарь обгоняет по экономии оперативы
> динамический уже на кол-во процессов больше 5 (благодаря общему использованию
> .text-сегмента, > но знают ли об этом ньюфаги и прочие смузихлёбы?..).

Это все в какой конфигурации было, на минуточку? В линухе так то что либа будет в памяти 1 раз, что основная тушка процесса.

А еще - в DE внезапно процессы разные. Пять разных кутевых программ с влинкованой статически кутей на 50 мегов - выжрут 250 мегов просто за сам факт наличия приватных копий кутей в оперативы. А если они динамически слинкованы, куть будет в памяти 1 раз на всю ораву, с своими 50 мегами. И старт нового процесса как раз сильно быстрее - потому что эти меги с диска уже и не читаются как раз, они уже в памяти.

> А когда их сотни и тысячи, то выбор очевиден.

Это уже весьма специфичное окружение и нишевой сценарий. Мягко говоря.

Ответить | Правка | Наверх | Cообщить модератору

333. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от _oleg_ (ok), 05-Апр-24, 11:46 
>> то я проверял когда-то - статический бинарь обгоняет по экономии оперативы
>> динамический уже на кол-во процессов больше 5 (благодаря общему использованию
>> .text-сегмента, > но знают ли об этом ньюфаги и прочие смузихлёбы?..).
> Это все в какой конфигурации было, на минуточку? В линухе так то
> что либа будет в памяти 1 раз, что основная тушка процесса.

В какой какой? Я ж говорю, что больше 5 процессов одинаковых - so сливает в экономии памяти статическому бинарнику.

> А еще - в DE внезапно процессы разные. Пять разных кутевых программ
> с влинкованой статически кутей на 50 мегов - выжрут 250 мегов
> просто за сам факт наличия приватных копий кутей в оперативы. А
> если они динамически слинкованы, куть будет в памяти 1 раз на
> всю ораву, с своими 50 мегами. И старт нового процесса как
> раз сильно быстрее - потому что эти меги с диска уже
> и не читаются как раз, они уже в памяти.

Разные, да не очень. Смотря какая система и как пользователь её использует. Внезапно может оказаться, что на обычном домашнем компе bash-процессов, которые одновременно в памяти крутятся, могут оказаться десятки. И в статике они займут меньше места в оперативе.

А вся эта история с DE и WM вообще говорит только о том, что там всё надо переделывать архитектурно и тогда so будут не нужны в таком кол-ве.

>> А когда их сотни и тысячи, то выбор очевиден.
> Это уже весьма специфичное окружение и нишевой сценарий. Мягко говоря.

Да где нишевый-то :-)? На десктопе надо смотреть. А на серваках это обычное дело. Много nginx'ов, много apache'ей и т.д.

Ответить | Правка | Наверх | Cообщить модератору

339. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от n00by (ok), 05-Апр-24, 12:32 
> Внезапно может оказаться, что на обычном домашнем компе bash-процессов, которые одновременно
> в памяти крутятся, могут оказаться десятки. И в статике они займут
> меньше места в оперативе.

Эксперты банально думают, что статика - это надо сложить размер bash с размерами libc.so и всего остального, а потом помножить на десяток. Тогда как на деле существенная часть кода выкинется. Да даже если бы при статике оказалось больше, всё это экономия на спичках, куда как интереснее возможности оптимизации при статическом связывании.

Ответить | Правка | Наверх | Cообщить модератору

344. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (-), 06-Апр-24, 09:53 
> В какой какой? Я ж говорю, что больше 5 процессов одинаковых -
> so сливает в экономии памяти статическому бинарнику.

И это было проверено для вообще всех программ, библиотек и соотношений их размеров на этой планете? Что-то не особо верится.

> Разные, да не очень. Смотря какая система и как пользователь её использует.

Пять копий 1 программы на десктопе пользователю в общем случае без надобности. А апофеозом вашего подхода являются приложухи на электроне. Там вообще эвона какой рантайм каждой проге отдельно приперли. Экономии должно быть - просто охренеть.

> Внезапно может оказаться, что на обычном домашнем компе bash-процессов, которые одновременно
> в памяти крутятся, могут оказаться десятки.

На обычном домашнем компе - врядли. У сильно некоторых фриков разве что. Да и весят они все вдесятером - меньше чем 1 копия кутей в оперативе. А если таких копий развесить пять штук независимых - каждую в своей статично линкованой проге - баш на этом фоне под микроскопом видно не будет.

> И в статике они займут меньше места в оперативе.

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

> том, что там всё надо переделывать архитектурно и тогда so будут
> не нужны в таком кол-ве.

Ну так покажите мастеркласс, посмотрим сколько и чего у вас получится. Надеюсь что не электрон очередной: такие мастерклассы нафиг надо.

> Да где нишевый-то :-)? На десктопе надо смотреть. А на серваках это
> обычное дело. Много nginx'ов, много apache'ей и т.д.

Тысячами их внезапно никто не запускает. Сейчас не в моде форк-обработчики которые by design хтонически неэффективны по сразу куче параметров.

Ответить | Правка | К родителю #333 | Наверх | Cообщить модератору

359. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от _oleg_ (ok), 08-Апр-24, 10:59 
> И это было проверено для вообще всех программ, библиотек и соотношений их
> размеров на этой планете? Что-то не особо верится.

Можете заняться подобной проверкой лично.

> На обычном домашнем компе - врядли. У сильно некоторых фриков разве что.
> Да и весят они все вдесятером - меньше чем 1 копия
> кутей в оперативе. А если таких копий развесить пять штук независимых
> - каждую в своей статично линкованой проге - баш на этом
> фоне под микроскопом видно не будет.

Все ваши кути надо переделывать.

> Ну так покажите мастеркласс, посмотрим сколько и чего у вас получится. Надеюсь
> что не электрон очередной: такие мастерклассы нафиг надо.

Я, к сожаленью, не занимаюсь разработкой ни одного известного free тулкита или рядом с ним. Поэтому только если проспонсируете моё время.

> Тысячами их внезапно никто не запускает. Сейчас не в моде форк-обработчики которые
> by design хтонически неэффективны по сразу куче параметров.

Вы как специалист localhost'а это говорите? Ну расскажите как гонять на хостинге apache с itk без форков :-).

Ответить | Правка | Наверх | Cообщить модератору

363. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (363), 08-Апр-24, 13:02 
> Можете заняться подобной проверкой лично.

При том что вы деталей своего эксперимента не опубликовали? Экспертиза опеннета во всей красе - какое-то тело брякнуло, пруфов ноль, вы там сами проверяйте, дескать. Без деталей. Круто придумано.

> Все ваши кути надо переделывать.

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

> Я, к сожаленью, не занимаюсь разработкой ни одного известного free тулкита или
> рядом с ним. Поэтому только если проспонсируете моё время.

Да я лучше кутей и этими их .so забесплатно попользуюсь. И таки буду считать что грузить приватную копию такого размера в прогу - нифига не эффективное решение.

> Вы как специалист localhost'а это говорите? Ну расскажите как гонять на хостинге
> apache с itk без форков :-).

О, а вот и "инноваторы" подтянулись. Видимо, чтобы показать как именно веб сервисы в 2024 делать ни в коем случае не надо. Что, очередная высокоинновационная шаред-помойка, которая по какому-то недоразумению еще не сдохла?!

Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

365. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от _oleg_ (ok), 08-Апр-24, 13:44 
> При том что вы деталей своего эксперимента не опубликовали? Экспертиза опеннета во
> всей красе - какое-то тело брякнуло, пруфов ноль, вы там сами
> проверяйте, дескать. Без деталей. Круто придумано.

А достаточно написал для тех, кому это интересно. Рассказал о своих изысканиях, привёл данные и график. В то время, как от вас только пустая болтовня. Так кто тут у нас "эксперт"?..

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

Да вы, вообще, не о том :-). Вам про устройства поршней и т.п., а вы про то, что дверные ручки в новой версии стали гораздо удобнее :-).

> Да я лучше кутей и этими их .so забесплатно попользуюсь. И таки
> буду считать что грузить приватную копию такого размера в прогу -
> нифига не эффективное решение.

Да нет у вас выбора. Что дали, то и берите.

>> Вы как специалист localhost'а это говорите? Ну расскажите как гонять на хостинге
>> apache с itk без форков :-).
> О, а вот и "инноваторы" подтянулись. Видимо, чтобы показать как именно веб
> сервисы в 2024 делать ни в коем случае не надо. Что,
> очередная высокоинновационная шаред-помойка, которая по какому-то недоразумению еще
> не сдохла?!

А это за детский сад сейчас был? Вы только что с очередных курсов вылезли? Где я написал про веб-сервисы? И с чего вдруг шаред-хостинги куда-то денутся? Как вы планируете запускать там сайты у людей? Бред школоты какой-то...

Ответить | Правка | К родителю #363 | Наверх | Cообщить модератору

285. "Инициатива по сокращению зависимостей у libsystemd"  +1 +/–
Сообщение от _oleg_ (ok), 04-Апр-24, 12:26 
> А еще динамические либы экономят место и память

Не надо забывать как они, вообще, появились. А появились они, если мне не изменяет память, от того, что разрабы X'ов не смогли адекватную архитектуру придумать, что бы не было огромных бинарников и т.п. В итоге получилось вот это. Из письма Роба Пайка:

When Sun reported on their first implementation of shared libraries,
the paper they presented (I think it was at Usenix) concluded that
shared libraries made things bigger and slower, that they were a net
loss, and in fact that they didn't save much disk space either.  The
test case was Xlib, the benefit negative. But the customer expects us
to do them so we'll ship it.

So yes, every major operating system implements them but that does not
mean they are a good idea.  Plan 9 was designed to ignore at least
some of the received wisdom.

Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

345. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (-), 06-Апр-24, 09:57 
>> А еще динамические либы экономят место и память
> Не надо забывать как они, вообще, появились. А появились они, если мне
> не изменяет память, от того, что разрабы X'ов не смогли адекватную
> архитектуру придумать, что бы не было огромных бинарников и т.п. В
> итоге получилось вот это. Из письма Роба Пайка:

Вообще-то идея оказалась удачной - и стала стандартом де факто. В винде, макоси и проч это все тоже есть. Правда там из-за проприетарности программ code reuse плохо работает - в винде нельзя попросить zlib у системы, свой тащите. Приватный. В DLL он или статично при этом уже не важно - приватная копия заведомо не будет шарить страницы памяти ни с кем.

Так что если в zlib всплыл вулн - упс, д@рьмо, теперь у вас есть более 9000 программ с дырой и удачи их вообще все найти и отапдейтить так по простому. В случае статической линковки с этим и в линухе можно откушать. В случае .so замена .so гарантировано меняет ее всем программам. А вон там... эээ...

Ответить | Правка | Наверх | Cообщить модератору

346. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от n00by (ok), 06-Апр-24, 11:19 
> Вообще-то идея оказалась удачной - и стала стандартом де факто. В винде,
> макоси и проч это все тоже есть. Правда там из-за проприетарности
> программ code reuse плохо работает

Плохо работает здесь понималка эксперта. В тех ОС у ПО не принято открывать исходники, потому и нет выбора. В Linux исходники открыты, свобода деклариворана, и даже внедрена мантра "лишь бы не как в венде". Но свободные от чего-то люди продолжают делать как в венде.

Ответить | Правка | Наверх | Cообщить модератору

354. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (-), 07-Апр-24, 02:37 
> Плохо работает здесь понималка эксперта. В тех ОС у ПО не принято
> открывать исходники, потому и нет выбора.

А, простите, что майкрософту на самом принципиальном уровне мешало например...
1) Сделать МОДУЛЯРИЗАЦИЮ системы на пакеты. Само по себе это не обязывает сорц открывать.
2) Предоставлять группу либ программам на уровне системы. Тот же zlib и прочие типовые вещи типа libsdl каокого и тому подобного.
3) Если прога юзает "стандартную" библу от оси, она и притаскивается системой, фиксится майками, а програмер ее просто вызывает.

ЧСХ они примерно ЭТО делают с либами winapi, msvcrt* и тому подобным. Просто это совсем уж на минималочках случается.

Единственное что я могу предположить - с одной стороны структура их ОС довольно враждебна к этому. Но ничего принципиально мешаюшего так делать все же нет. Ну вот MSI да, х-вый пакетник, дико оверинженернутый, тормозной, и на большом числе компонентов он просто заманает всех тормозами операций. Этот кусок недоразумения надо было давно выкинуть и сделать что-то более нормальное.

С другой стороны - у MS вероятно нет сотрудников понимающих эти парадигмы и готовые подписаться майнтайнить энное число дополнительных либ. Майкрософт стандартно спихивает все проблемы на даунстримов, ничего нового. За что developers, developers и делают оттуда драп-драп, собссно.

> В Linux исходники открыты, свобода деклариворана, и даже внедрена
> мантра "лишь бы не как в венде". Но свободные от чего-то люди продолжают делать как в венде.

Вообще-то я линухом пользуюсь как раз потому что пактник меня очень сильно разгружает от майнтенанса системы. Качается 1 мелкий пакет либы, дыры в более 9000 прог заделаны. Я потратил на это минуту. Это - управление ОС как оно должно быть, имхо.

Ответить | Правка | Наверх | Cообщить модератору

355. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от n00by (ok), 07-Апр-24, 11:02 
>> Плохо работает здесь понималка эксперта. В тех ОС у ПО не принято
>> открывать исходники, потому и нет выбора.
> А, простите, что майкрософту на самом принципиальном уровне мешало например...

Зачем ты сменил тему и написал не по адресу? Пиши в Микрософт.

Ответить | Правка | Наверх | Cообщить модератору

357. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (-), 08-Апр-24, 04:09 
>>> Плохо работает здесь понималка эксперта. В тех ОС у ПО не принято
>>> открывать исходники, потому и нет выбора.
>> А, простите, что майкрософту на самом принципиальном уровне мешало например...
> Зачем ты сменил тему и написал не по адресу? Пиши в Микрософт.

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

Просто у них изначально структура системы и апдейты на такое не расчитаны, и MSI - довольно хреновенькая пародия на нормальный пакетник. Ибо сложный как черти что, тормозной, переусложненный, и в таком качестве будет жутко печален.

А писать в майкрософт я пробовал. И пришел к выводу что это лишь маргинально лучше чем в спортлото. КПД операции ни к черту. В том числе и по вон той причине. Например они ACKнули пару крутых багов в своих либах (так что как видишь вон то все же практикуется в некоторой степени, и даже отливается возжелавшим сие) - и сказали что не могут раздать фикс. Потому что это не "компонент", а "часть винды". Так что ждите дескать выпуска новой винды. Вот и поговорили с майкросовтом :\. Это все кстати они отписали немеряной мегакорпе из фортуны 500. Так что - разговаривай с ними сам.

Ответить | Правка | К родителю #355 | Наверх | Cообщить модератору

360. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от n00by (ok), 08-Апр-24, 11:45 
Я знаю, что твоя тема всегда на месте, но она давно слабо коррелирует с данной, включая мою. Пора уже привыкнуть, что после пары неудачных попыток свести вопрос к демагогии, я перестаю их читать.
Ответить | Правка | К родителю #357 | Наверх | Cообщить модератору

364. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (363), 08-Апр-24, 13:06 
> Я знаю, что твоя тема всегда на месте, но она давно слабо
> коррелирует с данной, включая мою. Пора уже привыкнуть, что после пары
> неудачных попыток свести вопрос к демагогии, я перестаю их читать.

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

Ответить | Правка | К родителю #360 | Наверх | Cообщить модератору

366. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от n00by (ok), 08-Апр-24, 17:11 
Пора уже найти у нуби на гитхапе код, который способен загрузить PE/COFF куда угодно в венде и каким удобно способом, если читатель преодолеет свой страх перед плюсами и сообразит из пары рядом лежащих примеров, какие функции-члены классов и в каком порядке надо вызывать. И может быть даже заподозрит, что нуби всевозможные вопросы линковки изучил достаточно основательно. Потому может авторитетно заявить, для чего и что Микрософт делала, даже без ссылок на MSDN. Соответственно и не видит смысла в риторического вида дискуссиях, из которых не узнает ничего нового.
Ответить | Правка | К родителю #364 | Наверх | Cообщить модератору

219. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (218), 03-Апр-24, 21:24 
> Тебе через *.a дырку завезут точно так же

Совсем не точно так же. Ты не понял, о чём он говорит.

> а вот пофиксить будет в сто раз сложнее

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

Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

328. "Инициатива по сокращению зависимостей у libsystemd"  +/–
Сообщение от Аноним (329), 05-Апр-24, 10:08 
> проект с либой или тысячу от неё зависящих требует одинаковых усилий
> человека. А компьютер пусть хоть всю ночь пыхтит, он железный.

Не, вот извините. На уровне менеджмента...

1) Трекать 1 проект намного проще чем трекать 1000 проектов. Вероятность незамеченного косяка в 1000 многократно возрастает.

2) Если комп пыхтит сутки - мы эти сутки кукуем с общеизвестной уязвимостью. Зашибись, конечно.

3) Жрать проц на вот именно эти цели - допустимо разве что для билдферм. Остальные компьютерные системы установлены для ДРУГИХ целей и задач. И почему-то билдферм всем вечно не хватает и так. Но, конечно, за ваши то деньги - любой каприз, как говорится. Главное чтоб вы были готовы этот банкет оплачивать.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру