Здравствуйте, Pzz, Вы писали:
vsb>>Ну и баги железа, как правило, в Errata есть, по крайней мере если железо достаточно старое. Почитать несложно.
Pzz>Ты много работал с железом?
Не очень. Но с багами пока не сталкивался. Вообще на редкость приятное впечатление у меня от работы с железом. Я уже понял, что прошивка на 90% это то же склеивание библиотек, только эти библиотеки реализованы в HDL на железе, но вот качество этих библиотек кажется куда выше. И багов нет и интерфейс кажется очень адекватным. Про SDK от вендоров то же сказать не могу, там впечатление скорей обратное, но вся прелесть в том, что они не являются необходимыми, хотя я и использую их, за редкими исключениями.
Впрочем для меня это далеко не профильное направление, поэтому допускаю, что это "синдром туриста". Но я реально отдыхаю душой, когда пишу на простом советском C, собираю проект простым советским make-ом, где всё просто как два плюс два. А не как в каком-то вебе, где один билд можно два дня настраивать. У нас ребята фронтэнд пишут, так у них в CI сборка по полчаса идёт и артефакты (образы) по паре гигабайтов вылазят. Какое-то безумие.
Здравствуйте, vsb, Вы писали:
Pzz>>Ты много работал с железом?
vsb>Не очень. Но с багами пока не сталкивался. Вообще на редкость приятное впечатление у меня от работы с железом. Я уже понял, что прошивка на 90% это то же склеивание библиотек, только эти библиотеки реализованы в HDL на железе, но вот качество этих библиотек кажется куда выше. И багов нет и интерфейс кажется очень адекватным. Про SDK от вендоров то же сказать не могу, там впечатление скорей обратное, но вся прелесть в том, что они не являются необходимыми, хотя я и использую их, за редкими исключениями.
Я, просто, примерно всю жизнь как где-то вокруг железа работаю. И тоже люблю. Но железные глюки, они, если есть, их обычно приходится исправлять программистам. А если ты не внутри компании, которая разрабнатывала эту железку, работаешь, то тебе про обнаруженные тобой глюки и поговорить-то будет не с кем.
В этом деле видимость очень важна. Чтобы ты очень хорошо понимал, что у тебя происходит на стыке софтвария и железа. Поэтому да, всякие хитрые сложные библиотеки только мешают. Рано или поздно возникает сомнение, что библиотека делает именно то, что велено (это еще хорошо, если ее интерфейс достаточно низкоуровневый и позволяет "велить"), и тут начинаются разборки, что там на самом деле написано.
И хорошо еще, если это библиотека. А не ядро, например, линуха
vsb>Впрочем для меня это далеко не профильное направление, поэтому допускаю, что это "синдром туриста". Но я реально отдыхаю душой, когда пишу на простом советском C, собираю проект простым советским make-ом, где всё просто как два плюс два. А не как в каком-то вебе, где один билд можно два дня настраивать. У нас ребята фронтэнд пишут, так у них в CI сборка по полчаса идёт и артефакты (образы) по паре гигабайтов вылазят. Какое-то безумие.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, dsorokin, Вы писали:
D>>Однако если так подумать, то тут сильная завязка на единую точку отказа, на бутылочное горлышко — удаленный сервер crates.io, который находится в неконтролируемой враждебной стране. Поэтому в час X вся эта красивая хрень может запросто перестать работать. Вопрос стоит не в том, произойдет ли это? Вопрос состоит в том, когда это произойдет?
Pzz>А в rust еще не завезли vendoring, как в Go?
Давно есть. Можно рассматривать как частный случай зеркалирования, когда все зависимости таскаешь с собой, а они не лежат где-нибудь в интранете в нексусе.
Здравствуйте, dsorokin, Вы писали:
Pzz>>А в rust еще не завезли vendoring, как в Go?
D>Давно есть. Можно рассматривать как частный случай зеркалирования, когда все зависимости таскаешь с собой, а они не лежат где-нибудь в интранете в нексусе.
Ну vendoring вроде решает проблему с недоступностью источника...
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, dsorokin, Вы писали:
Pzz>>>А в rust еще не завезли vendoring, как в Go?
D>>Давно есть. Можно рассматривать как частный случай зеркалирования, когда все зависимости таскаешь с собой, а они не лежат где-нибудь в интранете в нексусе.
Pzz>Ну vendoring вроде решает проблему с недоступностью источника...
Нет, конечно! Главное, что не решает саму проблему!
Скажу банальные вещи, но здесь нужна децентрализация в распространении библиотек, причем децентрализация с элементами той же сертификации или с элементами ответственности мейнтейнеров. Примерно так и происходит у дистрибутивов линукса, но для C и C++, а нужно для большего числа языков. Впрочем, мы приехали к тому, с чего начинали в этом чате
Мне кажется, что должно пройти время, которое осудит модель распространения библиотек с единым репозиторием. Они уязвимы по определению. Просто это время еще не пришло, не пришло массовое осознание, хотя первые шаги уже сделаны. Например, были всяко-разные инциденты у того же npm. Ладно, это не нам решать!
Здравствуйте, dsorokin, Вы писали:
Pzz>>Ну vendoring вроде решает проблему с недоступностью источника...
D>Нет, конечно! Главное, что не решает саму проблему!
Почему? Допустим, тебе нужна библиотека версии 1.1.0. Ты ее вендоришь и получаешь копию в свое дерево исходников. Дальшь даже если оригинал и пропадет, твоя завендоренная копия никуда не денется. В следующий раз оригинал тебе понадобится только когда захочишь версию библиотеки обновить.
D>Скажу банальные вещи, но здесь нужна децентрализация в распространении библиотек, причем децентрализация с элементами той же сертификации или с элементами ответственности мейнтейнеров.
Деценрализация нужна. На самом деле, ей довольно активно занимаются. Но она пока не достигла того уровня, чтобы потеснить общепринятые методы.
D>Примерно так и происходит у дистрибутивов линукса, но для C и C++, а нужно для большего числа языков. Впрочем, мы приехали к тому, с чего начинали в этом чате
Увы, вся эта децентрализация линуха, за редким исключением, сейчас помещается на github.com и gitlab.com.
А что, в расте все загрузки идут через централизованное место? В Go можно прям с гитхаба грузить (с любого git-овского репозитория).
D>Мне кажется, что должно пройти время, которое осудит модель распространения библиотек с единым репозиторием. Они уязвимы по определению. Просто это время еще не пришло, не пришло массовое осознание, хотя первые шаги уже сделаны. Например, были всяко-разные инциденты у того же npm. Ладно, это не нам решать!
npm, похоже, не контролирует ничего. Тот же Go, ему паленую копию внешней библиотеки не подсунешь, он будет против. И автоматического обновления внешней зависимости тоже не происходит, если я привязался к версии 1.1, что переход на 1.2 — это явное действие с моей стороны. Чего там в апстриме творится, автоматически ко мне не попадает.
Здравствуйте, Pzz, Вы писали:
Pzz>Почему? Допустим, тебе нужна библиотека версии 1.1.0. Ты ее вендоришь и получаешь копию в свое дерево исходников. Дальшь даже если оригинал и пропадет, твоя завендоренная копия никуда не денется. В следующий раз оригинал тебе понадобится только когда захочишь версию библиотеки обновить.
В rust можно и на github сослаться, и на локальную файловую систему, и можно залочить все зависимости на локальный подкаталог vendor, где будут лежать исходные коды всех зависимостей.
Pzz>npm, похоже, не контролирует ничего. Тот же Go, ему паленую копию внешней библиотеки не подсунешь, он будет против. И автоматического обновления внешней зависимости тоже не происходит, если я привязался к версии 1.1, что переход на 1.2 — это явное действие с моей стороны. Чего там в апстриме творится, автоматически ко мне не попадает.
Pzz>Я думал, в расте примерно так же.
Да, не. Версии фиксируются. Там файл есть Cargo.lock специальный для этого. При желании можно положить в git. Будет воспроизводимая сборка.
Проблем с удаленным репозиторием куча. Уверен, что любой выпускник специальности "информационная безопасность" выдаст целый список обоснованных доводов. Чего это мусолить? Это же очевидно
Здравствуйте, dsorokin, Вы писали:
D>Проблем с удаленным репозиторием куча. Уверен, что любой выпускник специальности "информационная безопасность" выдаст целый список обоснованных доводов. Чего это мусолить? Это же очевидно
Ну я достаточно хорошо понимаю, как это устроено, и особых проблем не вижу.
Очевидным обычно называют то, что не знают, как доказать
Здравствуйте, Pzz, Вы писали:
Pzz>Ну я достаточно хорошо понимаю, как это устроено, и особых проблем не вижу.
В качестве мозгового штурма для такого фантастического сценария, если вдруг Rust станет дико популярным.
Поставщик мог бы продавать свою собственную версию системы сборки cargo, которая бы использовала проверенное зеркало к crates.io и что-нибудь еще по усмотрению поставщика.
Тогда для потребителя была бы выгода в том, что в случае сертификации программы не нужно было бы сертифицировать то, что определено в таком зеркале. Да и без сертификации можно было бы, скажем, наклеить какую-нибудь иконку на сайте программы. Мол, смотрите — нам можно доверять!
Вот, при таком сценарии доверия к системе сборки Rust было бы у меня гораздо больше! А пока, очень интересно, офигительно красиво и изящно, но еще есть, над чем работать.
