Компания Google представила написанную на языке Rust платформу OpenSK, позволяющую создавать прошивки для криптографических токенов, полностью соответствующих стандартам FIDO U2F и FIDO2. Подготовленные с использованием OpenSK токены могут применяться в качестве аутентификаторов для первичной и двухфакторной аутентификации, а также для подтверждения физического присутствия пользователя. Проект написан на языке Rust и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52281
> Rusto_O
> ARM TrustZone
> дырявый USB для ключей
> дырявый Bluetooth для ключейTriple nenuzhno
> o_OТак хипстеров же понабрали, а фирмварь на го весила 10 мегов и микроконтроллера с таким встроенным флешом в гугле найти не смогли :)
>> ARM TrustZone
>> дырявый USB для ключей
>> дырявый Bluetooth для ключей
> Triple nenuzhnoНу вот кстати первое может быть и неплохой штукой. При условии что вы его смогли на свою сторону перетянуть и там _ваш_ secure monitor. А не чей-то мутный блоб, который мамой клянус, в самом привилегированном месте...
USB... ну блин в современных компах ничего внятного кроме него просто нет. А вот блутус для ключей и правда так себе затея.
Всё открыто, болтики, пластмасса для корпуса, шнурочек, резисторы в обвязке. Самая малость -- чипы закрыте, ну мы гугелю верим. Это ж Open!
> -- чипы закрыте, ну мы гугелю верим. Это ж Open!Во всяком случае, производителя чипов они выбрали одного из самых мутных.
"Ядро и драйверы в TockOS, как и OpenSK, написаны на языке Rust."usafe: 890
extern "C": 106
Low level programming сплошь и рядом unsafe, так как предполагает применение машинных инструкций, чтений/записи по сырым указателям на адреса в памяти и прочей низкоуровневой магии. Но, опять таки, поверх этого unsafe можно и нужно делать safe код, в чём раст и помогает.
safe построенный поверх unsafe автоматически превращается в тыкву. Т.о. главнпя мантра растофилов обнуляется, а запредельная сложность, кривой дизайн и уёбищный синтаксис остаются.
Зато запихнули какую-то операционку в стремный нордик, еще и с проприетарным беспроводным стеком небось, потребовался аж M4F навороченный... в общем все прелести hype driven development.
Safe код безопасен тогда, когда безопасна прослойка Unsafe снизу. Для прослойки Unsafe гарантии предоставляет программист, для Safe -- компилятор. Так, в отличие от С/С++, код разбивается на два множества, одно из которых корректно (с точки зрения языка), если корректно другое. Если твоя программа оказалась тыквой, то, скорее всего, именно ты виноват в некорректном коде в Unsafe. Никто не винит sudo за возможность удалить /, но почему-то многие винят Unsafe за возможность писать по рандомному указателю.
Можно подумать что в других языках по другому
Да все точно так же. Просто в расте оно явно разделено, ну и гарантий побольше за счет лайфтаймов. clang похожее умеет, но там нужно флаги подтыкать, да и на уровне языка не хватает конструкций.
> Можно подумать что в других языках по другомуНу, чо, в Ada классно придумали - аналог VLA сделать. Так что парой нехитрых действий можно поиметь грабель покруче сишников. При том те то хотя-бы догадываются с какой стороны грабли могут прилететь, а господа "за меня подумает компилер и рантайм" просто получают ручкой по затылку. ВНЕЗАПНО.
А можно поподробней? Что вы понимаете под "парой нехитрых действий можно поиметь грабель покруче сишников" и что такое "аналог VLA"?
Ну вот то - выделение памяти под массивы переменного размера в рантайме. И если этой фичой безбашенно попользоваться, например, из внешнего параметра формируемого фиг знает как, однажды все очень красиво загнется и вся надежность отправится лесом. При том зачем такой прострел пятки именно в аде - я так и не понял.
> Ну вот то - выделение памяти под массивы переменного размера в рантайме.Нет.
> И если этой фичой безбашенно попользоваться, например, из внешнего параметра формируемого фиг знает как, однажды все очень красиво загнется и вся надежность
> отправится лесом.То ли дело просто выделять память (подсказка: unconstrained массивы совершенно ни при чем) c внешнего фиг знает как формируемого параметра.
> - я так и не понял.
Это тут ключевое.
> Нет.Да. Можно делать выделение памяти без выделения памяти. Еще один баянный метод проверить что будет - сделать бесконечную рекурсию.
Кстати с последним вышел облом, я это под cortex M запилил, мне было интересно посмотреть как вообще сработает кастомный обработчик hardfault. А оно хренась и не падает?! Оказывается GCC шибко умный, заинлайнил все, на выделение стэка забил. Так что микроконтроль с мизером памяти наворачивает себе бесконечную рекурсию. Сюрприз!
> То ли дело просто выделять память (подсказка: unconstrained массивы совершенно ни при
> чем) c внешнего фиг знает как формируемого параметра.А на сях можно и не выделять. Ну вон на том мк вообще *alloc и free нету. И единственный способ таким манером пятку себе подстрелить - как раз поюзать VLA из C99. И собственно одна из причин по которой их не советуют - надежность снижают.
> Это тут ключевое.
Ну вы то как эксперт в управлении памятью нам ща урок грамотности дадите? :)
>> Нет.
> Да. Можно делать выделение памяти без выделения памяти. Еще один баянный метод проверить что будет - сделать бесконечную рекурсию.Нет. Для начала, определитесь: выделять или не выделять, потому что ранее вы сами же писали о "выделение памяти под массивы переменного размера в рантайме."
Повторю еще раз, для экспертов выделения без выделения и прочей диалектики: unconstrained массивы в Аде - не аналог VLA.> Кстати с последним вышел облом, я это под cortex M запилил, мне
> было интересно посмотреть как вообще сработает кастомный обработчик hardfault. А оно хренась и не падает?! Оказывается GCC шибко умный, заинлайнил все, на
> выделение стэка забил. Так что микроконтроль с мизером памяти наворачивает себе бесконечную рекурсию. Сюрприз!Очень интересно (нет) и познавательно (тоже на самом деле нет) - вы открыли для себя новые грани современной оптимизации компиляторами для бесконечной рекурсии и сделали вывод что "налог VLA" в Аду работает так же грабельно как и в GCC?
Еще раз, для экспертов по интересному смотрению: unconstrained массивы в Аде - не аналог VLA.
>> Ну вот то - выделение памяти под массивы переменного размера в рантайме.
>> например, из внешнего параметра формируемого фиг знает как,
> А на сях можно и не выделять.Так выделять или не выделять?
> Ну вон на том мк вообще *alloc и free нету.
Это прекрасно, но непонятные претензии были к Аде (потому что аноним решил, что фичи там должны быть реализованны так же, как в GCC)
Т.е. по вашему, реализация ады все равно вставит заглушки для выделения памяти и будет крешится или где?
Это не так:
http://docs.adacore.com/live/wave/gnat_ccg/html/gnatccg_ug/g...
> Dynamic Memory Handling
> The use of dynamic memory (access types, aka pointers) is supported by the
> GNAT Pro CCG compiler, and will generate calls to the standard C functions
> malloc() (for memory allocation) and free() (for deallocation). If dynamic
> memory is used in the Ada sources, then malloc() and possibly free() need to
> be provided by the C compiler.Идем далее - я так понял, тут был спры^W кейс сильно урезанного рантайма. Что ж:
https://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gna...
No_Allocators, -- This restriction ensures at compile time that there are no occurrences of an allocator.
No_Implicit_Heap_Allocations, -- (RM D.8(8), H.4(3))
No_Implicit_Loops,
No_Protected_Type_Allocators,
5.1.13. No_Anonymous_Allocators
[RM H.4] This restriction ensures at compile time that there are no occurrences of an allocator of anonymous access type.Или это был намек, что Адисты не Сишники, а значит – по умолчанию глупые и недалекие люди и не знают, где и как у них там выделяется память?
Позвольте и тут усомниться.>> Так что парой нехитрых действий можно поиметь грабель покруче сишников.
> И единственный способ таким манером пятку себе подстрелить - как раз поюзать VLA из C99. И собственно одна из причин по которой их не советуют - надежность снижают.Давайте без очередного спрыга с темы и самонахваливания, просто пречислите эти самые грабли в Аде.
>> Это тут ключевое.
> Ну вы то как эксперт в управлении памятью нам ща урок грамотности дадите? :)Хотя вы, как известный эксперт по необоснованным заявлениям, ценному мнению и дартаньянствованию, с последующим спрыгам с темы, уже соломки подстелили, приплетя тут МК и "вообще *alloc и free нету", так и быть:
https://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ug...
> The Secondary Stack
> GNAT returns objects from functions via registers (if small) or via the
> primary stack. For the latter, the caller of the function typically
> allocates space for the return object on its primary stack before the call.
> However, Ada allows functions to return objects of unconstrained types, for
> example unbounded array types such as String, and unconstrained
> discriminated record types
> In this case the caller does not know the size of the returned object at the point of the call.
> To resolve this problem, GNAT provides each task with a secondary stack that objects of unconstrained types are returned on. On native and cross targets using the full run-time, the secondary stack by default is allocated dynamically on the heap.Надеюсь, что такое "using full run-time" и каковы последствия, объяснять не надо?
На всякий случай, цитирую еще из возможных опций урезания рантайма:https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/s...
> No_Secondary_Stack
> [GNAT] This restriction ensures at compile time that the generated code does
> not contain any reference to the secondary stack. The secondary stack is
> used to implement functions returning unconstrained objects (arrays or
> records) on some targets. Suppresses the allocation of secondary stacks for
> tasks (excluding the environment task) at run time.Все еще с нетерпением ждем список граблей "круче и неочевидней" сишных.
>> Можно подумать что в других языках по другому
> Ну, чо, в Ada классно придумали - аналог VLA сделать.https://www.adaic.org/resources/add_content/docs/craft/html/...?
> Ada95
> The bounds of an array don’t have to be static; you’re allowed to calculate
> them at run time:
> Appts : Appt_Array (1..N); -- N might be calculated when the program is runЗаодно стырив машину времени!
> Так что парой нехитрых действий можно поиметь грабель покруче сишников. При том те то хотя-бы догадываются с какой стороны грабли могут прилететь, а господа "за меня подумает компилер и рантайм" просто получают ручкой
В чем именно "покруче" можно поиметь грабель? Или аноним, как обычно, слышал звон?
по другому, потому во всех других языках, кроме rust, безопасная часть - интерпретируемая или JIT-компилируемая (== более медленная чем нативный код)
Переведу просто безопасная часть становится небезопасной. Никакого профита раст не дает. Даже скорость разработки у него не выше.
По их логике если проект секурный - надо писать на расте. А для всего остального и сишечки хватит. Или же в гугле есть какая то тенденция использовать раст для всех новых проектов, а не только секурных и высоконадёжных?
Ну, если Rust из коробки способен обеспечить большую безопасность при той же скорости что и Си то конечно надо переходить на Rust.
Другое дело, что он не обеспечивает ни того ни другого. ИЧСХ, сравнивают всё время почему-то с много более простым, древним и реально могущим стрелять в ногу Си, но никогда - с современными плюсами.
На си тоже можно писать очень по разному. На микроконтроллерах так там зачастую вообще делают статичное распределение ресурсов. Когда если фирмварь вообще стартанула - она и работает как батарейка энержайзер. И тогда проблемы с освобождением памяти при отсутствии malloc и free как бы неактуальны - их нет как класса.И вообще, в МК чем проще фирмвара - тем надежнее и предсказуемее. Напихать черти-какую операционку, супе-яп и чего там еще - это создание себе проблем а потом героическое их "решение".
Современные плюсы тоже подвержены UB. И любому кто программирует на них, надо держать данный факт в голове. Компиляторы скорее всего покажут тебе warning по этому поводу, но в safe подмножестве раст категорически откажет компилировать такой код. Нужно ли это - каждый решает сам для себя.
Если выбирать быстрое и лёгковесное подмножество C++, то придётся избавится от шаблонов, наследований и прочей мишуры. Что по сути уже почти тупо Си. Просто придётся писать `new myShit()` `new_my_shit`, вместо `delete a` писать `my_shit_destroy(a)`, а вместо виртуальных методов (которых, кстати, тоже лучше бы не использовать в ряде случаев) делать указатели на функции (которые определяются в "конструкторе"). Что скорее просто лёгкое синтаксическое изменение.
Про указатели на функции поспешил. Есть и ряд других (более адекватных) вариантов. Зависит от того, зачем человеку в голову пришло использовать виртуальные методы.
А потом узнать что вся экосистема компонентов - жестко завязана на одну единственную мозиллу корп, со всей дури вляпавшись в вендорлок.Вендорлок настолько крутой что нельзя даже сделать измененный компилер и называть его растом. Это конечно "для вашего же блага", но где был бы си, если бы имела место такая политика? Там же где паскаль? :)
> Вендорлок настолько крутой что нельзя даже сделать измененный компилер и называть его растомТак раст и карго это торговая марка. От смены названия раст не перестанет быть растом в своей сути. Где тут вендорлок не совсем понимаю.
> Так раст и карго это торговая марка.Я уже видел как это работает на примере файрфокса и его дополнений. Очень не понравилось. Что-то не хочется чтобы меня так же можно было так же натянуть когда я програмлю, если без мозилабраузера я еще переживу, то вот резко менять програмерское окружение после какой-нибудь диверсии мозиллы - грабли.
> резко менять програмерское окружение после какой-нибудь диверсии
> мозиллы - грабли.В чём эта резкая смена будет заключаться? В смене названия языка)?
> В чём эта резкая смена будет заключаться? В смене названия языка)?В смене экосистемы, например. Очень не здорово когда репо с компонентами завязано на одну коммерческую фирму, особенно столь ушибленную как мозилла.
Про репо согласен. Но это скорее проблема для разработчика софта. И это проблема любого централизованного репо, будь то NPM, PyPi или даже гитхаб/гитлаб.
> А потом узнать что вся экосистема компонентов - жестко завязана на одну
> единственную мозиллу корп, со всей дури вляпавшись в вендорлок.Сказал анонимный аноним, а анонимному анониму можно верить!
> Вендорлок настолько крутой что нельзя даже сделать измененный компилер и называть его растом.
Избирательное восприятие - это прекрасно!
https://www.linuxfoundation.org/trademark-usage/
> A trademark provides the owner with an exclusive right to authorize or control the use of the mark. Your right to use a mark of The Linux Foundation is provided for in this policy and in the statement of permitted use, if any, that may accompany the trademark notice displayed on the website dedicated to the project. A copyright license, even an open source copyright license, does not include an implied right or license to use a trademark that may be related to the project developing the licensed software or other materials.Подсказываю: назови "anonims rust compiler" или "darustcompiler" или "zerustificator" и т.д.
> Это конечно "для вашего же блага", но где был бы
> си, если бы имела место такая политика?Для начала - давайте-ка компилятор "Си" в студию.
> Для начала - давайте-ка компилятор "Си" в студию.Ну пожалуйста. GCC? Clang? Мало? Ну пусть TCC будет, он C99 более-менее сделал. А тут только нечто от мозиллы, да еще с завязкой репо на них. В файрфоксе я уже этого счастья хлебнул, когда мало того что апи перекорежили так еще и фикшеные дополнения потом хрен поставишь, потому что все подписями облеплено без возможности самому (или автором) подписать. Еще не хватало чтобы в програминге меня так же приложили при случае.
>> Для начала - давайте-ка компилятор "Си" в студию.
> Ну пожалуйста. GCC? Clang? Мало? Ну пусть TCC будет, он C99 более-менее сделал.Опять в ход пошла демагогия.
Ну вот:
GNU Compiler Collection или его часть GNU project C compiler
Tiny C Compiler
Clang
ни одно "Си"-онли в названии. Это раз.Да и затрейдмаркить "C" наверное несколько сложновато. Вы попробуйте взять llvm (которая ™), "сделать измененный компилер"-бэкэнд и называть его LLVM.
Это два.И появились вышеперечисленные в 1987, 2005 и 2007. Это три.
> надо переходить на RustТипичное мнение математиков, те бесконечно изобретают велосипед вместо того, чтобы взять молоток и забить гвоздь.
Ага саморез микроскопом. Типичное слесаря.
> Ага саморез микроскопом. Типичное слесаря.Слесари как раз обычно догадываются отвертку взять. Иногда, правда, эти паршивцы закручивают обычным philips'ом какой-нибудь pozidriv, убивая и инструмент и шляпку, но это кой-как работает. В отличие от навороченных теоретических построений так и остающихся абстракциями и теориями.
ERC-20 токены я так смогу прошить?
Нет только то что идет из коробки.
> позволяющем избежать многих уязвимостей,...и добавляющим толпу новых. Начиная от использования мутных нордиков с черти-чем внутри и заканчивая жестким локом на мозиллу.
Нордики интересные девайсы, для изучения самое то. С учетом еще того, что не только блюпуп можно на них тестить. Другое дело, что рут кеи для секурюбута и прочих трастцелл радостей у них очень любопытно завязаны на неизвлекаемые самогенеренные ключи, которые почему-то привязаны к номерам партий чипов (в доках прямо написано, часть про руткей). То есть, для изучения - норм, для продакшена и безопасности - ни в коем случае
> Нордики интересные девайсы, для изучения самое то.Одна из самых вендорлокнутых фирм на планете, снискавшая себе известность прежде всего тем что выпустила чипы с ... вообще ни с кем не совместимой модуляцией. Не то чтобы чипы какие-то плохие, но на их примере все желающие смогли на примере своей шкурки узнать что такое вендорлок.
> Другое дело, что рут кеи для секурюбута и прочих трастцелл радостей у них очень любопытно
> завязаны на неизвлекаемые самогенеренные ключи, которые почему-то привязаны к номерам
> партий чиповИ потом совершенно случайно окажется что какой-то товарищмайор может секурно задампить все ключи. Так что парой undocumented все
> (в доках прямо написано, часть про руткей). То есть, для изучения - норм,
> для продакшена и безопасности - ни в коем случаеА смысл тогда изучать? Я вот STM32 изучил - он достаточно ОК как для изучения так и для продакшна. Во всяком случае, там нет мутных маловыполнимых гарантий, хз чьих ключей и прочего добра. Правда в F1xx и защита прошивки от дампа скромная. В Lxxx покрепче.
Ну и для хранения ключей имхо лучше как-то так: кладем их в backup ram, подпитываем батарейкой. Если товарисчмайор или злобный хацкер разбирает девайс чтобы считать чип, размыкается свич, питание с backup RAM слетает, от ключа остается дырка от бублика. Конечно в серийном, сильно популярном экспонате майоры могут и подготовиться к такому раскладу, но это надо чтобы девайс у каждого второго хомячка образовался...
Парни, а не подскажете брелок для PKCS11 с возможностью аппаратной генерацией ключей?
> Парни, а не подскажете брелок для PKCS11 с возможностью аппаратной генерацией ключей?На этом глобусе вроде бы нет железок которые _аппаратно_ так смогут. Фирмварно - пожалста, только фирмвара это всего лишь некий софт запущеный на мелком процике. И было бы очень кстати если бы это был открытый код, а не спидозное проприетарное черт знает что.
а я правильно понимаю, что для обхода подобных проблем и были написаны такие сервисы как rngd?
т.е. ключи генерируем используя сразу несколько генераторов случайных чисел?
> а я правильно понимаю, что для обхода подобных проблем и были написаны
> такие сервисы как rngd?С RNG вот какая проблема... когда комп только стартует, его состояние в целом может быть слишком предсказуемо и воспроизводимо! И когда кернель должен предоставить энтропию по запросам программ (например читающих /dev/random, /dev/urandom или дергающих аналогичный сискол) - будет очень не круто если это при каждой загрузке будет повторяться.
Потому что атакующий просто попытается подобрать состояние компа на момент генерации ключа. И есть довольно хороший шанс что угадает. Есть практические атаки такого плана, особенно на мелкие железки типа роутеров и виртуалки, где с энтропией на момент старта совсем душно.
А еще софт может хотеть много рандома и быстро. А где его столько взять, если в системе случайностей полторы штуки в час?!
Штуки типа RNGD...
1) прихранивают random seed накопленный за достаточно длительное время, так что при загрузке есть системе доступна какая-то не слишком предсказуемая энтропия.
2) может знать и использовать больше источников случайностей чем кернель, например какие-нибудь действия юзера типа времени нажатий клавиш или ADC какой-нибудь железки.На самом деле подобное и в кернель встраивают - но кернель все же по задумке не мегамозг а исполнитель запросов и поэтому настолько насыщенно жить собственной жизнью умеет лишь в довольно урезанном варианте. А отдельная программа разумеется может позволить себе больше всяких чудесатых вещей.
> т.е. ключи генерируем используя сразу несколько генераторов случайных чисел?
Т.е. для начала набираем энтропию из разных источников и храним ее между перезагрузками. Потому что именно генераторы истинно случайных чисел штука довольно ... своеобразная. Как максимум что-то такое можно получить если взять шум младших разрядов ADC, но даже так есть шанс что атакующий сможет на это повлиять. И не везде есть ADC. Поэтому программные генераторы являются генераторами ПСЕВДОслучайных чисел. И подстава в том что дав генератору псевдослучайных чисел один и тот же начальный SEED мы получаем одни и те же числа. Что очень удобно атакующему и совсем не удобно нам. И вот тут возникает вопрос - а где взять по настоящему случайные числа для инициализации ГПСЧ? Штуки типа RNGD помогают найти на него ответ.
Поддержка хардварного рандома - в правильном виде как раз нечто типа ADC читающего шум чего-нибудь полупроводникового, например. Однако проверить что оно делает именно это - можно разве что если вы сами сделаете именно это, именно так. А что вон тот интелский чип реально делает при таком запросе на рандом (RDRAND) - кто ж его знает? Может вообще совсем не это? (по поводу чего ядерщики резонно не доверяют на 100% такому механизму).
Обожаю Opennet не только за новости в ламповом стиле, но и за концентрацию могущественных разработчиков, которые всегда поясняют как надо правильно и на каком языке писать код всяким криворучкам из Google, Apple, Intel и тд. ;)
Ну, свою безопасность этим весельчакам (Google, Apple, Intel и т.д.) я бы не стал доверять во всем не разобравшись, пусть они хоть на Ada, хоть на Rust пишут. В конце концов, большая часть этих контор значительную часть дохода имеет на личных данных пользователей.А вот видя новости про Rust на opennet, я всегда напрягаюсь, потому что предчувствую уже, как местные эксперты начнут пеной исходиться. "Сишечка еще плюнет на могилку вашему расту", "одни хеллоуворлды - язык ни к чему не пригоден", "хруст никто не использует, кроме мамкиных хипстеров", "где мое наследование", "без unsafe ничего написать нельзя", "есть unsafe - значит все unsafe" и т.д.
Уже голова пухнет от этих однообразных вбросов. Хоть бы состав реплик как-то обновляли.
>большая часть этих контор значительную часть дохода имеет на личных данных пользователейТвои личные данные не стоят ничего, угомонись, мамкин эксперт, зарабатывают на рекламе. Второе - своими данными в гугле ты можешь, хотя бы, управлять, в отличии от Аппл. В реале ваши данные отлично сливаются во всяких мессенджерах, типо телеги и васяпа. И это в то время, когда в "зловещем гуголе", тыщу лет есть гуглталк, ныне Hangouts, которому даже ошейник (номер телефона) для использования не нужен. Только браузер и гуглоакк. Продолжайте сходить с ума.
Вы это мне? Просто мне показалось, что соломенному чучелу.> Твои личные данные не стоят ничего
У вас странные приоритеты. Для коропораций да, они ничего не стоят. Копейки, капля в океане. Для меня они стоят всего. Утечка моих данных никак не скажется на гугле, а мне может испортить жизнь. Почему я должен рассуждать о ценности своих данных с точки зрения корпораций, а не с собственной?
> зарабатывают на рекламе
Которая таргетируется на основе личных данных.
> В реале ваши данные отлично сливаются во всяких мессенджерах, типо телеги и васяпа.
Я что-то говорил про телегу или васяп? Они в одной куче с гуглом, яблоком и прочими друзьями.
И я даже не сказал, что этот проект гугла плохой - лишь то, что не поверю этим ребятам, пока не разберусь в деталях, вот и все.
> Твои личные данные не стоят ничего, угомонись,А зачем они тогда их тырят? Начиная с "резервной копии" пароля вайвая? Как-то не логично тырить то что ничего не стоит.
> когда в "зловещем гуголе", тыщу лет есть гуглталк, ныне Hangouts, которому
...которыз закрыли, с разморозкой :)
> даже ошейник (номер телефона) для использования не нужен. Только браузер и гуглоакк.Дык гугл по этому добру вас узнает лучше чем по номеру телефона. В браузере у них эвона сколько кукисов навешано и гуглоаналитикой отзондировано, так же шикарно ваш номер телефона сторонние сайты не отгружают, однако.
> Продолжайте сходить с ума.
Эксперты в треде, все в машину!
> Компания Google представила платформу OpenSK...
> Проект написан на языке Rust
> Ядро и драйверы в TockOS, как и OpenSK, написаны на языке Rust.По моему, начинается новая эра, господа, раз уж Гугол стал писать на Rust!
Опасно делать такие предположения здесь. Не стоит тут подвергать сомнению вечность и незыблемость C (можете очень осторожно похвалить какой-нибудь Zig, но большего вам не позволят), хех.
Я больше про Go.
Я сомневаюсь, что Rust прямо вытеснит Go, все же простота в изучении и малое число концепций - это рыночное преимущество. В вебе я вижу скорее симбиоз между Rust и Go. Например, натыкался на случай, как в одной компании Rust использовали для самого нагруженного сервиса, а остальное на Go.
Раст и го немного про разные вещи. Го больше любим питонистам и сишникам (не ++), так как эдакий си с некоторыми элементами питона, а с другой стороны компилируемый и быстрый по сравнению с питоном. Лично мне го кажется местами странным в сравнении с растом или питоном, ощущается влияние Роба и его команды беженцев из Plan 9. Простота го часто сваливается в примитивность, одни дженерики чего стоят, которые не добавиди так как их не любит Роб, хотя библиотечная функция make(), new() и некоторые другие по сути дженерик-функции без использования interface{}, просто эти дженерики внутри языка и недоступны "простолюдинам" и джунам для который язык создавался (можно найти эти дженерики в документации к пакету builtin).
Не зря же они Мозилле деньги отваливали.
> По моему, начинается новая эра, господа, раз уж Гугол стал писать на Rust!Чувак, зайди на гитхаб гуглы и посмотри на ЭТО. Половина репо - тупо карманные проекты програмеров. И там есть все, от makefile до vhdl.
Хорошая попытка Гугл, но нет.
Опасносте! Ужас! Моя приваси стоит дораха! Нед!
Ну так убери рутовый пароль со своей виндоуз хп раз тебе не надо.
> Ну так убери рутовый пароль со своей виндоуз хп раз тебе не надо.У него как у истинного хомяка беспарольный вход под админом :)
https://www.nitrokey.com/news/2018/nitrokey-pro-2-available
Лицензия как всегда...
Концлагерь Бухенвальд представил открытые квартиры для создания уютного гнёздышка.