Здравствуйте, vdimas, Вы писали:
V>... V>Что такое "токен"? Он был введен для определения бинарной совместимости. V>Например, бинарник версии "3.0" с токеном "А" удовлетворит затребованную зависимость "2.0 A", но её не удовлетворит другой бинарник "2.0 B".
Затребует приложение "2.0 С", которого нет. Что получит приложение: "длл-хелл" или "хаос версий"?
V>Ведь именно поэтому в Linux невозможно сосуществование бинарников от разных сборок, что эти бинарники несовместимы (конфликтуют), хотя у них одинаковые или совместимые версии. Если бы ввести SxS в Linux, то можно было бы на одной системе иметь пакеты от разных сборок без всяких конфликтов, как это происходит в Windows.
SxS можно эмулировать для glibc посредством символьных ссылок, LD_PRELOAD, LD_LIBRARY_PATH и других интересных переменных среды, вплоть до подмены загрузчика (ld.so) прямо из командной строки.
Только нужен ли этот комбинаторный взрыв для получения более-менее детерминированной системы?
Для винды, где пакетный менеджер — это кнопка "загрузить" на сайте vasya-pupkin.narod.ru, устанавливающий без согласия пользователя сд-эжектор от тындекса, без комбинаторного взрыва никак.
_>>Посмотри на NixOS с менеджером пакетов Nix.
V>Те же самые проблемы, которые решаются через ональную огороженность от других сборок линухов и даже от собственных сборок (разумеется!), которые имеют другую версию. )) V>Трэш и угар, как по мне, но индустрия этим живёт сегодня.
Вот именно, "индустрия" живет.
_>>SxS рядом не валялся.
V>Мде?
Мде.
_>>Этом, можно сказать, динамически загружаемые библиотеки как статически слинкованные.
V>Да это вообще не важно. Смотри в суть вещей. В линухах до сих пор ниасили link-time code generation, поэтому запросто, например, могут позволять себе подставлять статические библиотеки для динамических зависимостей. Рука-лицо, не? ))
_>>Проблема не решается, появляется проблема хаоса из очень мало отличающихся версий либ. Один ад заменили другим адом.
V>Ну ты бы копнул SxS, там немного совсем. V>Это не пакетный менеджер ни в одном из мест. V>Это скромная такая, малюсенькая подсистема управления зависимостями. V>ЛЮБОЙ адекватный виндовый пакетный менеджер должен сидеть поверх этой базы.
Вот именно, sxs — это не пакетный менеджер, это какой-то костыль, с попыткой разрулить зависимости.
Лучше бы сделали нормальный пакетный менеджер.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
L>>Какой смысл о RAII вообще начинать говорить, если динамической памяти нет? EP>RAII же не только про память — даже в языках со встроенным GC таки вводят RAII-like скобки: using, try-with-resources, with.
Так исключений обычно тоже нет.
Вот автоматический вызов деструктора при выходе из скопа все же есть.
Здравствуйте, landerhigh, Вы писали:
L>Динамической в том смысле, в котором она присутствует на "больших" компах, там нет. И, что характерно, обычно и не надо.
Есть просто некий объем памяти.
А статически ей будут пользоваться или динамически, зависит сугубо от ПО.
V>>Где-то 128 байт встроенного ОЗУ, где-то килобайты встроенного, V>>а где-то можно подключить "большое" внешнее ОЗУ. L>Это ж не ОЗУ в прямом смысле этого слова.
Именно что ОЗУ в прямом смысле.
Разве что обычно подключают статическое ОЗУ, а не динамическое, чтобы не возиться с контроллером памяти.
В общем, у всех линеек и архитектур микроконтроллеров есть версии исполнения с внешними шинами адреса и данных.
V>>Т.е., вполне себе используют менеджеры памяти, когда это необходимо. V>>У меня был когда-то самописный даже для 512-ти байт ОЗУ, бо сами данные порой имеют динамическую природу. L>Подобные "менеджеры памяти" иногда приходится и при разработки для полноценных PC изобретать
Ну я и говорю, что это сугубо софтовый аспект — как распоряжаться имеющейся памятью.
V>>>>А если взять PIC или L>>>Зачем их брать, если для них компилятора плюсов даже нет? V>>Ну вот я их и взял, чтобы показать, почему там не плюсов. )) L>Есть мнение, что их там нет вовсе не поэтому
Наблюдая за развитием плюсов, особенно за попытками притащить его в embedded, я могу дать руку на отсечение, что именно поэтому. ))
Потому что плюсы тянут за собой кучу требований.
В итоге, популярные когда-то различные компиляторы С++ для embedded-платформ придумывали всякие ограничения:
— то исключения нельзя бросать;
— то отсутствует тип данных указателя на ф-ию или на мембер структуры/класса;
— нельзя множественное наследование (теряется фишка многих трюков на шаблонах);
— некоторые отказались от шаблонов;
— и т.д.
Например, для 8051 компиляторы С++ были и есть, даже более одного (на слуху от IAR, там даже шаблоны есть, вроде бы), но там настолько урезано всё остальное, что оно толком не взлетело.
Здравствуйте, vdimas, Вы писали:
V>Есть просто некий объем памяти. V>А статически ей будут пользоваться или динамически, зависит сугубо от ПО.
Это уже философия.
На практике микроконтроллер нужен как некий КА. Шлагбаум там открывать. Или закрывать. Памяти нужно очень мало.
V>Наблюдая за развитием плюсов, особенно за попытками притащить его в embedded, я могу дать руку на отсечение, что именно поэтому. ))
А мне кажется, что больше из-за засилия там умудренных сединой старцев, дальше сей ничего не видевших и как следствие отсутствие заметной востребованности в оном.
V>Потому что плюсы тянут за собой кучу требований. V>В итоге, популярные когда-то различные компиляторы С++ для embedded-платформ придумывали всякие ограничения: V>- то исключения нельзя бросать; V>- то отсутствует тип данных указателя на ф-ию или на мембер структуры/класса; V>- нельзя множественное наследование (теряется фишка многих трюков на шаблонах); V>- некоторые отказались от шаблонов; V>- и т.д.
Кое-что напомнило... тут вроде как недавно платформу Tizen обсуждали. Где конструкторы ниасилили
Здравствуйте, fin_81, Вы писали:
V>>Что такое "токен"? Он был введен для определения бинарной совместимости. V>>Например, бинарник версии "3.0" с токеном "А" удовлетворит затребованную зависимость "2.0 A", но её не удовлетворит другой бинарник "2.0 B". _>Затребует приложение "2.0 С", которого нет. Что получит приложение: "длл-хелл" или "хаос версий"?
Получит примерно то же, что получит твой бинарник на NixOS, когда захочет версию glibc.so.7.1, а в наличии будет только glib.so.6.2.
V>>Ведь именно поэтому в Linux невозможно сосуществование бинарников от разных сборок, что эти бинарники несовместимы (конфликтуют), хотя у них одинаковые или совместимые версии. Если бы ввести SxS в Linux, то можно было бы на одной системе иметь пакеты от разных сборок без всяких конфликтов, как это происходит в Windows. _>SxS можно эмулировать для glibc посредством символьных ссылок
Нельзя и не спорь. Я плотно с этим возился одно время.
_>вплоть до подмены загрузчика (ld.so) прямо из командной строки.
Дудки, ls.so надо подменять ВСЕЙ системе, потому что версионные зависимости должны распространяться транзитивно м/у процессами, но сами эти процессы (каждый из них) не должны этой фигней заниматься. Задача любого бинарника — дать загрузчику получить инфу о своей версии и о версии зависимостей.
А учитывая, что загрузчик — это "сердце" любой операционки... В общем, ты понял. ))
_>Только нужен ли этот комбинаторный взрыв для получения более-менее детерминированной системы?
Откуда там комбинаторный взрыв?
На сегодня поддерживаемый в SxS версий бинарников для различных поколений Windows больше, чем популярных ныне семейств совместимых сборок Linux. А если ограничиться LSB (а ограничиться придётся, потому что ни в какой версии не пропишешь, какие пути корневой FS считать "правильными" и как их интерпретировать), то там остаётся 3-4 конфигурации, где 95% объема бинарников "схлопнется" в общую часть, бо де-факто бинарно совместима м/у сборками.
_>Для винды, где пакетный менеджер — это кнопка "загрузить" на сайте vasya-pupkin.narod.ru, устанавливающий без согласия пользователя сд-эжектор от тындекса, без комбинаторного взрыва никак.
Что-то облом холиварить.
Платные ОСи давно переняли моду линухов — распространяют ПО через авторизованные репозитории — "магазины приложений".
V>>Те же самые проблемы, которые решаются через ональную огороженность от других сборок линухов и даже от собственных сборок (разумеется!), которые имеют другую версию. )) V>>Трэш и угар, как по мне, но индустрия этим живёт сегодня. _>Вот именно, "индустрия" живет.
Это не отменяет трэша и угара.
На одной только несовместимости поколений RHEL 5.x/6.x/7.x индустрия теряет многие миллионы ежегодно.
V>>Ну ты бы копнул SxS, там немного совсем. V>>Это не пакетный менеджер ни в одном из мест. V>>Это скромная такая, малюсенькая подсистема управления зависимостями. V>>ЛЮБОЙ адекватный виндовый пакетный менеджер должен сидеть поверх этой базы. _>Вот именно, sxs — это не пакетный менеджер, это какой-то костыль, с попыткой разрулить зависимости.
Почему добавление к номеру версии всего одного поля (самого важного за всю историю существования версионирования как такового) провоцирует такую попоболь? ))
Это опять холиварным ветром надуло, что ле?
_>Лучше бы сделали нормальный пакетный менеджер.
"Нормальный пакетный менеджер" с колокольни Linux — это такой, где есть исключительно бесплатное ПО и который заточен под нужны исключительно разработчика ПО. Потому что для однократно настраиваемой машинки-лошадки (скажем, платёжного или справочного терминала) никакие пакетные менеджеры не нужны, разумеется. В общем, не зря пакетные менеджеры в линухах являются всего-лишь третьесторонними тулзами, а не частью системы, угу. Даже в Gentoo. ))
Здравствуйте, vdimas, Вы писали:
_>>Затребует приложение "2.0 С", которого нет. Что получит приложение: "длл-хелл" или "хаос версий"?
V>Получит примерно то же, что получит твой бинарник на NixOS, когда захочет версию glibc.so.7.1, а в наличии будет только glib.so.6.2.
Дело в том, что ты просто не установишь это приложение, не удовлетворив зависимость.
И зависимость будет не от версии, а от хеша (sha1) полного скрипта сборки этого пакета /nix/store/<sha1>-glibc-2.24/<выхлоп>.
То есть в системе может быть установлено сколько угодно версий (включая одних и тех же версий) glibc с разными ключами конфигурации под капризы каждого приложения и могут работать одновременно.
V>>>Ведь именно поэтому в Linux невозможно сосуществование бинарников от разных сборок, что эти бинарники несовместимы (конфликтуют), хотя у них одинаковые или совместимые версии. Если бы ввести SxS в Linux, то можно было бы на одной системе иметь пакеты от разных сборок без всяких конфликтов, как это происходит в Windows. _>>SxS можно эмулировать для glibc посредством символьных ссылок
V>Нельзя и не спорь. Я плотно с этим возился одно время.
Вот в NixOS разруливают, вплоть до того что стоят разные glibc одинаковой версии для бутстрапа gcc разных стадий бутстрапа, для рабочих программ, и спорить не хотят, просто работают.
_>>вплоть до подмены загрузчика (ld.so) прямо из командной строки.
V>Дудки, ls.so надо подменять ВСЕЙ системе, потому что версионные зависимости должны распространяться транзитивно м/у процессами, но сами эти процессы (каждый из них) не должны этой фигней заниматься. Задача любого бинарника — дать загрузчику получить инфу о своей версии и о версии зависимостей.
Вот установил ты новую версию glibc (2.25 -> 2.26), а система работает, демоны не падают, сериал в видеоплеере не прервался, новые файрфоксы запускаются, как это происходит?
V>А учитывая, что загрузчик — это "сердце" любой операционки... В общем, ты понял. ))
Альтернативные миры, альтернативные теории, альтернативные религии. Мультивселенная!
_>>Только нужен ли этот комбинаторный взрыв для получения более-менее детерминированной системы?
V>Откуда там комбинаторный взрыв? V>На сегодня поддерживаемый в SxS версий бинарников для различных поколений Windows больше, чем популярных ныне семейств совместимых сборок Linux. А если ограничиться LSB (а ограничиться придётся, потому что ни в какой версии не пропишешь, какие пути корневой FS считать "правильными" и как их интерпретировать), то там остаётся 3-4 конфигурации, где 95% объема бинарников "схлопнется" в общую часть, бо де-факто бинарно совместима м/у сборками.
LSB такой LSB. Никто его не придерживается и не придерживался. Так посматривали в его сторону и с высокой колокольни. Тем более корпорации, особенно красношапка со своим системд. А системд — это уже как бы стандарт.
_>>Для винды, где пакетный менеджер — это кнопка "загрузить" на сайте vasya-pupkin.narod.ru, устанавливающий без согласия пользователя сд-эжектор от тындекса, без комбинаторного взрыва никак.
V>Что-то облом холиварить.
Взаимно. Альтернативные миры как-то неконструктивны.
Здравствуйте, landerhigh, Вы писали:
L>Это уже философия. L>На практике микроконтроллер нужен как некий КА. Шлагбаум там открывать. Или закрывать. Памяти нужно очень мало.
Ну, у меня была сложная система транкинговой связи с динамически организующейся сетью ретрансляторов на 8048 (это еще в 10 раз хуже, чем 8051).
Или программируемая система музыкальных звонков в школу на PIC и вообще много всяких приблуд на нём же.
Кароч, динамики хватало, это от самой задачи зависит.
V>>Наблюдая за развитием плюсов, особенно за попытками притащить его в embedded, я могу дать руку на отсечение, что именно поэтому. )) L>А мне кажется, что больше из-за засилия там умудренных сединой старцев, дальше сей ничего не видевших и как следствие отсутствие заметной востребованности в оном.
Но не старцы решают, что надо людям.
Например, еще в стандарте move не было, а в Бусте уже программно реализовали.
L>Кое-что напомнило... тут вроде как недавно платформу Tizen обсуждали. Где конструкторы ниасилили
Почему ниасилили? Компилятором не запрещено, просто внутренний стандарт на разработку не разрешает.
Просто пример из головы:
class MyClass
{
MyClass::MyClass(Arg1 arg1, int * arg2)
try
: field1_(arg1), field2_(arg2)
{} catch (...) {
// do we need to delete arg2 here???
}
Arg1 field1_;
std::shared_ptr<int> field2_;
};
У-у-упс ))
И это при том, что try/catch для списка инициализации народ обычно ленится использовать.
Но даже когда не ленится, то вот тебе пример нежданчика.
В общем, всякие диалекты С++ для микроконтроллеров вовсе не по причине старцев стали не нужны. А потому что народу не особо нужно, с тех пор как MIPS и ARM стали стоить в деньгах сравнимо с AVR/PIC/8051. Т.е., смысл пропал надрываться с новыми технологиями под старые архитектуры. Тем архитектурам сегодня оставили, действительно, роль "программируемого автомата". Но это же производители железа должны были созреть до такой ситуации, верно? Мы же, которые программисты, мы же не в вакууме программисты, а над вполне осязаемым железом в конце всех концов. Поэтому, стандарты на ПО, считай, прямым образом управляются ситуацией в области железа.
=============
Тем более, что тот же Саттер далеко еще не старец, а очень даже живого ума человек.
В течение 10 лет Герб был организатором и секретарем комитета по стандартизации ISO C++.
Здравствуйте, fin_81, Вы писали:
V>>Получит примерно то же, что получит твой бинарник на NixOS, когда захочет версию glibc.so.7.1, а в наличии будет только glib.so.6.2. _>Дело в том, что ты просто не установишь это приложение, не удовлетворив зависимость.
А кто мне запретит?
На что спорим, что установлю?
Причём, более чем одним способом. ))
_>И зависимость будет не от версии, а от хеша (sha1)
На безрыбье и сам раком встанешь.
Если пакеты в линухах подписывать не принято, то некий токен надо формировать от "чего-то еще".
Но смысл там тот же, что и в SxS, получается. Отличия только в источнике этого токена.
И отсюда проблема в безопасности.
Потому что подменить токен подписанному пакету в SxS я не смогу, даже обладая правами администратора, а вот обладая теми же правами в NixOS запросто можно ручками "поселить" в системе еще один пакет, который как раз навернётся при попытке его использования. Или можно подменить имеющийся пакет на другой, с тем же sha1.
Здравствуйте, vdimas, Вы писали:
V>>>Получит примерно то же, что получит твой бинарник на NixOS, когда захочет версию glibc.so.7.1, а в наличии будет только glib.so.6.2. _>>Дело в том, что ты просто не установишь это приложение, не удовлетворив зависимость.
V>А кто мне запретит? V>На что спорим, что установлю? V>Причём, более чем одним способом. ))
Твоя "система", твой "мир", твое определение понятия "установить", можешь даже манифест написать.
Здравствуйте, fin_81, Вы писали:
_>>>Дело в том, что ты просто не установишь это приложение, не удовлетворив зависимость. V>>А кто мне запретит? _>Твоя "система", твой "мир"
Именно так в Linux. Что бы там ни делала любая тулзина, навроде Nix, всё это можно повторить ручками.
_>твое определение понятия "установить", можешь даже манифест написать.
А вот подменить PTK у подписанного бинарника в Window — никак.
Здравствуйте, vdimas, Вы писали:
_>>Твоя "система", твой "мир" V>Именно так в Linux. Что бы там ни делала любая тулзина, навроде Nix, всё это можно повторить ручками.
Как ты "установишь" приложение в NixOS, если в там нет LSB? Нет там стандартных /lib, /bin и тп директорий.
Можно сказать, там каждый пакет — это своеобразный контейнер, самодостаточный с зависимостями от других пакетов.
Установишь(скопируешь) ты исполнимый файл, попытаешься запустить, а он тебе скажет, что это невалидный бинарник, тк не сможет найти загрузчик ld.so. Тебе придется установить еще одну "систему с LSB", чтобы ты мог собрать и запустить приложение в обход nix. Nix (со своим libc и загрузчиком) может установлен и работать параллельно c уже установленным debian, fedora, macos.
_>>твое определение понятия "установить", можешь даже манифест написать. V>А вот подменить PTK у подписанного бинарника в Window — никак.
Кажись, кто-то изобрел серебряную пулю в виде "подписи" и свято верит. Аминь?
Здравствуйте, fin_81, Вы писали:
_>>>Твоя "система", твой "мир" V>>Именно так в Linux. Что бы там ни делала любая тулзина, навроде Nix, всё это можно повторить ручками. _>Как ты "установишь" приложение в NixOS, если в там нет LSB? Нет там стандартных /lib, /bin и тп директорий.
И?
_>Можно сказать, там каждый пакет — это своеобразный контейнер, самодостаточный с зависимостями от других пакетов.
Эх, молодёжь... ))
В своё время я для входа в очередной chroot много чего делал ручками. Вернее, писал нужный скрипт.
Это сейчас на технологию обратили внимания, стало модно. Вон докер — это лишь обслуживающая нашлёпка на chroot и весь твой Nix тоже.
_>Установишь(скопируешь) ты исполнимый файл, попытаешься запустить, а он тебе скажет, что это невалидный бинарник, тк не сможет найти загрузчик ld.so.
Ну ты людей-то за идиотов не держи и сам не подставляйся. ))
А то вдруг я подумаю, что это твой настоящий ход мыслей.
Здравствуйте, vdimas, Вы писали:
_>>Можно сказать, там каждый пакет — это своеобразный контейнер, самодостаточный с зависимостями от других пакетов.
V>Эх, молодёжь... )) V>В своё время я для входа в очередной chroot много чего делал ручками. Вернее, писал нужный скрипт. V>Это сейчас на технологию обратили внимания, стало модно. Вон докер — это лишь обслуживающая нашлёпка на chroot и весь твой Nix тоже.
Прикинь, это не chroot, вся файловая система доступна.
В общем, тебя не интересует "внешний мир". Тебе интереснее отображать "внешний мир" на свой "внутренний", отрицая все что не отображается.
Chroot головного мозга.
Звиняйте за неадекватность вашей модели. Конец.
Здравствуйте, fin_81, Вы писали:
V>>Это сейчас на технологию обратили внимания, стало модно. Вон докер — это лишь обслуживающая нашлёпка на chroot и весь твой Nix тоже. _>Прикинь, это не chroot, вся файловая система доступна.
Здравствуйте, vdimas, Вы писали:
V>Ты всегда начинаешь хамить, когда твой собственный аргумент работает против тебя?
Попробую вернуть в конструктивное русло, раз ты провоцируешь, при этом сам уходишь от конструктива.
Первым хамить начал ты, когда я показал на сомнительность "аргумента" SxS. При этом я предложил более "аргументный аргумент" в виде Nix, указав что такой подход тоже не серебряная пуля, со своими недостатками.
Потом, ты даже в глаза не видел Nix, ни разу не писал для него пакета, но рассуждаешь аргументами в виде "chroot".
И chroot можно отключить для демона сборки. Chroot нужен для того, чтобы во время сборки гарантировать, что зависимости были только те, что указаны в сценарии, так сказать, гарантировать чистоту сборки. Установленные пакеты имеют прямые ссылки в виде: бинарник с загрузчиком /nix/store/хеш/lib/ld-linux.so, также для libc — /nix/store/хеш/lib/libc.so. По этому ты не сможешь запустить сторонний бинарник в обход nix, потому что нет там libc в стандартном месте (/lib/ld-linux.so). Можно запустить только статически слинкованный, которые напрямую дергает сисколы. Для сторонних бинарей есть пакет (точнее его придется использовать и расширить своим nix-пакетом), который настраивает стандартное окружение, чтобы можно было запустить, где используется chroot.
Но ты имеешь свое мнение, и при этом указываешь на то, что это мнение единственно правильное.
Здравствуйте, fin_81, Вы писали:
_>Попробую вернуть в конструктивное русло, раз ты провоцируешь, при этом сам уходишь от конструктива. _>Первым хамить начал ты, когда я показал на сомнительность "аргумента" SxS.
Хамить — это хамить.
А не соглашаться с тобой — моё демократическое право.
_>И chroot можно отключить для демона сборки. Chroot нужен для того, чтобы во время сборки гарантировать, что зависимости были только те, что указаны в сценарии, так сказать, гарантировать чистоту сборки. Установленные пакеты имеют прямые ссылки в виде: бинарник с загрузчиком /nix/store/хеш/lib/ld-linux.so, также для libc — /nix/store/хеш/lib/libc.so. По этому ты не сможешь запустить сторонний бинарник в обход nix, потому что нет там libc в стандартном месте (/lib/ld-linux.so).
Ты опять говоришь не о том.
Еще раз, по-русски.
В системе Nix можно "ручками" (самописным скриптом каким-нить) соблюсти все эти якобы "тонкости".
Насчёт "сторонних бинарников" — я тебе уже отвечал.
Среди всех сборок линухов не так много разнообразия, гораздо меньше, чем общая сумма всех несовместимых версий.
Поэтому, у тебя всегда будет очень даже счётное кол-во тех же, допустим, "одноименных с точностью до версии" glibc, установленных в твоём Nix (3-4 штуки от силы). Поэтому, нет абсолютно никаких проблем соорудить себе систему, в которой такие бинарники бы подготавливались бы для Nix и "инжектировались" в неё уже готовыми, подменяя, скажем, критические сборки.
_>Но ты имеешь свое мнение, и при этом указываешь на то, что это мнение единственно правильное.
Я тебе уже указывал на то, что ты плохо понимаешь, о чём рассуждаешь.
Невнимателен, не используешь воображение. Боишься представить, как оно всё в принципе может быть устроено (там элементарно, вообще-то).
Здравствуйте, vdimas, Вы писали:
_>>Попробую вернуть в конструктивное русло, раз ты провоцируешь, при этом сам уходишь от конструктива. _>>Первым хамить начал ты, когда я показал на сомнительность "аргумента" SxS.
V>Хамить — это хамить. V>А не соглашаться с тобой — моё демократическое право.
Хамство — это, так сказать, "доминация" над собеседником, что ты и демонстрируешь, настаивая на единственно правильном своем мнении, при этом не видел предмет обсуждения.
V>Ты опять говоришь не о том. V>...
И опять ты говоришь о том, что не видел, но мнение имеешь. То "chroot", то скрипты... Что еще?
Ты бы хотя писал перед своим сообщением — "не читал, но осуждаю".
Конструктив с тобой невозможен.
