Мне вот интересно - а вариант с запуском системы под гипервизором (с пробросом видеокарты) для читерства не используется?(конечно с маскировкой факта что это виртуалка если античит триггерится)
Давно уж что читы, что античиты для топовых competition-игр прописались в гипервизоре. И ничего не нужно пробрасывать, "полноценный" kvm излишен. Продвинутые форумные скрипт-киддисы пишуткачают с гитхаба элементарные "hello world"-гипервизоры резидентного драйвера дырявого UEFI, ОС грузится напрямую на железе с маппингом в гипервизор 1-к-1, и творится вакханалия а-ля БСОДы, ошибки загрузки системы и прочий треш.
С UEFI проблема намного серьёзнее дырявых дров винды, т. к. вендоры исправляют уязвимости в своих реализациях UEFI приблизительно никогда.
Или так сложнее потому что patchguard?
PatchGuard точно так же обходится в процессе загрузки ядра, когда средствами гипервизора составляется карта процессов, потоков и замапленных регионов памяти ОС. Так сложнее, потому что надо потратить время, чтобы разбираться в работе ОС и гипервизорах, а нагибать нубов надо прямо сейчас.
Гипервизоры это ещё полбеды. Существуют приватные коммерческие читы для "профессиональных стримеров", представляющие из себя аппаратный DMA-модуль с программной обвязкой-фреймворком, которая может скастомизировать железку под себя так, что каким бы крутым ни был античит, он не сможет заподозрить, что память читается сторонним устройством. Да, цены таких девайсов $10к+, но блогерычитеры-милионники могут себе позволить.
Не поверите, но за всю жизнь написал всё же больше кода на Си и С++, нежели на Расте.
называть неадекватами профессионалов лишь за то что они используют инструмент который вам не нравится
Да мне ваще параллельно на то, что кому нравится. И Си, и Плюсы, и Раст сам использую по мере надобности без лишних слов. А говорю лишь об упёртости и не желании смотреть в будущее, страхе смерти своего лампового Сишечки. Раст -- это же страшно, это для зумеров, его читать невозможно, а писать так вообще -- руки отсохнут!
Примерно как сравнить людей, кто боится летать самолётом и ездит поездом, убеждая всех вокруг, какие опасные и дорогие самолёты. Да, оба будут в одной и той же точке рано или поздно. Оба достигнут цели, но тот, кто летел на самолёте ещё успеет погулять, поспать, поработать, пока второй ещё катится по рельсам своего комфорта и стабильности, ковыряясь в дебагере, где у него там чего случилось.
Я искренне хочу услышать от людей, кто серьёзно взялся за Раст и с уверенностью может сказать, что технология гавно и не подходит для его задачи. Очень хотел бы посмотреть я на эту задачу и этих "профессионалов". Но обратных же примеров куча. Подавляющее большинство тех, кто взялся за Раст, теперь за уши от него не оттянуть =)
А уж право решать, кто тут быдло, оставлю вам, простите.
Это довольно абсолютные цифры. Мне кажется, не стоит их учитывать в отрыве от зрелости языка. Раст более-менее стабилизировался и получил популярность только к 2018-й версии, а это всего лишь 5 лет. Менее 5-ти лет стало достаточно для того, чтобы инертные топовые мировые гиганты, которые один надоедливый, всех бесящий баг могут фиксить годами, внезапно увидели в Расте потенциал и массово начали на нём писать свои проекты. Только эти факты дорогого стоят, чтобы судить об успешности технологии.
Гугл в конце 22-го года проводил исследование. С внедрением Раста количество уязвимостей упало на 25%, количество падений из-за повреждения памяти -- на 70%! А это десятки миллионов долларов в их масштабах. И сэкономленные нервы пользователям.
То, что это появилось в те времена, когда не было альтернатив, не говорит о том, что эти языки до сих пор незаменимы. Да, изучение нового требует ресурсов: времени, средств, остановки маховика инетрности и изменения направления парадигм мышления. Я с этим ни сколько не спорю, я спорю с конкретными формулировками этой ветки коментариев вида "С++ незаменим", "невозможно игры писать на чём-то ещё", "кроме Си и С++ ничего не нужно" и подобными риториками прошлого тысячелетия, когда был один язык, один компилятор и непреодолимое чувство творчества.
еще и разбираться как сторонние библиотеки подключить чтобы компилятор был доволен
У раста ffi-библиотеки любой сложности из коробки собираются и линкуются, ни с чем не нужно разбираться. Сам, когда несколько лет назад учил язык на низкоуровневом хобби-проекте, без проблем и бубнов встроил огромные проекты: язык Dart с его фреймворком Flutter. Сейчас же, с опытом, обернуть либу, для которой внезапно нет готового пакета, занимает пару часов.
никуда он от нас не денится, еще нашим внукам останется
В плане чтения кода на Си, я согласен, он будет жить ещё очень долго, но писать на нём уже мало кто решается.
Взять тот же Гугл, Майкрософт, Фейсбук, Cloudflare, Amazon. Откройте их крайние репозитории, начатые в течение последних 3 лет. Ни ОС, ни драйверов, ни системных утилит, ни реализаций стека протоколов, почти никто из них не начинал писать на Си. Зато референсные реализации того же WASM, WebGPU написаны на Раст. Ядро HTTP3, протоколы QUIC и WireGuard у Cloudflare реализованы на Раст. В Андроиде на Rust написаны стек Bluetooth, NFC, HAL, гипервизор. Новая гугловская KataOS полностью написана на Раст, включая ядро и драйверы, а в Fuchsia половина кода на нём уже. Майкрософт усиленно пилит биндинги для Windows SDK под Раст.
Не знаю, может быть я это замечаю только потому, что я плотно занимаюсь языком уже несколько лет, но по-моему тренды довольно показательны.
постоянно зависаю с интеграционными работами
Странно, по-моему мнению, тулчейн и экосистема Раста -- лучшее, с чем приходилось работать за всю кодерскую жизнь.
Перечисленные вами факты -- исключительно историческое наследие.
Я это написал, ответив на фразу "заменить их никак не получается". Вот мне и интересно, у кого не получается? У комментатора? У тех, кто не пробовал? Инертность, "трушность"? Так это тогда не проблема языка, а проблема тех, у кого не получается. Кто осилил закопать это гавно мамонта, у тех более чем получается. Ни один адекватный человек сейчас не начнёт новый проект на Си, если только не религиозный фанатик.
Всё, что осталось хорошего от Си, так это его универсальный ABI, который, кстати, тоже сложился в "стандарт" де-факто сугубо исторически. Остальное давно уже можно безболезненно закопать.
Не знаю, как в этих ваших столицах, но в Ростове-на-Дону за всё время существования сервиса ровно 2 (два) раза на моей памяти Ситимобил был дешевле ЯндексУберов. В других городах, где был ДиДи, тот был самым дешёвым, Яндексубер на втором месте, а Ситимобил всегда был самым дорогим. Совсем неадекватно дорогим, иногда в 2-2.5 раза!
Контингент водил в регионах у них тоже был а-ля вчера с зоны откинулся, сегодня таксовать поехал.
В универское время знал людей, которые там работали. Тогда они просто брали проекты на Апворке с некислыми рейтами, нанимали недавно закончивших универ студентов, платили им 10-20к деревянных в месяц. При этом, от работников даже не скрывали их рейт, что они на самом деле зарабатывают несколько тысяч долларов, а получают на шаурму и проезд туда-обратно.
Тех немногих, кто заподозревал неладное и уходил от рабовладельца на тот же апворк, кидали, не выплачивали остаток. В случае частых вопросов на тему "когда выплатят?", получали угрозы, типа если в себе так уверен, приезжай в офис, забери коль сможешь. А вы про какой-то ТК. Ну-ну =)
Шёл 2022-й год. Ничего не менялось. Если они до сих пор живы, значит спрос на подобные унижения у студентов до сих пор велик. Неужели в годы такого информационного изобилия все настолько отчаялись. Можно ж уже чуть ли не в ютубе учиться кодить теперь.
Примерно такой же использую в качестве роутера, только помощнее. i5-8365U, 4G, SSD 128G
С максимальным тюнингом под энергосбережение жрёт где-то 6.5Вт в Idle. Ну, то есть, даже когда гигабит через себя пропускает, он по сути в Idle находится, энергопотребление максимум до 7-8Вт повышается.
Да, оверкилл, но помимо роутера ещё используется в качестве "домашней лаборатории" под виртуалки, различные сервисы, разработку и т.п.
Возможно, современная ситуация получше, но когда пару лет назад сталкивался, из своих проектов максимум 10% мог собрать gnu тулчейном без бубна.
ПС. Сейчас погуглил. Похоже, что ситуация заметно лучше стала с появлением WLS, который явно поспособствовал развитию тулчейна. Во времена, когда я пытался, с этим был какой-то треш.
Да что ж всем так интересны сексуальные извращения.
Как я написал в соседней ветке, gnu toolchain был создан в винде исключительно для кросскомпиляции. 4 гигабайта диска настолько дорого стоят, чтобы тратить нервы на боль и страдания?
А также это нужно тем кто хочет использовать Rust но не имеет лицензии на MSVC.
Для проектов с открытым кодом или команд до 5 человек лицензия на MSVC не нужна, что покрывает большинство потребностей.
Если будет возможность слинковать статически, то не придётся. Например, HelloWorld слинковать можно.
Но в серьёзных проектах такого почти не встретится, потому что GNU ABI предполагает динамическую линковку по умолчанию. Множество либ вообще не предназначено для статики. Натрахаетесь со всякими PIC, релоками, и прочими радостями линковки.
Это всё -- если у вас нет рантайм ABI-bound взаимодействия, иначе -- много разнообразного секса будет.
Мб потому что в Винде используется Windows ABI, а не GNU'сный?
Как вы предлагаете линковать либы, например, из современной SDK/WDK? Я вообще не уверен, что gnu бандл содержит адекватные хотя бы основные либы для виндовых фич. Последний раз, когда сталкивался пару лет назад, там было говно мамонта времён раннего pre SP3 Windows XP.
Если вам достаточно gnu тулчейна, значит вы HelloWorld'ы компилите без внешних платформенных зависимостей. Ну или сраные блокчейны с бекендами, перекладывающими байтики, тоже вполне соберутся. А что-то полезное под современную 10/11 винду типа драйверов или системных утилит им никак не слинкуешь.
gnu тулчейн под винду изначально создавался для кросс-компиляции, а не извращений.
Когда будут туториалы "Как включить компьютер", "Как установить Виндавс"?
Если уж на то пошло, то советуйте Even Better TOML вместо Better TOML, который заброшен и не поддерживается уж 4 года как.
Для подсветки синтаксиса и автодополнений есть два наиболее популярных расширения: Rust и rust-analyzer. Они работают немного по-разному и конфликтуют между собой. Я не буду глубоко разбирать, в чём у них различия, но rust-analyzer работает лучше, по тому берём его.
Различия у них в том, что vscode-rust больше года назад забросили, а позже вообще объявили deprecated в RFC2912. Оно не "плохо работает", оно вообще больше не разрабатывается. rust-analyzer ожидается в stable toolchain вместо RLS.
Без проблем всё пробрасывается с одной видеокартой, 5 лет почти сидел на такой системе.
Не знаю как сейчас, но раньше достаточно было выгрузить родной драйвер GPU, отдетачить нулевую vtconsole и разбиндить efi-framebuffer. При этом монитор изчезает, отлаживать можно через ssh. Потом, для каждого пробрасываемого устройства, разбиндить его драйвер и сразу же забиндить vfio-pci модуль на этот vid:did.
Чтобы вернуться в хост, нужно повторить всё в обратном порядке. Раньше даже автодетект работал, не нужно было запоминать прошлый драйвер. Была одна лишь проблема: USB-контроллеры были у меня дванольные, а третьих не было, либо были какие-то драфтовые, без реализованного hci reset, который при возврате в хост происходит. Из-за этого какое-то устройство могло остаться в потустороннем мире до перезагрузки. Решалось перетыкиванием девайсов в те контроллеры, которые умели reset. Сейчас, подозреваю, везде уже xhci, с его возвратом из забвения в реальность проблем вроде как нет.
И, кстати, не нужно ничего хардкодить ни в ядро, ни патчить, всё без проблем динамически делается, в отличие от сказанного в статье. Достаточно разобраться в проблеме, а не нагрести с форумов копипаста, как сделал автор и запилить очередную говностатью.
По поводу производительности. Имелась в те времена карточка GTX1070. По тестам на ФПС при максимальном тюнинге всех возможных параметров были потери порядка 2-3%. Основная проблема была в инпут-лаге. Если задротить в компетишн шутеры, заметна была "аквариумность". Есть вероятность, что в соврмеренных процах поменьше VM-exit'ов происходит на каждый чих, поэтому лаг может быть чуть предсказуемее.
Статья так себе, если честно. Основной смысл работы в такой системе как раз в файн-тюнинге.
Например, выделить память гостю можно через Huge Pages, чтоб поменьше дёргать страничный транслятор. Отключить merging страниц на худой случай, если huge pages против религии.
Вынести IO в отдельный тред, и запинить афинити чтобы, хоть и редкими, но локами, не снижать latency.
Отстроить маппинг очередей virtio-scsi, нативный TRIM, выключить промежуточные кеши. А ещё лучше заморочиться с vhost.
И ещё несколько десятков оптимизаций, которые уменьшат суммарный оверхед до пары процентов.
Для удобства выделения диска отлично подходит LVM thin provisioning: динамический ресайз, снапшоты и т. п. Хотя перформанс просаживал в несколько раз, когда юзал.
По сути, написали на том же Си, но с синтаксисом другого языка, абсолютно не разобравшись в языке.
unsafe в этом случае нужен для того, чтобы сделать safe-обёртку, RAII и т.п. Ваш же код ни на йоту не безопаснее кода на Си. Даже наоборот: unsafe во всех местах, а не в конкретных идиоматических -- верный генератор UB похлеще С++.
Что-то поменялось? windows-rs всегда без проблем работал со stable.
в нём есть библиотека bindings. Цель этой библиотеки — подключать зависимости для того, чтобы вы могли работать с Windows API в вашем приложении.
Цель этой библиотеки -- вынести биндинги в отдельный юнит для компилятора, чтобы каждый раз не запускать кодогенерацию и компиляцию. И не подключает она никаких зависимостей, она генерирует из метаданных обёртки, типы и адаптеры для удобного вызова extern функций. И да, это не биндинги в привычном их понимании, а именно wrapper'ы, которые, по опыту использования, очень хреново инлайнятся и кучу неявных side-эффектов генерят. Например, получая адрес функции, получаешь адрес незаинлайненного thumb wrapper'а, даже если фактический вызов заинлайнился, то есть, по сути, адрес мёртвого кода. При этом адрес получить можно только полным повторным extern fn объявлением для каждой WinAPI функции. Конечно, адреса нужны не всегда, но иногда нужно и много, не зря же Раст -- всё таки системный низкоуровневый язык.
Это — вызов макроса, который подключит все необходимые зависимости.
Опять таки, никаких зависимостей он не подключает, а просто инлайнит сгенерированный из метадаты исходник на Расте из стандартной директории выхлопа генератора.
Первое — функция main теперь должна возвращать windows::Result<()>
2. fn main должна возвращать результат, понятный Windows
Не выдумывайте, откуда вы взяли такое требование? main может возвращать любой тип, который реализует трейт std::process::Termination, хоть пустую юнит-стуктуру делайте и возвращайте из неё 42, никто не запрещает. Похоже, вы скопипастили из примеров код, не разобравшись, зачем там этот тип указан. А указан он для использования оператора ? на std::ops::Try-типах, то есть там, где возвращается либо COM'овский Result, содержащий WinRT'шную ошибку, либо растовый Result, полученный через какой угодно метод конвертации. Вы же ни разу этот оператор не использовали, значит тип возврата main тут не причём и может быть любым impl Termination.
Пишете, что нужно везде использовать W-версии функций, а сами используете A-версии.
deprecated же. RegisterClassEx сейчас рекомендуется использовать.
HWND(0)
То, что HWND == NULL и HWND == 0 имеют одинаковые значения -- чисто случайное implementation defined совпадение и потенциальное UB. В windows-rs трейт std::default::Default мапится на NULL handle.
extern "system" fn wndproc(...){ unsafe{...
Вся функция здесь -- unsafe. Нужно не блок внутри функции делать unsafe, а всё extern-объявление, ибо unsafe интерфейс и unsafe реализация -- разные вещи.
match message as u32
В чём сакральный смысл конвертации u32 в u32?
MessageBoxA(None, "Привет", "Это игра 2048 для Хабры", MB_OK | MB_ICONINFORMATION );
Поэтому нам не нужно извращаться и писать что-то типа:
MessageBoxA(std::ptr::null_mut(), ...
Здесь не стоит путать ABI указателя на ffi функцию и его мапинг из Option'а с костылём, который придумали в windows-rs. Это совершенно разные вещи. Из коробки работает толькоOption<extern fn()>. Другие типы без бубнов так не работают, нужны обёртки из трейтов.
Давно уж что читы, что античиты для топовых competition-игр прописались в гипервизоре. И ничего не нужно пробрасывать, "полноценный" kvm излишен. Продвинутые форумные скрипт-киддисы
пишуткачают с гитхаба элементарные "hello world"-гипервизоры резидентного драйвера дырявого UEFI, ОС грузится напрямую на железе с маппингом в гипервизор 1-к-1, и творится вакханалия а-ля БСОДы, ошибки загрузки системы и прочий треш.С UEFI проблема намного серьёзнее дырявых дров винды, т. к. вендоры исправляют уязвимости в своих реализациях UEFI приблизительно никогда.
PatchGuard точно так же обходится в процессе загрузки ядра, когда средствами гипервизора составляется карта процессов, потоков и замапленных регионов памяти ОС. Так сложнее, потому что надо потратить время, чтобы разбираться в работе ОС и гипервизорах, а нагибать нубов надо прямо сейчас.
Гипервизоры это ещё полбеды. Существуют приватные коммерческие читы для "профессиональных стримеров", представляющие из себя аппаратный DMA-модуль с программной обвязкой-фреймворком, которая может скастомизировать железку под себя так, что каким бы крутым ни был античит, он не сможет заподозрить, что память читается сторонним устройством. Да, цены таких девайсов $10к+, но
блогерычитеры-милионники могут себе позволить.А весь багаж вариаций UB из С++ тоже входит в BNF? :D
Не поверите, но за всю жизнь написал всё же больше кода на Си и С++, нежели на Расте.
Да мне ваще параллельно на то, что кому нравится. И Си, и Плюсы, и Раст сам использую по мере надобности без лишних слов. А говорю лишь об упёртости и не желании смотреть в будущее, страхе смерти своего лампового Сишечки. Раст -- это же страшно, это для зумеров, его читать невозможно, а писать так вообще -- руки отсохнут!
Примерно как сравнить людей, кто боится летать самолётом и ездит поездом, убеждая всех вокруг, какие опасные и дорогие самолёты.
Да, оба будут в одной и той же точке рано или поздно. Оба достигнут цели, но тот, кто летел на самолёте ещё успеет погулять, поспать, поработать, пока второй ещё катится по рельсам своего комфорта и стабильности, ковыряясь в дебагере, где у него там чего случилось.
Я искренне хочу услышать от людей, кто серьёзно взялся за Раст и с уверенностью может сказать, что технология гавно и не подходит для его задачи. Очень хотел бы посмотреть я на эту задачу и этих "профессионалов". Но обратных же примеров куча. Подавляющее большинство тех, кто взялся за Раст, теперь за уши от него не оттянуть =)
А уж право решать, кто тут быдло, оставлю вам, простите.
Это довольно абсолютные цифры. Мне кажется, не стоит их учитывать в отрыве от зрелости языка. Раст более-менее стабилизировался и получил популярность только к 2018-й версии, а это всего лишь 5 лет. Менее 5-ти лет стало достаточно для того, чтобы инертные топовые мировые гиганты, которые один надоедливый, всех бесящий баг могут фиксить годами, внезапно увидели в Расте потенциал и массово начали на нём писать свои проекты. Только эти факты дорогого стоят, чтобы судить об успешности технологии.
Гугл в конце 22-го года проводил исследование. С внедрением Раста количество уязвимостей упало на 25%, количество падений из-за повреждения памяти -- на 70%! А это десятки миллионов долларов в их масштабах. И сэкономленные нервы пользователям.
То, что это появилось в те времена, когда не было альтернатив, не говорит о том, что эти языки до сих пор незаменимы.
Да, изучение нового требует ресурсов: времени, средств, остановки маховика инетрности и изменения направления парадигм мышления. Я с этим ни сколько не спорю, я спорю с конкретными формулировками этой ветки коментариев вида "С++ незаменим", "невозможно игры писать на чём-то ещё", "кроме Си и С++ ничего не нужно" и подобными риториками прошлого тысячелетия, когда был один язык, один компилятор и непреодолимое чувство творчества.
Например? Очень хотелось бы услышать, что есть такого в С++ особенного для геймдева?
https://docs.rust-embedded.org/book/
https://github.com/rust-embedded/awesome-embedded-rust
У раста ffi-библиотеки любой сложности из коробки собираются и линкуются, ни с чем не нужно разбираться. Сам, когда несколько лет назад учил язык на низкоуровневом хобби-проекте, без проблем и бубнов встроил огромные проекты: язык Dart с его фреймворком Flutter. Сейчас же, с опытом, обернуть либу, для которой внезапно нет готового пакета, занимает пару часов.
В плане чтения кода на Си, я согласен, он будет жить ещё очень долго, но писать на нём уже мало кто решается.
Взять тот же Гугл, Майкрософт, Фейсбук, Cloudflare, Amazon. Откройте их крайние репозитории, начатые в течение последних 3 лет. Ни ОС, ни драйверов, ни системных утилит, ни реализаций стека протоколов, почти никто из них не начинал писать на Си.
Зато референсные реализации того же WASM, WebGPU написаны на Раст. Ядро HTTP3, протоколы QUIC и WireGuard у Cloudflare реализованы на Раст. В Андроиде на Rust написаны стек Bluetooth, NFC, HAL, гипервизор. Новая гугловская KataOS полностью написана на Раст, включая ядро и драйверы, а в Fuchsia половина кода на нём уже. Майкрософт усиленно пилит биндинги для Windows SDK под Раст.
Не знаю, может быть я это замечаю только потому, что я плотно занимаюсь языком уже несколько лет, но по-моему тренды довольно показательны.
Странно, по-моему мнению, тулчейн и экосистема Раста -- лучшее, с чем приходилось работать за всю кодерскую жизнь.
Перечисленные вами факты -- исключительно историческое наследие.
Я это написал, ответив на фразу "заменить их никак не получается". Вот мне и интересно, у кого не получается? У комментатора? У тех, кто не пробовал? Инертность, "трушность"? Так это тогда не проблема языка, а проблема тех, у кого не получается.
Кто осилил закопать это гавно мамонта, у тех более чем получается. Ни один адекватный человек сейчас не начнёт новый проект на Си, если только не религиозный фанатик.
Всё, что осталось хорошего от Си, так это его универсальный ABI, который, кстати, тоже сложился в "стандарт" де-факто сугубо исторически. Остальное давно уже можно безболезненно закопать.
Что это за области такие, где нельзя заменить Си? На полке в музее?
Не знаю, как в этих ваших столицах, но в Ростове-на-Дону за всё время существования сервиса ровно 2 (два) раза на моей памяти Ситимобил был дешевле ЯндексУберов. В других городах, где был ДиДи, тот был самым дешёвым, Яндексубер на втором месте, а Ситимобил всегда был самым дорогим. Совсем неадекватно дорогим, иногда в 2-2.5 раза!
Контингент водил в регионах у них тоже был а-ля вчера с зоны откинулся, сегодня таксовать поехал.
Это известная в ростовских кругах старая галера.
В универское время знал людей, которые там работали. Тогда они просто брали проекты на Апворке с некислыми рейтами, нанимали недавно закончивших универ студентов, платили им 10-20к деревянных в месяц. При этом, от работников даже не скрывали их рейт, что они на самом деле зарабатывают несколько тысяч долларов, а получают на шаурму и проезд туда-обратно.
Тех немногих, кто заподозревал неладное и уходил от рабовладельца на тот же апворк, кидали, не выплачивали остаток. В случае частых вопросов на тему "когда выплатят?", получали угрозы, типа если в себе так уверен, приезжай в офис, забери коль сможешь. А вы про какой-то ТК. Ну-ну =)
Шёл 2022-й год. Ничего не менялось. Если они до сих пор живы, значит спрос на подобные унижения у студентов до сих пор велик. Неужели в годы такого информационного изобилия все настолько отчаялись. Можно ж уже чуть ли не в ютубе учиться кодить теперь.
А впрочем, с хера ли бы оно поменялось...
Примерно такой же использую в качестве роутера, только помощнее. i5-8365U, 4G, SSD 128G
С максимальным тюнингом под энергосбережение жрёт где-то 6.5Вт в Idle. Ну, то есть, даже когда гигабит через себя пропускает, он по сути в Idle находится, энергопотребление максимум до 7-8Вт повышается.
Да, оверкилл, но помимо роутера ещё используется в качестве "домашней лаборатории" под виртуалки, различные сервисы, разработку и т.п.
Возможно, современная ситуация получше, но когда пару лет назад сталкивался, из своих проектов максимум 10% мог собрать gnu тулчейном без бубна.
ПС. Сейчас погуглил. Похоже, что ситуация заметно лучше стала с появлением WLS, который явно поспособствовал развитию тулчейна. Во времена, когда я пытался, с этим был какой-то треш.
Да что ж всем так интересны сексуальные извращения.
Как я написал в соседней ветке, gnu toolchain был создан в винде исключительно для кросскомпиляции. 4 гигабайта диска настолько дорого стоят, чтобы тратить нервы на боль и страдания?
Для проектов с открытым кодом или команд до 5 человек лицензия на MSVC не нужна, что покрывает большинство потребностей.
Если будет возможность слинковать статически, то не придётся. Например, HelloWorld слинковать можно.
Но в серьёзных проектах такого почти не встретится, потому что GNU ABI предполагает динамическую линковку по умолчанию. Множество либ вообще не предназначено для статики. Натрахаетесь со всякими PIC, релоками, и прочими радостями линковки.
Это всё -- если у вас нет рантайм ABI-bound взаимодействия, иначе -- много разнообразного секса будет.
Мб потому что в Винде используется Windows ABI, а не GNU'сный?
Как вы предлагаете линковать либы, например, из современной SDK/WDK? Я вообще не уверен, что gnu бандл содержит адекватные хотя бы основные либы для виндовых фич. Последний раз, когда сталкивался пару лет назад, там было говно мамонта времён раннего pre SP3 Windows XP.
Если вам достаточно gnu тулчейна, значит вы HelloWorld'ы компилите без внешних платформенных зависимостей. Ну или сраные блокчейны с бекендами, перекладывающими байтики, тоже вполне соберутся. А что-то полезное под современную 10/11 винду типа драйверов или системных утилит им никак не слинкуешь.
gnu тулчейн под винду изначально создавался для кросс-компиляции, а не извращений.
Хабр -- для аутистов!
Когда будут туториалы "Как включить компьютер", "Как установить Виндавс"?
Если уж на то пошло, то советуйте
Even Better TOMLвместоBetter TOML, который заброшен и не поддерживается уж 4 года как.Различия у них в том, что
vscode-rustбольше года назад забросили, а позже вообще объявилиdeprecatedвRFC2912. Оно не "плохо работает", оно вообще больше не разрабатывается.rust-analyzerожидается в stable toolchain вместоRLS.Без проблем всё пробрасывается с одной видеокартой, 5 лет почти сидел на такой системе.
Не знаю как сейчас, но раньше достаточно было выгрузить родной драйвер GPU, отдетачить нулевую
vtconsoleи разбиндитьefi-framebuffer. При этом монитор изчезает, отлаживать можно через ssh. Потом, для каждого пробрасываемого устройства, разбиндить его драйвер и сразу же забиндитьvfio-pciмодуль на этот vid:did.Чтобы вернуться в хост, нужно повторить всё в обратном порядке. Раньше даже автодетект работал, не нужно было запоминать прошлый драйвер. Была одна лишь проблема: USB-контроллеры были у меня дванольные, а третьих не было, либо были какие-то драфтовые, без реализованного
hci reset, который при возврате в хост происходит. Из-за этого какое-то устройство могло остаться в потустороннем мире до перезагрузки. Решалось перетыкиванием девайсов в те контроллеры, которые умелиreset. Сейчас, подозреваю, везде ужеxhci, с его возвратом из забвения в реальность проблем вроде как нет.И, кстати, не нужно ничего хардкодить ни в ядро, ни патчить, всё без проблем динамически делается, в отличие от сказанного в статье. Достаточно разобраться в проблеме, а не нагрести с форумов копипаста, как сделал автор и запилить очередную говностатью.
По поводу производительности. Имелась в те времена карточка GTX1070. По тестам на ФПС при максимальном тюнинге всех возможных параметров были потери порядка 2-3%. Основная проблема была в инпут-лаге. Если задротить в компетишн шутеры, заметна была "аквариумность". Есть вероятность, что в соврмеренных процах поменьше VM-exit'ов происходит на каждый чих, поэтому лаг может быть чуть предсказуемее.
Статья так себе, если честно. Основной смысл работы в такой системе как раз в файн-тюнинге.
Например, выделить память гостю можно через Huge Pages, чтоб поменьше дёргать страничный транслятор. Отключить merging страниц на худой случай, если huge pages против религии.
Вынести IO в отдельный тред, и запинить афинити чтобы, хоть и редкими, но локами, не снижать latency.
Отстроить маппинг очередей virtio-scsi, нативный TRIM, выключить промежуточные кеши. А ещё лучше заморочиться с vhost.
И ещё несколько десятков оптимизаций, которые уменьшат суммарный оверхед до пары процентов.
Для удобства выделения диска отлично подходит LVM thin provisioning: динамический ресайз, снапшоты и т. п. Хотя перформанс просаживал в несколько раз, когда юзал.
Ох, из чего ж статью то высосали, а?
По сути, написали на том же Си, но с синтаксисом другого языка, абсолютно не разобравшись в языке.
unsafeв этом случае нужен для того, чтобы сделать safe-обёртку, RAII и т.п. Ваш же код ни на йоту не безопаснее кода на Си. Даже наоборот: unsafe во всех местах, а не в конкретных идиоматических -- верный генератор UB похлеще С++.Что-то поменялось?
windows-rsвсегда без проблем работал соstable.Цель этой библиотеки -- вынести биндинги в отдельный юнит для компилятора, чтобы каждый раз не запускать кодогенерацию и компиляцию. И не подключает она никаких зависимостей, она генерирует из метаданных обёртки, типы и адаптеры для удобного вызова
externфункций. И да, это не биндинги в привычном их понимании, а именно wrapper'ы, которые, по опыту использования, очень хреново инлайнятся и кучу неявных side-эффектов генерят. Например, получая адрес функции, получаешь адрес незаинлайненного thumb wrapper'а, даже если фактический вызов заинлайнился, то есть, по сути, адрес мёртвого кода. При этом адрес получить можно только полным повторнымextern fnобъявлением для каждой WinAPI функции. Конечно, адреса нужны не всегда, но иногда нужно и много, не зря же Раст -- всё таки системный низкоуровневый язык.Опять таки, никаких зависимостей он не подключает, а просто инлайнит сгенерированный из метадаты исходник на Расте из стандартной директории выхлопа генератора.
Не выдумывайте, откуда вы взяли такое требование?
mainможет возвращать любой тип, который реализует трейт std::process::Termination, хоть пустую юнит-стуктуру делайте и возвращайте из неё42, никто не запрещает. Похоже, вы скопипастили из примеров код, не разобравшись, зачем там этот тип указан. А указан он для использования оператора ? на std::ops::Try-типах, то есть там, где возвращается либо COM'овский Result, содержащий WinRT'шную ошибку, либо растовыйResult, полученный через какой угодно метод конвертации. Вы же ни разу этот оператор не использовали, значит тип возвратаmainтут не причём и может быть любымimpl Termination.Пишете, что нужно везде использовать W-версии функций, а сами используете A-версии.
Доступ в кишки тупла -- такое себе. В
windows-rsэта проверка делается через windows::Handle::is_invalid().deprecated же.
RegisterClassExсейчас рекомендуется использовать.То, что HWND == NULL и HWND == 0 имеют одинаковые значения -- чисто случайное implementation defined совпадение и потенциальное UB. В windows-rs трейт std::default::Default мапится на
NULLhandle.Вся функция здесь --
unsafe. Нужно не блок внутри функции делатьunsafe, а всёextern-объявление, ибо unsafe интерфейс и unsafe реализация -- разные вещи.В чём сакральный смысл конвертации u32 в u32?
Здесь не стоит путать ABI указателя на ffi функцию и его мапинг из
Option'а с костылём, который придумали в windows-rs. Это совершенно разные вещи. Из коробки работает толькоOption<extern fn()>. Другие типы без бубнов так не работают, нужны обёртки из трейтов.