Видимо, это сюда перекочевало из ошибки автора обзора на Ars Technica. Имелось в виду, что пока поддерживается использование одного ядра процессора. Поддержка SMP есть, но пока работает не очень стабильно.
А можно ещё unsafe/unchecked обращение к массиву по индексу попробовать, как в обеих версиях из статьи («индексы корректны по построению») — интересно, получается ли у компилятора доказать, что проверки всегда проходят, и выкинуть их при оптимизации?
Android сильно ограничивает фоновую активность приложений, но при этом позволяет безлимитно создавать приложениям сервисы для работы в фоновом режиме. Чем разработчики от неграмотности или в корыстных целях злоупотребляют.
Совсем не безлимитно; в новых версиях (Oreo, Pie) на сервисы наложили серьёзные ограничения, уже нельзя просто так завести сервис и тратить ресурсы. Про это я немного подробнее рассказал в прошлой статье.
Если вы о свободном месте, которое остаётся после добавления вторых копий каждого из системных разделов, то всё совсем не так плохо, как звучит.
Во-первых, большинство функций recovery по обновлению системы в схеме с A/B-обновлениями выполняет сама система, так что recovery можно сильно упростить (а значит, она будет занимать меньше места). Во-вторых, не нужен раздел cache, на который раньше скачивались обновления перед установкой. В-третьих, вместо того, чтобы хранить odex-файлы предустановленных приложений в разделе system (а они, вроде бы, занимают половину её объёма), можно исходно сохранить их на system_b (вместо образа системы), откуда при первом запуске скопировать в data; а после этого уже использовать system_b по назначению.
Google говорят, что у них на Pixel в результате этих оптимизаций для A/B-схемы потратилось только 320 дополнительных мегабайт по сравнению со старой схемой. Подробнее здесь и ещё вот здесь.
Смотрите, разница здесь вот какая. Графический ключ, пин-коды, пароль и т.п. — это чистый, статический кусок информации. Его можно сравнивать (совпадает пароль или не совпадает?), его можно хранить, от него можно взять хэш, на его основе можно создавать ключ шифрования данных и так далее.
А система распознавания отпечатка пальца, лица, радужки глаза… — это именно система распознавания. Она может решить, владелец устройства приложил палец или кто-то другой. В каком-то виде она, конечно, хранит характеристики этого пальца, чтобы его узнавать; но, во-первых, это какая-то нечётная модель, во-вторых, такие характеристики пальца из себя ничего секретного не представляют и создавать на их основе ключ было бы небезопасно.
Повторю другими словами: в одном случае у нас есть явный и устойчивый кусок информации, который нужно сравнивать с другим куском информации (а ещё можно использовать для генерации ключа). В другом случае у нас есть некоторая функция, чёрный ящик, которая возвращает boolean — правильный ли палец прикладывают. Это здорово для аутентификации (не нужно запоминать пароль!), но секретный ключ на основе этого не сгенерировать.
Так работает новый механизм обновления системы. Одномернно хранятся две версии каждого системного раздела (boot_a, boot_b, system_a, system_b, vendor_a, vendor_b — а вот к разделу data это, конечно, не относится). Один из них этих слотов считается активным, и именно с него загружается система (то есть, если, например, активен слот a, то bootloader загружает ядро и initramfs из boot_a, /system монтируется из system_a и т.д.). В другом слоте остаётся прошлая версия системы — или, наоборот, только что загруженная новая версия, в которую устройство загрузится при следующей перезагрузке. Подробнее можно почитать здесь, здесь и здесь.
Да, можно и нужно использовать систему типов для таких вещей. Проблема в том, что это решение принимает разработчик библиотеки для работы с БД, а не автор конченой программы (и тем более не анализатор). И в случае JDBC, например, запросы передаются в виде String sql.
Так что конечно было бы лучше, если бы все использовали систему типов, но анализатор всё равно должен уметь находить SQL-инъекции в коде, который использует «сырые» строки.
Есть достаточно хорошие биндинги для GTK, glib и всей g-экосистемы: https://gtk-rs.org. Есть rust-qt-binding-generator. Но вообще для GUI Rust не очень-то подходит с его моделью памяти (ownership, отсутствие классов и наследования...); имеет смысл писать на Rust ядро/бэкэнд, а GUI — на более «родном» для платформы языке (Vala, Objective-C, Kotlin, ...)
Разным анализаторам нужно разное. Кто-то работает на исходном коде (или, например, на AST, который сам же строит по исходному коду), а кому-то «достаточно» бинарника (в кавычках, потому что это не обязательно меньшее требование — как описано в статье, собрать исходники может быть не так тривиально). Это может быть или совсем «нативный» бинарник (например, для C/C++), или набор class-файлов для Java/Kotlin/Scala — и class-файлы, кстати, во многом сохраняют семантику исходного кода, в большей степени, чем «совсем бинарники».
С бинарниками ещё возникает сложность с тем, чтобы найденную уязвимость пользователю отобразить — нельзя же написать, что «в библиотеке Foo есть SQL-инъекция». Более крутые анализаторы способны декомпилировать бинарник и сопоставить место, где нашли в нём уязвимость, строчке в декомпилированном коде.
А если они с исходным кодом, то что мешает их исправлять?
Может быть, их исходный код и доступен (в публичном репозитории), но чтобы внести туда свои правки, нужно делать форк, pull request, ждать следующего релиза и т.д. Альтернативно, можно, конечно, собирать проект со своей копией библиотеки, а не пытаться исправить уязвимость в upstream'е, но это много другой головной боли.
В принципе, похожие проекты уже есть, например, PureDarwin и GNU-Darwin, хотя у них, вроде как, нет Cocoa и всего высокоуровнего стека для macOS-приложений. Впрочем они могли бы, как мы, использовать реализации из проектов The Cocotron или GNUstep.
Проблема с созданием полноценной системы в том, что для неё требуется сильно больше, чем ядро и bash, нужны разнообразные драйвера, сервисы, графическая подсистема и т.п. В Linux всё это уже есть — и драйвера под практически любое оборудование, и системные сервисы вроде тех же udev, PulseAudio/PipeWire, wpa_supplicant и NetworkManager, и крутая современная графическая подсистема (DRM, KMS, Mesa, Vulkan, Wayland). В Darling мы стараемся максимально облегчить сам контейнер и использовать уже существующие на хосте сервисы, библиотеки и т.д. Для потенциальной DarlingOS пришлось бы или всё это перереализовывать, или пытаться портировать с Linux, или отказаться от большинства того, что отличает современную операционную систему от Unix 70-х годов.
Ну и потом, основная мотивация разрабатывать ReactOS вместо того, чтобы просто использовать Linux + Wine — jeditobe, поправьте меня, если я не прав :) — это потенциальная возможность использовать драйвера для Windows, которые часто всё-таки находятся в лучшем состоянии, чем их аналоги для Linux. А вот у macOS и iOS едва ли есть в этом плане преимущество перед Linux, поэтому вариант Linux + Darling подойдёт лучше всего.
Рассчитывать не стоит и не гарантирован (когда по памяти завершают, иначе гарантирован), но в документации явно написано, что система может его вызвать в такой ситуации:
onDestroy()
Called before the activity is destroyed. This is the final call that the activity receives. The system either invokes this callback because the activity is finishing due to someone's calling finish(), or because the system is temporarily destroying the process containing the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. The system may also call this method when an orientation change occurs, and then immediately call onCreate() to recreate the process (and the components that it contains) in the new orientation.
Нет, переход на ART вряд ли повлиял на работу сетевых соединений.
(Этот абзац не специфичен для Android, а верен на любой Linux-системе) Действительно, система может освобождать занятые порты не сразу после завершения державшего их процесса, а только после отправки всех буферизованных данных (это называется socket linger, и с этим часто борются с помощью SO_REUSEADDR), но это актуально для портов с заранее известным номером. Если вы просто делаете POST-запрос, система автоматически назначит вам подходящий свободный порт, и этой проблемы не возникнет.
Хабр — не Тостер, но думаю, вам стоит посмотреть с помощью сниффера, в чём разница в успешных и неуспешных запросах, как вам и порекомендовали на StackOverflow.
Ну и не могу не упомянуть, что отправка данных на сервер каждые 10 секунд — это, мягко говоря, не лучшая идея. Создавать для этого каждый раз новый сокет и забывать его закрыть — тоже.
Есть :)
Система не однопоточная.
Видимо, это сюда перекочевало из ошибки автора обзора на Ars Technica. Имелось в виду, что пока поддерживается использование одного ядра процессора. Поддержка SMP есть, но пока работает не очень стабильно.
Совсем не безлимитно; в новых версиях (Oreo, Pie) на сервисы наложили серьёзные ограничения, уже нельзя просто так завести сервис и тратить ресурсы. Про это я немного подробнее рассказал в прошлой статье.
Если вы о свободном месте, которое остаётся после добавления вторых копий каждого из системных разделов, то всё совсем не так плохо, как звучит.
Во-первых, большинство функций recovery по обновлению системы в схеме с A/B-обновлениями выполняет сама система, так что recovery можно сильно упростить (а значит, она будет занимать меньше места). Во-вторых, не нужен раздел cache, на который раньше скачивались обновления перед установкой. В-третьих, вместо того, чтобы хранить odex-файлы предустановленных приложений в разделе system (а они, вроде бы, занимают половину её объёма), можно исходно сохранить их на system_b (вместо образа системы), откуда при первом запуске скопировать в data; а после этого уже использовать system_b по назначению.
Google говорят, что у них на Pixel в результате этих оптимизаций для A/B-схемы потратилось только 320 дополнительных мегабайт по сравнению со старой схемой. Подробнее здесь и ещё вот здесь.
Смотрите, разница здесь вот какая. Графический ключ, пин-коды, пароль и т.п. — это чистый, статический кусок информации. Его можно сравнивать (совпадает пароль или не совпадает?), его можно хранить, от него можно взять хэш, на его основе можно создавать ключ шифрования данных и так далее.
А система распознавания отпечатка пальца, лица, радужки глаза… — это именно система распознавания. Она может решить, владелец устройства приложил палец или кто-то другой. В каком-то виде она, конечно, хранит характеристики этого пальца, чтобы его узнавать; но, во-первых, это какая-то нечётная модель, во-вторых, такие характеристики пальца из себя ничего секретного не представляют и создавать на их основе ключ было бы небезопасно.
Повторю другими словами: в одном случае у нас есть явный и устойчивый кусок информации, который нужно сравнивать с другим куском информации (а ещё можно использовать для генерации ключа). В другом случае у нас есть некоторая функция, чёрный ящик, которая возвращает boolean — правильный ли палец прикладывают. Это здорово для аутентификации (не нужно запоминать пароль!), но секретный ключ на основе этого не сгенерировать.
Так работает новый механизм обновления системы. Одномернно хранятся две версии каждого системного раздела (boot_a, boot_b, system_a, system_b, vendor_a, vendor_b — а вот к разделу data это, конечно, не относится). Один из них этих слотов считается активным, и именно с него загружается система (то есть, если, например, активен слот a, то bootloader загружает ядро и initramfs из boot_a, /system монтируется из system_a и т.д.). В другом слоте остаётся прошлая версия системы — или, наоборот, только что загруженная новая версия, в которую устройство загрузится при следующей перезагрузке. Подробнее можно почитать здесь, здесь и здесь.
Следующая часть наконец-то вышла: https://habr.com/company/solarsecurity/blog/427431/
Четвёртая статья: https://habr.com/company/solarsecurity/blog/427431/
Я наконец написал продолжение! https://habr.com/company/solarsecurity/blog/427431/
Да, можно и нужно использовать систему типов для таких вещей. Проблема в том, что это решение принимает разработчик библиотеки для работы с БД, а не автор конченой программы (и тем более не анализатор). И в случае JDBC, например, запросы передаются в виде
String sql.Так что конечно было бы лучше, если бы все использовали систему типов, но анализатор всё равно должен уметь находить SQL-инъекции в коде, который использует «сырые» строки.
Есть достаточно хорошие биндинги для GTK, glib и всей g-экосистемы: https://gtk-rs.org. Есть rust-qt-binding-generator. Но вообще для GUI Rust не очень-то подходит с его моделью памяти (ownership, отсутствие классов и наследования...); имеет смысл писать на Rust ядро/бэкэнд, а GUI — на более «родном» для платформы языке (Vala, Objective-C, Kotlin, ...)
Разным анализаторам нужно разное. Кто-то работает на исходном коде (или, например, на AST, который сам же строит по исходному коду), а кому-то «достаточно» бинарника (в кавычках, потому что это не обязательно меньшее требование — как описано в статье, собрать исходники может быть не так тривиально). Это может быть или совсем «нативный» бинарник (например, для C/C++), или набор class-файлов для Java/Kotlin/Scala — и class-файлы, кстати, во многом сохраняют семантику исходного кода, в большей степени, чем «совсем бинарники».
С бинарниками ещё возникает сложность с тем, чтобы найденную уязвимость пользователю отобразить — нельзя же написать, что «в библиотеке Foo есть SQL-инъекция». Более крутые анализаторы способны декомпилировать бинарник и сопоставить место, где нашли в нём уязвимость, строчке в декомпилированном коде.
Может быть, их исходный код и доступен (в публичном репозитории), но чтобы внести туда свои правки, нужно делать форк, pull request, ждать следующего релиза и т.д. Альтернативно, можно, конечно, собирать проект со своей копией библиотеки, а не пытаться исправить уязвимость в upstream'е, но это много другой головной боли.
Официально мы про это пока ничего не объявляли, но создалось правильно, следите за новостями ;)
Посещала!
В принципе, похожие проекты уже есть, например, PureDarwin и GNU-Darwin, хотя у них, вроде как, нет Cocoa и всего высокоуровнего стека для macOS-приложений. Впрочем они могли бы, как мы, использовать реализации из проектов The Cocotron или GNUstep.
Проблема с созданием полноценной системы в том, что для неё требуется сильно больше, чем ядро и bash, нужны разнообразные драйвера, сервисы, графическая подсистема и т.п. В Linux всё это уже есть — и драйвера под практически любое оборудование, и системные сервисы вроде тех же udev, PulseAudio/PipeWire, wpa_supplicant и NetworkManager, и крутая современная графическая подсистема (DRM, KMS, Mesa, Vulkan, Wayland). В Darling мы стараемся максимально облегчить сам контейнер и использовать уже существующие на хосте сервисы, библиотеки и т.д. Для потенциальной DarlingOS пришлось бы или всё это перереализовывать, или пытаться портировать с Linux, или отказаться от большинства того, что отличает современную операционную систему от Unix 70-х годов.
Ну и потом, основная мотивация разрабатывать ReactOS вместо того, чтобы просто использовать Linux + Wine — jeditobe, поправьте меня, если я не прав :) — это потенциальная возможность использовать драйвера для Windows, которые часто всё-таки находятся в лучшем состоянии, чем их аналоги для Linux. А вот у macOS и iOS едва ли есть в этом плане преимущество перед Linux, поэтому вариант Linux + Darling подойдёт лучше всего.
Именно! Спасибо, стараемся :)
Рассчитывать не стоит и не гарантирован (когда по памяти завершают, иначе гарантирован), но в документации явно написано, что система может его вызвать в такой ситуации:
Нет, переход на ART вряд ли повлиял на работу сетевых соединений.
(Этот абзац не специфичен для Android, а верен на любой Linux-системе) Действительно, система может освобождать занятые порты не сразу после завершения державшего их процесса, а только после отправки всех буферизованных данных (это называется socket linger, и с этим часто борются с помощью
SO_REUSEADDR), но это актуально для портов с заранее известным номером. Если вы просто делаете POST-запрос, система автоматически назначит вам подходящий свободный порт, и этой проблемы не возникнет.Хабр — не Тостер, но думаю, вам стоит посмотреть с помощью сниффера, в чём разница в успешных и неуспешных запросах, как вам и порекомендовали на StackOverflow.
Ну и не могу не упомянуть, что отправка данных на сервер каждые 10 секунд — это, мягко говоря, не лучшая идея. Создавать для этого каждый раз новый сокет и забывать его закрыть — тоже.