Вот, ранее волю мирового правительства можно было узнавать через Wiki, том числе и русскоязычных статей. Вроде нейтрально должно быть, но на самом деле нет.
Сейчас намного удобнее слушаться белых господ — можно напрямую спросить у GPT.
Вот, по ЯП — прямо сказали не писать на C++ а писать на Rust. И если у GPT что-то спросить системное без указания языка — она выдаст обязательно код на Rust
Притом такая байка продвигается, что Rust делает разрабов счастливыми. Мол все просто и удобно, не то что в дедовском C++. Но по факту вы верите в это? Макросы ужасные, нет простого и понятного ООП. Умные указатели уже давно точно такие есть и в C++ а проверка владения работает топорно.
так, кто у нас теперь будет за rg45?
S>Притом такая байка продвигается, что Rust делает разрабов счастливыми. Мол все просто и удобно, не то что в дедовском C++. Но по факту вы верите в это?
отчего бы не верить? Верю.
S>Макросы ужасные,
ну и не лезте туда. template в C++ тоже мягко говоря не сахар, ну так он 95% разработчиков не нужен.
S>нет простого и понятного ООП.
ООП не нужен
S>Умные указатели уже давно точно такие есть и в C++ а проверка владения работает топорно.
примеры в студию, когда это проверка владения работает топорно.
Здравствуйте, Shmj, Вы писали:
S>Сейчас намного удобнее слушаться белых господ — можно напрямую спросить у GPT.
Надо же, с тобой мировое правительство прям разговаривает. Давно это с тобой?
S>Притом такая байка продвигается, что Rust делает разрабов счастливыми. Мол все просто и удобно, не то что в дедовском C++. Но по факту вы верите в это? Макросы ужасные, нет простого и понятного ООП. Умные указатели уже давно точно такие есть и в C++ а проверка владения работает топорно.
Я бы рискнул предположить, в нонешние времена язык делает его экосистема. У C++ она ужасная.
Pzz>Я бы рискнул предположить, в нонешние времена язык делает его экосистема. У C++ она ужасная.
Более того, я б сказал что ее вообще нет!
Есть набор отдельных инструментов сделанный разными людьми.
То ли дело Go — практически из коробки! Это меня просто впечатлило в свое время.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Shmj, Вы писали:
S>Притом такая байка продвигается, что Rust делает разрабов счастливыми. Мол все просто и удобно, не то что в дедовском C++. Но по факту вы верите в это? Макросы ужасные, нет простого и понятного ООП. Умные указатели уже давно точно такие есть и в C++ а проверка владения работает топорно.
Просто и удобно в C. Rust это для тех, кому надо код писать без багов. Лично у меня такой потребности нет, мне и с багами нормально. C++ просто не нужен.
Здравствуйте, LaptevVV, Вы писали:
Pzz>>Я бы рискнул предположить, в нонешние времена язык делает его экосистема. У C++ она ужасная. LVV>Более того, я б сказал что ее вообще нет!
Да, потому что это — архаичная экосистема Си родом из 70-х. Когда основным способом распостранения софтвария было "коллега поделился лентой с архивами".
Желающие могут попробовать протащить в linux свою программу, которая зависит от библиотеки, которая не входит в большую часть дистрибутивов линуха. Задолбаетесь, товарищи.
LVV>Есть набор отдельных инструментов сделанный разными людьми. LVV>То ли дело Go — практически из коробки! Это меня просто впечатлило в свое время.
У Go настоящий парсер настоящего языка входит в стандартную библиотеку. Ровно тот, которым пользуется компилятор. Поэтому всякая мелкая финтифлюшка, которая делает что-нибудь полезне с исходниками, реально понимает, что в них написано. А не пытается угадать с помощью этих, регулярных выражений.
Здравствуйте, vsb, Вы писали:
S>>Притом такая байка продвигается, что Rust делает разрабов счастливыми. Мол все просто и удобно, не то что в дедовском C++. Но по факту вы верите в это? Макросы ужасные, нет простого и понятного ООП. Умные указатели уже давно точно такие есть и в C++ а проверка владения работает топорно.
vsb>Просто и удобно в C. Rust это для тех, кому надо код писать без багов. Лично у меня такой потребности нет, мне и с багами нормально. C++ просто не нужен.
Как человек, написавший в разных проектах с полдюжины разных реализаций HTTP, скажу, что нет, в Си неудобно. Задалбывает очень HTTP писать.
Здравствуйте, Pzz, Вы писали:
S>>>Притом такая байка продвигается, что Rust делает разрабов счастливыми. Мол все просто и удобно, не то что в дедовском C++. Но по факту вы верите в это? Макросы ужасные, нет простого и понятного ООП. Умные указатели уже давно точно такие есть и в C++ а проверка владения работает топорно.
vsb>>Просто и удобно в C. Rust это для тех, кому надо код писать без багов. Лично у меня такой потребности нет, мне и с багами нормально. C++ просто не нужен.
Pzz>Как человек, написавший в разных проектах с полдюжины разных реализаций HTTP, скажу, что нет, в Си неудобно. Задалбывает очень HTTP писать.
Почему? Могу только предположить, что из-за отвратительной стандартной библиотеки. Но вроде есть библиотеки получше?
Здравствуйте, vsb, Вы писали:
Pzz>>Как человек, написавший в разных проектах с полдюжины разных реализаций HTTP, скажу, что нет, в Си неудобно. Задалбывает очень HTTP писать.
vsb>Почему? Могу только предположить, что из-за отвратительной стандартной библиотеки. Но вроде есть библиотеки получше?
Ну во-первых, не очень-то есть. А во-вторых, они имеют тенденцию очень подминать проект под себя.
Дело не только в стандартной библиотеке. Вся экосистема очень не очень. Начиная прам со сборки. Чтобы собрать программу, надо написать программу для сборки программы на каком-нибудь левом языке, типа Makefile, Cmake и т.п.
Особенно круто становится, когда в одной программе встречаются запчасти разного происхождения, с разными идеями о том, как их собирать. Или когда целевая платформа не какая-то одна, а зоопарк разных.
Здравствуйте, Alekzander, Вы писали:
Pzz>>Я бы рискнул предположить, в нонешние времена язык делает его экосистема. У C++ она ужасная.
A>Что такое "экосистема C++"?
В двух словах и не объяснить. Но опытные ребята, они меня поняли.
Здравствуйте, Pzz, Вы писали:
Pzz>Дело не только в стандартной библиотеке. Вся экосистема очень не очень. Начиная прам со сборки. Чтобы собрать программу, надо написать программу для сборки программы на каком-нибудь левом языке, типа Makefile, Cmake и т.п.
А где не так?
Pzz>Особенно круто становится, когда в одной программе встречаются запчасти разного происхождения, с разными идеями о том, как их собирать. Или когда целевая платформа не какая-то одна, а зоопарк разных.
Запчасти это зло. Надо всё писать самому, а не превращать програмирование в какое-то склеивание готовых модулей на скотче и синей изоленте. Есть исключения, которые самому писать слишком сложно, но зачастую это просто страх неизвестности. Я вот сейчас пишу USB-стек и там всё очень просто, я боялся это делать, т.к. у меня было некое представление о том, что этим только боги занимаются, но реально там всё в железе реализовано, от программиста нужны простейшие обработчики, мелочь по сути. Да, стек не универсальный, так мне и не надо универсальный.
Здравствуйте, vsb, Вы писали:
Pzz>>Дело не только в стандартной библиотеке. Вся экосистема очень не очень. Начиная прам со сборки. Чтобы собрать программу, надо написать программу для сборки программы на каком-нибудь левом языке, типа Makefile, Cmake и т.п.
vsb>А где не так?
Go, вроде бы Rust.
Pzz>>Особенно круто становится, когда в одной программе встречаются запчасти разного происхождения, с разными идеями о том, как их собирать. Или когда целевая платформа не какая-то одна, а зоопарк разных.
vsb>Запчасти это зло. Надо всё писать самому, а не превращать програмирование в какое-то склеивание готовых модулей на скотче и синей изоленте.
Надо. Но где-то после пятого раза начинает очень задалбывать HTTP опять писать
vsb>Я вот сейчас пишу USB-стек и там всё очень просто, я боялся это делать, т.к. у меня было некое представление о том, что этим только боги занимаются, но реально там всё в железе реализовано, от программиста нужны простейшие обработчики, мелочь по сути. Да, стек не универсальный, так мне и не надо универсальный.
Настоящее веселье у тебя начнется, когда из-за багов в железе, которые от тебя не зависят, у тебя что-нибудь будет не работать. А в соседнем линухе (или венде) будет работать.
А так-то да, пока по спецификации пишешь и железо ту же самую версию спецификации читало, что и ты, все выглядит просто
Здравствуйте, Pzz, Вы писали:
Pzz>>>Я бы рискнул предположить, в нонешние времена язык делает его экосистема. У C++ она ужасная.
A>>Что такое "экосистема C++"?
Pzz>В двух словах и не объяснить. Но опытные ребята, они меня поняли.
У меня в голове есть своё представление об "экосистеме C++". Хотелось бы понять, насколько оно совпадает с твоим.
Если нам не нравится одно и то же, это хорошо. Если разные вещи, это зависит. А если тебе не нравится как раз то, что нравится мне, это совсем плохо.
Про что ты? Про стандартную библиотеку? Что программисты на нём токсики? Или что нет npm?
Много назад некие супер-умы указали: все серьезное и надежное надо обязательно писать на Аде. И что? На самом деле те, кто повелся, в результате все равно через много лет ушли на C/C++ по многим причинам в том числе и потому, что Ада уж очень специфическая, библиотек мало, поддержка мало где есть, да самих прогеров, знакомых с ней на уровне писания кода а не читания книг, почти нет. Да и сам язык УГ. Ну их комитеты еще ковырялись в языке и синтаксе его, выдали новую Аду и еще вроде одну, добавили ооп! Но в целом хрень же.
Rust пока представляет собой Аду версия 2.0. Те же крики ах и ох! Но у Ады хоть компиляторы коммерческие были (по цене амтомобиля) а здесь что? Судя по всему у Rust есть только какая то вещь в прогрессе. Интересно поддержка компилятора хоть есть или типа — пиши вопрос в интернет может кто-то знает почему не компилится или медленно или еще что? Может когда-то Rust и взлетит но сейчас похоже он еще и не на взлетной полосе.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, vsb, Вы писали:
Pzz>>>Дело не только в стандартной библиотеке. Вся экосистема очень не очень. Начиная прам со сборки. Чтобы собрать программу, надо написать программу для сборки программы на каком-нибудь левом языке, типа Makefile, Cmake и т.п.
vsb>>А где не так?
Pzz>Go, вроде бы Rust.
Палка о двух концах. Это, конечно, удобно, когда все зависимости подтягиваются сами, и когда все собирается само лишь по одной волшебной команде "cargo build --release" — как будто произносишь волшебное заклинание, когда "оно само". Офигенно круто! Слов просто нет! Для неофитов самое то, чтобы привлечь, заинтриговать!
Однако если так подумать, то тут сильная завязка на единую точку отказа, на бутылочное горлышко — удаленный сервер crates.io, который находится в неконтролируемой враждебной стране. Поэтому в час X вся эта красивая хрень может запросто перестать работать. Вопрос стоит не в том, произойдет ли это? Вопрос состоит в том, когда это произойдет?
Есть зеркалирование, но насколько оно распространенно? И насколько оно удобно? Насколько оно действительно защищает?
По своему это даже хорошо, что в плюсовых проектах часто зависимости таскают с собой или берут из дистрибутива. Неудобно, конечно, но надежнее.
А так, Rust как язык мне очень нравится. Тем более, мне как хаскелисту с опытом на языках ФП, в том числе, с коммерческим опытом.
Тут еще один момент. Насколько проекты Rust соберутся на компьютерах с маленьким ОЗУ? Сильно сомневаюсь, что соберутся. Правда, на С++ программы с большим количеством шаблонов тоже не соберутся, но если брать базовый язык, то шансы есть, что программа на C++ вполне соберется на компьютере с малым количеством ОЗУ — это наследие технологий родом из 70-х. Насколько актуально это в 2024 году — да фиг знает!
И еще один момент. Шаблоны компилятор C++ толком и не проверяет — это by-design, так было задумано. А вот Rust обобщенный код проверяет. За это Rust особенно ценю. С обобщенным кодом в Rust работать много-много проще, просто в разы!
Здравствуйте, dsorokin, Вы писали:
D>Однако если так подумать, то тут сильная завязка на единую точку отказа, на бутылочное горлышко — удаленный сервер crates.io, который находится в неконтролируемой враждебной стране. Поэтому в час X вся эта красивая хрень может запросто перестать работать. Вопрос стоит не в том, произойдет ли это? Вопрос состоит в том, когда это произойдет?
А в rust еще не завезли vendoring, как в Go?
D>Есть зеркалирование, но насколько оно распространенно? И насколько оно удобно? Насколько оно действительно защищает?
Ну, в любом нормальном проекте, "официальная", автоматизированная сборка будет делаться на компьютере, не подключенном к сети. Т.е., какое-то локальное кеширование внешних репозиториев так или иначе предусмотрено.
D>Тут еще один момент. Насколько проекты Rust соберутся на компьютерах с маленьким ОЗУ? Сильно сомневаюсь, что соберутся. Правда, на С++ программы с большим количеством шаблонов тоже не соберутся, но если брать базовый язык, то шансы есть, что программа на C++ вполне соберется на компьютере с малым количеством ОЗУ — это наследие технологий родом из 70-х. Насколько актуально это в 2024 году — да фиг знает!
У rust-овского компилятора backend-ом работает LLVM. Как и у половины C++-ных компиляторов. Так что полагаю, требования к сборочному компьютеру у них плюс-минус сравнимые.
Да и что есть компьютер с маленьким ОЗУ? 8 гигов — это маленькое или не маленькое? А 16?
Здравствуйте, Pzz, Вы писали:
Pzz>>>Дело не только в стандартной библиотеке. Вся экосистема очень не очень. Начиная прам со сборки. Чтобы собрать программу, надо написать программу для сборки программы на каком-нибудь левом языке, типа Makefile, Cmake и т.п.
vsb>>А где не так?
Pzz>Go, вроде бы Rust.
На Go по-моему любой нетривиальный проект собирается через make. По крайней мере я таких видел достаточно.
Сам компилятор:
To build the Go distribution, run
$ cd src
$ ./all.bash
Я не могу сказать, что мне нравится текущая ситуация со средствами сборки, но она по-моему везде плохая...
vsb>>Я вот сейчас пишу USB-стек и там всё очень просто, я боялся это делать, т.к. у меня было некое представление о том, что этим только боги занимаются, но реально там всё в железе реализовано, от программиста нужны простейшие обработчики, мелочь по сути. Да, стек не универсальный, так мне и не надо универсальный.
Pzz>Настоящее веселье у тебя начнется, когда из-за багов в железе, которые от тебя не зависят, у тебя что-нибудь будет не работать. А в соседнем линухе (или венде) будет работать.
Всё может быть, но возможность эта гипотетическая.
А вот реальная ситуация. Товарищ написал прошивку, как раз используя библиотеку. В итоге под виндой она работала глючно. Вытаскиваешь девайс из порта, вставляешь заново — винда его не видит, он как бы зависает. Вставляешь в другой порт — видит (симптомы могу путать, это пару лет назад было, но примерно так), потом по таймауту там чего-то отлипало. Как чинить — не понятно, ну точней понятно — лезть в USB-анализатор и исходники библиотеки и всё дебажить, но это как бы сложно... Когда весь код для работы с USB это полторы тысячи строк в одном файле, из которых половина это константы дескрипторов и логгирование, тут уже попроще, можно и подебажить.
Ну и баги железа, как правило, в Errata есть, по крайней мере если железо достаточно старое. Почитать несложно.
Здравствуйте, vsb, Вы писали:
vsb>А вот реальная ситуация. Товарищ написал прошивку, как раз используя библиотеку. В итоге под виндой она работала глючно. Вытаскиваешь девайс из порта, вставляешь заново — винда его не видит, он как бы зависает. Вставляешь в другой порт — видит (симптомы могу путать, это пару лет назад было, но примерно так), потом по таймауту там чего-то отлипало. Как чинить — не понятно, ну точней понятно — лезть в USB-анализатор и исходники библиотеки и всё дебажить, но это как бы сложно... Когда весь код для работы с USB это полторы тысячи строк в одном файле, из которых половина это константы дескрипторов и логгирование, тут уже попроще, можно и подебажить.
Не, я не критикую твое решение сделать все руками. Просто, хм, сложности не в этом. А сейчас — ну почему бы и не сделать себе приятное?
vsb>Ну и баги железа, как правило, в Errata есть, по крайней мере если железо достаточно старое. Почитать несложно.
Здравствуйте, 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 было бы у меня гораздо больше! А пока, очень интересно, офигительно красиво и изящно, но еще есть, над чем работать.
