Pull to refresh
8K+
320
Николай Шлей@CodeRush

Firmware Security Engineer

29,1
Rating
692
Subscribers
Send message

Хорошая обзорная статья, но вот этот пассаж резанул глаз:

Просто приведу вам небольшой пример: хотя вы не можете купить ETF Vanguard S&P 500 с тикером VOO, вы все равно можете инвестировать в тот же индекс через того же провайдера (Vanguard) с тикером VUSA.

Единственное существенное отличие заключается в том, что он базируется в Ирландии, а не в США, и вы можете покупать или продавать его напрямую в евро, а не в долларах США, поэтому вам не нужно тратить деньги на конвертацию валюты.

Автор несколько не в курсе американского налогового законодательства, а конкретно - сочетания US-domiciled бумаг (которые IRS не без оснований считает US-based) с estate tax (налогом на наследство), у которого безналоговый порог для US non-residen alien (т.н. всех не-граждан и не-гринкартовцев, постоянно не живущих в США) всего $60k. Таким образом, если купить себе VOO "на всю котлету", а потом неожиданно умереть (не успев передать акции траст-фонду имени самого себя), то брокер успешно вам заблокирует все US-domiciled бумаги, а потом с ваших наследников стрясет нормально так налога на наследство, до 40%. Вам, конечно, на тот момент это уже не очень интересно, но детям будет неприятно.

С другой стороны, VUSA и прочие Ireland-domiciled бумаги, с которыми таких проблем нет, имеют и более высокую комиссию за управление, и "внутренний" налог 15% на дивиденды и проценты, который ирландский филиал Vanguard платит самостоятельно. Это может быть несколько невыгодно для тех, кто живет в стране с более низким процентом по этим налогам (в Болгарии, например), но в общем случае даже хорошо.

Подробности про налоги для нерезидентов США, таблица стран с процентами и расчет правильных дивидендов от ирландских фондов на BoggleHeads Wiki.

Не нулевой, а 101.

В результате запуска без параметров там будет что-нибудь вроде thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', т.е. ничего интересного.

Если же повторять эксперимент на Rust, то лучше засунуть все в здоровенный блок match и посмотреть, прожует компилятор 4 миллиарда записей в нем, или тоже решит, что это не для него.

В старой версии, кстати, можно было удалять диалоги из одноименного раздела, а в новой я как ни старался, соответствующую кнопку найти не смог.

Верните, пожалуйста.

Ну вот, в итоге абсолютно весь рост фондового рынка РФ за 5 лет успешно сожран курсовой разницей, т.е. в более стабильной валюте (у которой тоже немаленькая инфляция за эти 5 лет) не получилось заработать примерно ничего.

Добавьте, пожалуйста, на график VWCE и VUAG, доступные через любого европейского брокера.

На автора я не нападаю, и вообще стараюсь отделять идеи от их носителей. Моя претензия к идеям, которые высказывает автор, в том, что он рассуждает о "финансовой независимости" и "ранней пенсии", но о рисках при этом почти не говорит. "Суть не в конкретных активах, а в подходе" - это замечательно, но мы тут говорим про 50+ лет финансового планирования, и потому примеры стоит приводить в тех инструментах и с теми процентами, где таковое планирование имеет смысл.

Идея именно "ранней пенсии", на мой взгляд, она вся целиком про управление рисками, и успех в деле сохранения покупательской способности накопленного капитала и возможности жить с пассивного дохода от него в течении полувека обеспечивается диверсификацией (настоящей, т.е. использованием нескольких брокеров в странах разных экономических блоков), индексным инвестированием (потому что угадать самим, кто именно сможет заработать за 50 лет, крайне маловероятно, а активное управление на таких периодах проигрывает широким индексам просто за счет высоких комиссий за этой самое управление), консервативным подходам к содержимому портфеля (т.е. не "акций нвидии на всю котлету"), и т.п.

Если же рассматривать эту статью как помощь в начале накопительной фазы ("на пути к жизни с капитала"), то о рисках все равно стоит хотя бы упомянуть, потому что внезапный скачок курса доллара с 80 рублей до 120 за один день может срезать вам всю доходность от инструментов в рублях за 5 лет. И вероятность такого события сильно выше, чем скачок этого же курса в обратную сторону.

