Ну. то есть, Rufus лучший просто тем, что он работает, а другие нет? Ну тогда, безусловно, он и правда лучший :) Я просто пытался уточнить, есть ли ещё какие-то более тонкие критерии превосходства одних утилит для записи образов над другими. Понятно, что если записанный образ не загружается, то задача не решена, и утилите, которая это записала, незачёт.
А чем она лучше других утилит, которые делают то же самое — создают загрузочную флэшку? Это бинарная задача — образ либо корректно записан, либо нет. Как это можно сделать лучше или хуже?
Читая вступительные строки о «продуктах, которые устроены или выглядят странно и отталкивающе», сразу подумал о FAR, но никак не TCMD. ИМХО Тотал Коммандер очень классный, он очень удобен, очень быстро работает (а этого, как я теперь понимаю, совсем не тривиально добиться), много встроенных продвинутых функций, а о многообразии плагинов и говорить нечего.
У меня примерно 300 неиспользуемых вкладок в трёх-четырёх отдельных окнах (в сумме), я тоже не жалуюсь на производительность. В Хроме именно с производительностью тоже проблем нет, но вот памяти он жрёт больше, и прилично больше. При намного меньшем количестве вкладок.
Гугл не заставляет писать приложения с нативными компонентами, всё заточено на написание приложений целиком и полностью на Java, поэтому когда вы вопрошаете: «Зачем такое надо было делать?», во-первых, непонятно, чем это вам мешает, а во-вторых, кому адресован вопрос. Могу ответить за себя: у нас кросс-платформенное приложение на С++, и переписывать его с нуля на Java никто не стал бы, а поддержка нативного кода Андроидом как раз и позволила нам предложить нашим пользователям ещё и Андроид-версию приложения. Сейчас мы с коллегой работаем над нативным интерфейсом (С++ / OpenGL) вместо штатного Java, но не потому, что со штатным что-то не то, а потому что нам так проще и мы можем его лучше отладить.
Хочу отметить, что №3 — постоянная проблема при программировании чего бы то ни было на С/С++, и я имею в виду любые проверки, а не только проверки на nullptr. Ещё лет 5 назад придумал такое решение, и мне оно до сих пор кажется удобным и изящным: особый вид assert макроса — assert_and_return, который проверяет условие и возращает указанный объект (или ничего). В релизе уходит сам assert/abort(), но остаётся проверка и выход. Вот пример:
Подключение EDK я не осилил (хотя их руководства, наверняка, стоят внимания — я не видел этих материалов, когда изучал тему программирования под UEFI). Может быть, кому-то пригодится мой репозиторий с хедерами для работы UEFI и пример UEFI приложения c использованием этих хедеров (там есть и работающий проект для VS2019).
Тоже не понимаю. Как по мне, QML ужасен. И да, я пытался им пользоватиься, но не понял, зачем он. При написании с нуля софта под мобилки могу увидеть смысл, но под десктоп? Портировать? Какждому своё, но я не вижу, какие проблемы в существующем и работающем десктопном приложении решает QML. Зато вижу, что добавляются новые проблемы.
Палка о двух концах, писать софт под одну архитектуру проще, а оптимизировать — и подавно. Лично меня устраивает монополия х86, пока есть хотя бы два топовых вендора, которые двигают прогресс в конкуренции между собой.
А как вообще автоматизированно получить страницу, спрятанную за Cloudflare? Этот нынче половина интернета. Ведь каким бы вежливым мой бот ни был, его заставят проходить капчу.
А у Veritasium есть отличное видео про капельки:
А вот аналоги для других ОС мне не зашли. Поэтому я разрабатываю собственный кросс-платформенный файловый менеджер с оригинальным названием :)
б) — страна развивается
Я не утвержаю, что между а) и б) есть причинно-следственная связь, но подозрения имеются)
Без моего макроса была бы такая колбаса:
А вот, собственно, моя реализация: github.com/VioletGiraffe/cpputils/tree/628ddff8b37bb11d8af336501f3dcb22f560cd7f/assert