Теперь конкретно про то, что я называю рублевым активом: все, что номинировано в рублях, и торгуется на биржах РФ. РФ, на текущий момент, является развивающимся рынком, а после 22 года еще и целью санкций против ее самых успешных компаний, банков, бирж и т.п. Вкладывать деньги в такой рынок - это крайне рискованное, но и потенциально очень доходное мероприятие, поэтому в такой рынок стоит заходить тем, у кого уже и так достаточно денег, чтобы потенциальная потеря всех денег с рынка РФ не ударяла по ним никак. Т.е. если у вас есть карманный хедж-фонд на пару миллиардов долларов под управлением - смело заходите в развивающиеся страны, может успеете сделать там иксы до того, как там настанет очередной незапланированный карачун. Заносить же на такой рынок основной капитал, nest egg, на который мы в дальнейшем планируем жить - это, с точки зрения управления рисками, полный пиздец, для которого у вас должны быть железные нервы и титановые яйца. Если вы это считаете хеджированием валютных рисков - значит ваш профиль рисков сильно отличается от моего.

Я искренне и без сарказма желаю удачи в нелегком деле сохранения и приумножения капитала и автору, и комментаторам, и сам стараюсь упоминать хорошие, на мой собственный взгляд, ресурсы вроде BoggleHeads Wiki, Investopedia, Common Sense Investing и т.д. в комментариях, участвовать в обсуждениях, делиться своей точкой зрения. Если вы считаете это все нападками на авторов статей - прошу пардону, нападать ни на кого не собирался, места в интернете хватит всем.

В российских условиях есть отличные 9.5 правил ведения безопасного ИТ-бизнеса в России, с 2010 года не потерявшие ни грамма актуальности. Вкладывайте в себя, в свои собственные проекты, торгуйте их результатами на мировом рынке, а прибыль от них храните в сотне разных инструментов в десятке разных юрисдикций.

К сожалению (или к счастью) мы живем в глобальном мире глобального рынка, а РФ на текущий момент не производит в полном цикле практически ничего, что нужно было бы (раннему) пенсионеру. Внутри еды заложен импортный семенной материал и техника, внутри промышленной продукции - импортные технологии и станки, внутри лекарств - импортные технологии и сырье, и т.п.

Все эти импортные вещи торгуются за доллар и юань, поэтому "долгосрочные цели в рублях" - это очень странный предмет, он вроде есть - оп, и его уже нет. В фиате вообще странно хранить деньги (это средство обмена, а не накопления), но ставить долгосрочные цели в слабой нестабильной валюте - это опять же огромный риск, никак не покрывающий упомянутые вами.

Нужно еще добавить, что подобные ПИФы на развивающихся рынках (а рынок РФ - именно такой) хоть и приносят относительно высокую доходность, но при этом имеют очень значительный системный риск, связанный и с особенностями рынка, и с курсом локальной валюты, и с политическим климатом, и с постоянно меняющимися правилами. Эти 9-10% - это в рублях с непонятным (т.е. "очень надеемся, что работающим") хеджированием инфляции и непонятными страховыми перспективами. Если вот это называть надежным, то что тогда ненадежное...

Есть относительно надежный способ получать около 3-6%, но не в виде конкретно дивидендов (потому что они генерируют налоговые события, и этим зачастую неудобны) - широкие пассивные индексные фонды, либо американские (но тогда лучше иметь американское же налоговое резидентство, чтобы не попасть под налоги неприятные, или, в крайнем случае, жить в стране с низкими процентами по dual taxation treaty, вроде Болгарии), либо ирландские (в них уже учтены американские налоги на дивиденды и интерес в 15%, и можно взять накапливающий вариант того же фонда вместо распределяющего). У меня самого сейчас весь портфель сделан из VTSAX (основной источник премии за риск), VBTLX (хедж на случай сильного падения рынка акций) и AAPL (надо продать, но налоги пока слишком высокие, жду возможности оптимизации). Если налоговое резидентство США получить не вариант, можно купить у любого европейского брокера те же самые широкие фонды, только с ирландским домицилем (VEVE и аналоги, justETF поможет выбрать).

Вообще, на BoggleHeads Wiki есть отличный набор статей, советую почитать их все.

С российскими брокерами и ПИФами посоветую не связываться, даже без учета всех нынешних проблем с санкциями, потому что у них совершенно сумасшедшие комиссии (1% и выше). Максимум - дальнейшая диверсификация в собственный портфель из местных акций и облигаций, с оплатой самому себе за управление портфелем, но это уже не пассивный доход, а полу-пассивный, потому что работать над ребалансировкой придется все равно.

Скорее всего, пытаются успеть занять освободившуюся нишу как можно быстрее, а затем уже думать, как монетизировать доработки под конкретных корпоративных пользователей, продавать плагины, поддержку и т.п. Если сразу делать фремиум - пользователи могут уйти к опенсорсным конкурентам, и потому занять нишу не получится.

Радость от программирования (а оно реально в радость, это акт творения, причем один из самых простых в реализации, потому что бороться с ограничениями физического мира для него не нужно), радость от решения проблемы (офигеть, теперь вместо 20 минут в хекс-редакторе можно сделать то же самое за 20 секунд, и оно работает или также, или лучше, потому что программа меньше ошибается), радость от благодарности пользователей и повышения репутации и создания доброго имени ("ага, знаю этого чувака, он вообще крутой") - достаточные мотиваторы для многих людей, чтобы не требовать еще и денег.

Я не согласен с тем, что эти мы "плодим халявщиков", или "отнимаем поляну у кустарей", потому что халявщики таким же способом спиратили бы платное ПО, и при этом не вернули бы разработчикам вообще ничего (кроме, может быть, общедоступного кряка, чтобы остальным халявщикам удобнее стало). В опенсорсе же пользователи - это не только обуза, но и благо, потому что они предоставляют бесплатное тестирование, бесплатный фидбэк, а некоторые даже код сами правят и фичи сами реализовывают, становясь полноценными участниками проекта.

Короче, хотите денег - занимайтесь их зарабатыванием. Мне за опенсорс деньги не нужны, я им решаю для себя совсем другие задачи и массирую им совсем другую часть системы поощрения внутри головы. За деньги я работаю на корпорацию, которая намного лучше меня самого умеет монетизировать мой труд, а мне оставляет ту часть работы, от которой я получаю какое-то удовольствие (потому что это тоже акт творения, и тоже помогает пользователям), а всю остальную работу полностью берет на себя. Сделка вполне честная, на мой взгляд, а то, что она вредит "кустарям" - это так работает капитализм, разделение труда, специализация, найм профессионалов и так далее. Кустарям же от себя посоветую не на опенсорс злиться, а объединяться в собственные корпорации и конкурировать уже с другими такими же, на своей поляне. Там и денег сильно больше заработаете, если работать умеете, и опенсорс будет с вами на одной стороне баррикад, а не на разных.

Just for fun, конечно.

Я когда свой проект стартовал в 2013 году, был на последнем курсе магистратуры, и деньги мне тогда были не нужны, нужны были прикладные знания и навыки в области Software Engineering и Software Development, которые я и пошел получать и тренировать наилучшим, на мой тогдашний взгляд, способом. При этом и процесс, и результат этого труда были нужны именно мне (я тогда занимался модификацией UEFI-совместимых прошивок в качестве хобби), а альтернатив хороших, кросс-платформенных, с открытым кодом и графическим интерфейсом тогда не было.

В итоге получилось и свой C и C++/Qt улучшить заметно, и проблему достаточно эффективно решить, и научиться не только программированию, но и сопровождению, и заиметь определенную репутацию в своих узких кругах, благодаря которой получилось устроиться и на первую серьезную работу (разработчиком прошивок), а затем и в мегакорпорацию (специалистом по безопасности эти самых).

Если бы я заранее рассчитывал на монетизацию этого проекта, то не стал бы за него садиться, потому что у среднего пользователя нет денег на такую ерунду, а имеющиеся альтернативы (PhoenixTool, например) уже тогда были и бесплатными, и работоспособными, а из недостатков имели только закрытый код и привязанность к .Net 3 (т.е. к Windows).

Более того, товарно-денежные отношения для подавляющего большинства людей подразумевают (хотя бы частичную) передачу контроля на проектными решениями и приоритетами, т.е. задачей разработчика становится "делать пользователю зашибись". У меня такой задачи нет, и я делаю зашибись в первую очередь себе самому, а пользователям хотя и очень рад (они, например, тестируют твой софт на конфигурациях, которые ты сам у себя в подвале гарантированно собирать не станешь), но ничего не должен. И донаты не беру по этой же примерно причине.

Корпорации, кстати, это тоже хорошие пользователи, и то, что они каким-то образом делают на моем коде деньги - да на здоровье, я бы эти деньги все равно не сделал, потому что не желаю смешивать работу за деньги с работой для души. Уважение коллег заработал - отлично, пользователи сказали "спасибо" - замечательно, попал в десятку лучших в мире специалистов по разбору UEFI-совместимых прошивок на составные части, потому что за 10 лет работы над их разбором насмотрелся на любые и всякие - тоже хорошо, теперь эту специализацию можно продать тем, кому она для чего-то нужна.

Абсолютно уверен, что если бы я вместо опенсорса и работы с сообществом написал бы какой-нибудь UEFITool PRO и попытался его продать, заработал бы сейчас значительно меньше, если что-либо вообще. А так и с деньгами проблем больше нет, и проект стал стандартом де-факто в своей микроскопической нише. Понятно, что это все результат скорее случайных процессов и удачных таймингов, и потому может быть проигнорировано как "ошибка выжившего", но получилось как получилось, и мне нравится этот результат.

Советы неплохие, но начинаются с середины, и еще сильно до того, как идти выбирать лицензию и т.д. по тексту, нужно для себя прояснить очень хорошо примерно следующее:
- какую именно проблему решает проект, является ли эта проблема реальной, нужно ли решение лично вам как автору, и кому еще это решение может пригодиться
- какие имеются альтернативы и в чем их фатальные недостатки, из за которых именно вам нужно решать проблему заново, и не будет ли лучше присоединиться к разработке уже существующего проекта, а не садиться за написание нового
- сколько у вас ресурсов и сможете ли вы тратить главный невосполнимый ресурс (время вашей жизни) не только на fun-части проекта (написание кода, решение проблемы, прием благодарностей и донатов), но и на slog-части (настройка и отладка сборочной системы, тестирование, создание и поддержка CI/CD-пайплайна, общение с пользователями, разгребание сообщений об ошибках, фич- и пулл-реквестов и т.п.).
- ожидаете ли вы роста пользовательской базы, и если да, то готовы ли к тому, что проект станет отнимать значительно больше ресурсов, чем в начале?
- готовы ли вы к конфликтам, форкам, драме, оскорблениям, необоснованным требованиям по немедленной доставке фич, немедленному исправлению багов, немедленной реакции на инциденты, потенциальным проблемам с патентами, адвокатами, письмами cease and desist, DMCA-тейкдаунами, GDPR-совместимостью, бану вашей юрисдикции гитхабом, неадекватам всех сортов и мастей, и прочим прелестям взаимодействия с большой группой бездельников в интернете?

Если ко всему готовы и все для себя решили - могу только порадоваться за вас, добро пожаловать, коллега. Постараюсь воспользоваться результатами вашего альтруизма и вашим весомым вкладом в будущее человеческой цивилизации. Искреннее больше спасибо.
Если не готовы и не решили - тоже спасибо, меньше разочарованных авторов и мейнтейнеров. Попробуйте себя в чем-нибудь другом.

Продолжайте переходить на личности, обсуждать мою типичность, растовость и выдуманную "безопасность". Общаться с вами не намерен, искать вам примеры проблем безопасности, вызванные C++ UB тоже. Ступайте своей дорогой.

Пока что, к сожалению, кроме переставления кроватей никаких других вариантов нет, как и "других писателей", так что переставлять в любом случае приходится, так или иначе. Выиграет ли от этого бордель - будем посмотреть, пока что выигрывает, по крайней мере из моего погреба видится именно так.

Ну и если уж говорить конкретно про UEFI и другие популярные продукты похожего уровня, то большая часть серьезных эксплуатируемых проблем с ними за последние 5 лет - это именно "детские" проблемы C-подобных языков:
- Intel ME 11.x INTEL-SA-00086 - переполнение стека при чтении файла с MFS.
- UEFI BootHole - переполнение кучи в GRUB при чтении конфигурационного файла, потому что в результате ручной проверки на это переполнение было только сообщение в лог.
- UEFI LogoFail - переполнение кучи и чтение за пределами буфера в парсерах изображений.
- Apple iBoot checkm8 - use-after-free в драйвере USB DFU.

Ошибок в логике тоже было море, и я ни в коем случае не пытаюсь тут сказать, что от использования более современных "безопасных" ЯП они все исчезнут, как по волшебству, и разработчики на них неожиданно перестанут быть людьми и делать ошибки. Не перестанут, конечно, но удаление целых классов ошибок из списка вероятных (а с ростом кодовой базы эта вероятность быстро приближается к 100%) - это несомненное благо, с какой стороны не смотри.

У меня с тех пор много воды утекло, и я насмотрелся на нынешнем месте работы уже именно на проблемы, вызванные непосредственно недостатками С и C++, а точнее сочетанием необходимости сохранять нечеловеческий уровень концентрации для написания на них безопасного работающего кода с крупномасштабной потоковой разработкой, 500 пулл-реквестами в сутки, очень разным уровнем разработчиков и т.п. Не могу сказать, что у меня есть примеры кодовых баз похожего размера и активности на более новых "безопасных" языках, но пока что решительно все попытки замены C и C++ на FireBloom и embedded Swift, в которых я участвовал и с которыми имел дело, показывают однозначное улучшение по большинству метрик, особенно по количеству эксплуатируемых проблем с памятью, состояний гонок, и самодеятельностей компилятора. При этом внедрение это - крайне недешевое во всех смыслах мероприятие, идущее тем не менее полным ходом.

Мне, честно сказать, давно уже ультрафиолетовы конкретные инструменты, потому что мне необходимо уметь пользоваться любыми. В данном случае я вижу, что ничего, буквально ничего, не спасает большие проекты на С и С++ от "решета", и потому я уже давно пришел к тому, чтобы не начинать новых проектов на ЯП, доказавших практикой собственную ограниченность у всех участников индустрии. Лошадь сдохла - слезь.

Стоило, я думаю, написать об этом в предисловии, вместо "выбор языка программирования для нашего приложения был очевиден". Ну и в действительно любую кофеварку лучше получилось бы внедрить подмножество C99, а не C++17, если уж выбирать и по этому критерию тоже. И разработчики были бы еще дешевле, и тулинг весь или тот же самый, или лучше.

Я искренне желаю вам удачи, и надеюсь, что C++ не станет для вас "чемоданом без ручки" в тот момент, когда ваша кодовая база перерастет 10М строк, из проекта уволятся его оригинальные разработчики, и прошивка накопит достаточно мертвого кода, чтобы перестать влезать на кофеварки. Пока что мой собственный опыт показывает, что писать хороший поддерживаемый низкоуровневый продолжительно работающий код на С++ не умеет примерно никто. Язык банально слишком сложный для и так уже весьма непростой предметной области, вариантов выстрелить себе в лицо слишком много, и оптимизирующий компилятор слишком много на себя берет.

Не могу сказать, что более современные альтернативы лишены всех этих недостатков, или не имеют собственных новых, но не замечать того, что практически все вокруг люди, команды и компании уже начали перевод своих прошивок и ОС с С-подобных языков на более современные и безопасные, я не могу. Nvidia переходит на SPARK, Microsoft переходит на Rust, Ядро Linux добавляет экспериментальную Rust-подсистему, Google начинает использование Rust в Android, имя им легион.

Overall, despite these challenges and limitations, we’ve still found Rust to be a significant improvement over C (or C++), both in terms of safety and productivity, in all the bare-metal use cases where we’ve tried it so far. We plan to use it wherever practical. (Google Security Blog)

Хорошая статья и подходы верные, только вот с выбором C++ все равно согласиться не могу, потому что вы тратите кучу ресурсов на борьбу с его недостатками, и при этом никаких его преимуществ, кроме, возможно, большего количества профессиональных разработчиков на локальном рынке, и "проверенности временем", не используете.

У вас нет интеропа с непонятным легаси-кодом на С, у вас нет существующей кодовой базы на миллионы строк, у вас нет экзотических архитектур, сумасшедших требований к производительности, отказоустойчивости, безопасности (security), безопасности (safety) и т.д.

Посмотрите на TamaGo, на Embedded Rust, на SPARK и прочие альтернативы. Я понимаю, что вы не стартап, а корпорация, но подход "мы обвесим C или C++ достаточным количеством тулинга, и он станет нормальным" - не работает. Он не работает у Microsoft, он не работает у Google, он не работает у Apple, и у вас он тоже не заработает. Чем раньше вы (и ваш менеджмент) это поймете, тем меньше у меня, инженера по обеспечению безопасности прошивок, будет новой работы. Жаль только жить в эту пору прекрасную...

Information

Rating
314-th
Date of birth
Registered
Activity

Specialization

Инженер встраиваемых систем, Системный инженер
Ведущий