Karhin’s Blog
Apps, Design and Music
Later ↑

Криптография на пальцах

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

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

Терминология

Она очень странная и непривычная: таких слов в обычной жизни не встретишь. Какие-то ключи, кодирования, шифрования, декодирования, хэши, эллиптические кривые, ааа.

Зануды будут сразу вас поправлять и морщиться, когда вы перепутаете кодирование с шифрованием, но теперь вы будете точно знать, что кодирование это про алкоголиков – это преобразование фотографий котиков в формат, подходящий для обработки другой программой, а шифрование, чтобы никто другой больше не смог посмотреть котиков, пока они передаются или хранятся. Короче, кодирование – это не про безопасность.

Кодирование и декодирование не предполагает наличие какого-то секрета или пароля, а шифрование и дешифрование предполагает. Еще помните, что хэширование – это поезд в одну сторону. Хэш вообще нельзя расшифровать.

Хэширование

Хэш – это результат хэш-функции или операции хэширования. Хэш от английского hash – беспорядок, путаница. В общем, это какое-то беспорядочное значение фиксированного размера, которое получается от некоторого вполне порядочного любого размера. Хэширование рядом с шифрованием, но не имеет к нему прямого отношения.

Вот например у вас есть фотография котика и у вашего друга есть такая же фотография котика, но нам нужно точно удостовериться, что у нас точно одинаковые котики.

Простой вариант в том, чтобы просто скинуть друг-другу эти фотографии и сравнить их 1 в 1, но что если у нас 4K HDR видео котика на один час в несколько десятков гигабайтов? Каждый раз как-то скидывать друг-другу это видео? А если видео ломается при пересылке или лучший файлообменник мессенджер, в котором мы это делаем, подменяет кадры с котиком?

Хэш-функция придёт на помощь и превратит нашего котика в бессмысленную строку! Есть очень много разных функций для хэширования, например, MD5, SHA-1 и SHA-2.

Наглядное превращение котика в 64 символа случайного текста.

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

Но это всё равно не решает проблему с тем, что котика могут подменить, а по телефону с помощью дипфейков робот зачитает нам неверный хэш, поэтому мы пойдём немного дальше: придумаем какой-то секрет, который будете знать только вы, ваш друг и никто больше.

Упрощённая схема того, как работает HMAC.

Вы прохэшируете вашего котика, добавите этот секрет к хэшу котика и потом захэшируете его ещё раз. Примерно в этом смысл ещё одного страшного термина – HMAC. С поправкой на то, что HMAC работает чуть-чуть сложнее, чтобы уменьшить количество возможных атак на ваш котообмен.

HMAC – hash-based message authentication code.

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

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

Ещё одно применение хэш-функций – это хранение паролей. Вы слышали истории про утечки баз данных сайтов или сами попадали в ситуацию, когда какой-то индюк из Индии в 3 часа ночи залогинился в вашем аккаунте в Инстаграм?

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

А вот если бы разработчик сайта захэшировал ваш пароль, то такой ситуации бы не случилось, ведь пароль в чистом виде остался бы неизвестным.

Кстати, это одна из самых главных причин использовать менеджеры паролей с уникальными паролями для всех сайтов. Придумывание паролей по маске или что-то такое спасёт вас только от автоматизированных атак, но если живой человек увидит пароль superpassword_google.com, то, наверное, он что-то заподозрит.

В идеальном мире вероятность получить одинаковый хэш для разных входных данных стремится к нулю. Если двум входным значениям соответствует одинаковое выходное, то это значит, что произошла коллизия.

Теоритически злой пёсель выдал такой же хэш, как и котик!

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

Такое случается с алгоритмами достаточно часто. Например, SHA-1 уже можно сломать за копейки. Такая же ситуация с MD5 уже много лет.

Значит ли это, что эти алгоритмы уже прямо совсем нельзя использовать? В криптографических задачах точно не стоит, но, чтобы сравнивать котиков в условиях, когда вопрос не о трёхзначных циферках, вполне себе можно.

Симметричное шифрование

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

Например, применяли шифр Цезаря или шифр сдвига, то есть брали алфавит и сдвигали его на некоторое количество символов. Ключ в данном случае – это количество символов на которое сдвинут алфавит. Такой шифр можно взломать на листке бумаги за несколько минут, попробуйте.

Расшифруйте секретное кодовое слово.

В интернетах обычно используется алгоритм AES с длиной ключа 128, 196 или 256 бит. Чем длиннее ключ, тем круче. Раньше использовали DES или 3DES (в старых системах до сих пор используют).

Современные алгоритмы шифрования – это чисто про математику и магию. Основная идея в том, чтобы из обычного сообщения получить набор кракозябр, который статистически не связан с оригинальным.

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

Откуда тогда эти истории про взломы всего, чего только можно, ведь всё же зашифровано? Но тут и секрет: обычно шифрование не взламывают.

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

  • Сгенерировать ключ.
  • Передать этот ключ собеседнику, чтобы его не узнал кто-то ещё.
  • Ключ нужно как-то безопасно хранить.
  • А если потом всё же кто-то узнал этот ключ, нужно проделать это всё повторно.
  • Ключ всё таки иногда нужно обновлять, чтобы, если украдут один ключ, не украли все фотографии котиков.

Вероятность факапа на каждом этапе очень высокая.

А в чём проблема сгенерировать случайный ключ? Ну хотя бы в том, что компьютеры разрабатывают так, чтобы они были предсказуемыми. Мы же не хотим, чтобы два плюс два в айфоне давало каждый раз новый результат.

Конечно, в современных приложениях и операционных системах придумают всякие хитрые способы для генерации случайных чисел, а в компьютеры встраивают аппаратные генераторы, но если представить, что источник случайных цифр выдаёт их неслучайным образом, то AES уже не поможет.

Офис CloudFlare с лава-лампами, которые используются для генерации случайных чисел.

Свежий показательный пример, когда всё поломалося при генерации случайных чисел на процессорах Intel.

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

Ну то есть вы сгенерировали ключ, а другое приложение уже знает этот ключ. И никто ничего не заметил, никакого взлома шифрования, шпионских устройств и Джеймса Бонда.

Ну а в чём проблема передать ключ? Никакой проблемы нет, если у вас есть возможность встретиться лично. А вот если вы живёте в разных частях планеты? Передавать ключ шифрования по общедоступным каналам, это не самая лучшая идея.

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

Так а с хранением что? Положить ключ на рабочий стол или в любое другое место можно, но к нему могут иметь доступ другие приложения, которые могут его и украсть. Ну и вы же слышали про вирусы?

А ещё внезапно ваш ключ засинхронизируется каким-то модным приложением в эти облака, ваш пароль от аккаунта куда-то утечёт и его взломают. Кто-то бесплатно получит ваши ключи.

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

Например, у Apple есть Secure Enclave – это отдельный сопроцессор, который умеет в аппаратное шифрование, генерацию случайных чисел и имеет изолированную от всего остального мира память. Плохая новость в том, что даже в этом сопроцессоре находят уязвимости.

Ассиметричное шифрование

Ассиметричное шифрование так называется, потому что в нём используется целых два ключа: один для шифрования, а второй для расшифрования. В симметричном один ключ для всего.

Ключ для шифрования называется публичным, а ключ для дешифрования приватным. Публичный ключ можно налепить себе на лоб или набить татуировкой CYBERPUNK, но приватный нужно прятать под подушкой и никому не показывать.

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

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

Мы всё так же сгенерируем AES ключ, которым зашифруем котика. Сгенерированный AES ключ мы зашифруем публичным ключом нашего друга.

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

А почему просто не зашифровать всё вместе публичным ключом друга? Можно и так, это тоже будет работать, но ассиметричные алгоритмы работают значительно медленнее, чем симметричные. Помните же, что мы собирались 4K HDR видео отправлять?

А какие подводные? Вам до сих пор точно нужно знать, что публичный ключ принадлежит вашему собеседнику и что приватный ключ вашего собеседника не украли. А ещё есть классическая атака, которая называется человек посередине или Man in the middle (MITM).

Электронные подписи

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

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

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

Обычно подписывается не всё сообщение или весь файл, а его хэш.

Сертификаты

Рядом с электронными подписями и публичными ключами часто звучит слово сертификат. Сертификат – это файл специального формата, который описывает публичный ключ.

А ещё сертификаты тоже подписывают, но другие люди или программы. Так формируются цепочки доверия. На этой технологии строится весь этот безопасный интернет и HTTPS, но про это в другой раз.

Сертификат сайта, который вы смотрите.

Сквозное шифрование

Сквозное шифрование – это не какой-то алгоритм шифрования, а подход к тому, как организован обмен данными.

Сейчас это мастхэв в мессенджерах, поэтому попытаюсь объяснить на абстрактном примере. И по большому секрету скажу, что в iMessage применяется именно такая схема.

Основной прикол в том, что у вас на устройстве генерируется публичный и приватный ключи. Публичный ключ уходит на сервер, а приватный никогда не покидает ваше устройство. Так для каждого вашего устройства.

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

  • Генерируется одноразовый AES ключ для симметричного шифрования.
  • Этим ключом шифруется текст сообщения, фотография, видео и всё остальное.
  • Одноразовый ключ шифруется публичным ключом собеседника.
  • Комбинация из зашифрованного ключа и текста хэшируется и подписывается вашим ключом.
  • Всё это повторяется для каждого устройства собеседника.
  • Все зашифрованные сообщения отправляются на сервер, а сервер уже по возможности доставляет их на устройства вашего собеседника отсюда и статусы доставки сообщений.

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

С помощью такой многоходовки, никто, кроме вас и собеседника, не может прочитать сообщение. Отсюда и само название “сквозное”.

А это прямо супер-пупер безопасно? Неа. Это не делает вашу переписку абсолютно безопасной и защищённой. Вернёмся к MITM или человеку посередине.

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

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

Но у мессенджера нет возможности посмотреть публичный ключ собеседника, что это значит? Что вас просят поверить на честное слово, что никто не подменяет ключ. Решайте сами.

Что ещё можно почитать?

Много всего. Если стало интересно и хочется почитать ещё про криптографию и безопасность, то вот вам оптимистичная цитата из книги “Практическая криптография” (Шнейер Брюс):

Чтобы заниматься проектированием безопасных систем, необходимо самому стать хитрым и изворотливым. Найти слабые места в собственной работе сможет только тот, кто сам начнет думать как злоумышленник. Разумеется, это повлияет и на остальные аспекты вашей жизни. Каждый, кто работал с криптографией на практике, испытал это чувство. Начав думать о том, как нападать на системы, вы будете применять это ко всему, что вас окружает. Вашу голову заполонят кошмарные мысли о том, как можно перехитрить людей и как они могут перехитрить вас. Криптографы – это профессиональные параноики. Через некоторое время вы либо научитесь отделять профессиональную паранойю от реальной жизни, либо просто сойдете с ума.

Самая большая проблема интерфейсов современных мессенджеров

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

А ведь знаете, я и сам своего рода разработчик мессенджеров. Раньше мы с  Тимуром делали Ghostly.

Сейчас фактически все интерфейсы мессенджеров или частей сервисов, связанных с обменом сообщений, строятся по единому паттерну.

В обычной презентации – это двухколоночный интерфейс со списком диалогов и активным чатом, а в компактной – обычный стек навигации. Взгляните на Telegram, Signal, Viber, Twitter, Instagram или веб-версию Ghostly.

Всем знакомый двухколоночный интерфейс.

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

От отдельных окон для всего постепенно начали отказываться и переходить к интерфейсу с вкладками, но и у него есть проблемы.

  • Нельзя увидеть последнее сообщение от собеседника без открытия вкладки.
  • Вкладок становится слишком много, ведь список контактов постепенно в них переползает, если их не закрывать.
Интерфейсы ICQ разных лет, которые я нашёл на реддите.

Если помните, то и в браузерах когда-то все страницы открывались в отдельных окнах, но потом произошла революция вкладок, потому что десятки окон – это жесть! А теперь пытаются решить проблему с сотнями вкладок. Ох уж этот компуктер саенс.

После вкладочных интерфейсов на сцену вышел двухколоночный интерфейс, который закрыл все проблемные места предыдущих итераций и стал фактически стандартом.

  • Сразу видно с кем ты общался последний раз.
  • Сразу видно последнее сообщение в чате, а ещё статус доставки и прочтения.
  • Нет сотен вкладок и нет сотен окон.

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

Но при этом нет возможности просматривать чат и отвечать в другой параллельно. Сохранение контекста не работает.

Зачем это нужно?

Простой сценарий: вы раз в год открыли мой канал в телеграме и начали листать к старым постам, наткнулись на комментарии и решили устроить срач. В процессе срача вам пришло сообщение на которое нужно срочно ответить.

Что вы делаете?

В компактной презентации возвращаетесь на три-четыре экрана назад, открываете чат и отвечаете на сообщение, а потом снова проходите через четыре экрана и только потом возвращаетесь к срачу.

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

Как это пытается решить двухколоночный интерфейс?

Ну примерно никак. Придумывают всякие сохранения скролла, которые не работают, а еще черновики, чтобы не потерялись сообщения.

Как можно решить эту проблему?

А я не знаю! Но знаю компромиссы, которые могут упростить жизнь.

На айпадах и десктопах есть поддержка окон. Она ещё есть в андроиде нативно, но на мобиле это работает отвратительно. Можно просто добавить возможность открывать чат в новом окне, как это было в старом добром 2007. Такая функция есть в iMessage, но нет в Telegram и большинстве мессенджеров.

iMessage позволяет открыть чат в отдельном окне.

На мобилах до сих пор не придумали какого-то нормального способа показывать древовидную навигацию, а отдельные окна уже дурно пахнут. Максимум, который есть у человечества, таб бар с несколькими независимыми стеками навигации.

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

DALL-E: я снова верю в технологии

DALL-E – это новая система на основе искуственного интеллекта, которая умеет преобразовывать текст на естественном языке в изображения.

Несколько месяцев пускал слюни на картинки, которые публикуют в твиттере люди с инвайтами. В конце июля в блоге сервиса появился анонс с тем, что разослано уже более миллиона приглашений. Заветное письмо пришло 4 августа.

Увидел и завизжал, как свинья!

Когда начал регистрироваться, немного расстроился. Будьте готовы к тому, что сервис не принимает белорусские карты и белорусские телефонные номера. А ещё может не пустить к себе с белорусского IP адреса.

Картинки по запросу The photorealistic cat eats pepperoni pizza and drinks beer at sunset.

115 запросов стоят 15$. На один запрос генерируются 4 изображения.

Единственный недостаток в том, что очень легко увлечься и потратить несколько десятков запросов на вариациии “кот читает газету” или “кот ест пиццу” в исполнении разных художников, потому что интересно же! Со мной так и было!

Кстати, попробуйте угадать, для какой картинки, какой художник брался за референc.

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

А ещё с ним легко генерировать иллюстрации для интерфейсов. Я вот рисовать не умею, а хорошие картинки стоят дорого. Немного фотошопа, чтобы довести до ума, и можно забирать в приложение.

Уже очень давно не удивлялся технологиям. Но с DALL-E снова готов поверить, что что-то новое и классное появляется в IT. А не какая-то НФТ херня веб3.0.

Кстати, можете попробовать бесплатный Craiyon (бывший DALL-E mini), если не хотите ждать приглашение от OpenAI. Правда, над ним всем смеются, потому что там получаются криповые изображения. Я вас предупреждал.

Правильная реализация UIActivityViewController в SwiftUI

В iOS 16 добавлен ShareLink, который полностью решает проблему. Если вы собираетесь поддерживать версии iOS до 16, то можете читать дальше.

С помощью Activity View Controller можно предоставить пользователю функции для взаимодействия с контентом в других приложениях: копирования, публикации в социальные сети, отправки через мессенджеры и многие другие функции.

К сожалению, Apple до сих пор не представили нормального способа создания UIActivityViewController в контексте SwiftUI. Как и не сделали ещё больше десятка мелких, но необходимых вещей для базового приложения.

Самым простым и логичным решением кажется оборачивание в UIViewControllerRepresentable, как в топовом ответе на StackOverflow, и представление через .sheet().

struct ActivityViewController: UIViewControllerRepresentable {
    var activityItems: [Any]
    var applicationActivities: [UIActivity]? = nil
    
    func makeUIViewController(context: UIViewControllerRepresentableContext<ActivityViewController>) -> UIActivityViewController {
        return UIActivityViewController(activityItems: activityItems, applicationActivities: applicationActivities)
    }
    
    func updateUIViewController(_ uiViewController: UIActivityViewController, context: UIViewControllerRepresentableContext<ActivityViewController>) {}
}

Всё это хорошо работает на iPhone. Однако у этой реализации есть один большой недостаток: Activity View будет занимать весь экран iPad, а в macOS меню будет торчать не там, где нужно.

Представление Activity View курильщика в iPadOS и macOS.

Основная причина некорректного поведения в том, что в UIKit приложении для представления UIActivityViewController требуется указывать sourceView и sourceRect, что явно указано в документации. Приложение на iPad или macOS просто упало бы без этих атрибутов, но в SwiftUI поведение изменили.

On iPad, you must present the view controller in a popover. On iPhone and iPod touch, you must present it modally.

Представление Activity View здорового человека в iPadOS и macOS.

Если вы используете SwiftUI из UIKit, то просто передайте координаты и размеры вашей кнопки в UIViewController. Имея координаты, можно установить необходимую позицию для UIActivityViewController. Получить координаты для View можно через .overlay() и GeometryReader. Не очень красиво, но работает.

protocol MyUIViewDelegate: AnyObject {
    func shareButtonFrameChanged(frame: CGRect)
}

.overlay(GeometryReader { proxy -> AnyView in
    delegate?.shareButtonFrameChanged(
        frame: proxy.frame(in: CoordinateSpace.global)
    )
    return AnyView(Rectangle().fill(.clear))
})

Что делать, если вы хотите писать только на SwiftUI? Я попытался воссоздать нормальное поведение через popover. В iPadOS меню начало отображаться ровно по середине кнопки, но откорректировать его положение не получилось. В macOS поведение вообще не изменилось.

Но приложение нужно сделать уже позавчера, поэтому будем хакать поведение. Apple уже несколько лет не может разобраться с поддержкой нескольких окон в iPadOS, поэтому нужно добавить несколько магических расширений для того, чтобы получить UIViewController, в котором размещается кнопка шаринга.

extension UIApplication {
    
    var keyWindow: UIWindow? {
        return UIApplication.shared.connectedScenes
            .filter { $0.activationState == .foregroundActive }
            .first(where: { $0 is UIWindowScene })
            .flatMap({ $0 as? UIWindowScene })?.windows
            .first(where: \.isKeyWindow)
    }
    
    var keyWindowPresentedController: UIViewController? {
        var viewController = self.keyWindow?.rootViewController
        if let presentedController = viewController as? UITabBarController {
            viewController = presentedController.selectedViewController
        }
        while let presentedController = viewController?.presentedViewController {
            if let presentedController = presentedController as? UITabBarController {
                viewController = presentedController.selectedViewController
            } else {
                viewController = presentedController
            }
        }
        return viewController
    }
    
}

Кнопку шаринга нужно разместить в Geometry Reader, чтобы получить её координаты. .overlay() уже не подойдёт, так как он будет изменять состояние View, но и код станет проще.

GeometryReader { proxy in
    Button(action: {
        let rect = proxy.frame(in: CoordinateSpace.global)
        let activityViewController = UIActivityViewController(activityItems: [URL(string: "https://karh.in/")!], applicationActivities: nil)
        if let vc = UIApplication.shared.keyWindowPresentedController {
            activityViewController.popoverPresentationController?.sourceView = vc.view
            activityViewController.popoverPresentationController?.sourceRect = rect
            vc.present(activityViewController, animated: true, completion: nil)
        }
    }, label: {
        Image(systemName: "square.and.arrow.up")
            .font(.system(size: 32))
    }).buttonStyle(.bordered)
}.frame(width: 48, height: 48)

Плохая новость: это может перестать работать в следующих версиях 🤡. Хорошая новость в том, что теперь Activity View будет появляться в нужном месте, а если даже поведение окон поменяют, то приложение не упадёт, а просто не отобразит меню.

Представление Activity View в SwiftUI здорового человека.

Полезные ссылки по теме:

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

Запускаем Chrome OS Flex

Google запустил открытое тестирование операционной системы Chrome OS Flex. Обещают, что будет работать даже на очень старом ПК или маке. Я не поверил и решил проверить: рассказываю про впечатления, как установить и небольшую проблему, с которой столкнулся. Если кратко про впечатления, то мне очень понравилась.

Минимальные системные требования:

  • 64-разрядный процессор Intel или AMD;
  • 4 гигабайта ОЗУ;
  • 16 гигабайтов постоянной памяти.

Установка

Можно заполнить форму на главной странице с запросом раннего доступа, а можно сразу пройти к гайду, который откроется после заполнения формы. Не очень понял, зачем её заполнил.

Для установки нужна флешка минимум 8 гигабайтов, установленный гугл хром с расширением Chromebook Recovery Utility. Расширение работает только на маке и виндоус, на линуксе записать не получилось.

Втыкаем флешку, запускаем расширение, выбираем производителя Google Chrome OS Flex, продукт Chrome OS Flex (Developer-Unstable), ждём несколько десятков минут загрузку и запись операционной системы.

Не без приколов, конечно.

Перезагружаем компьютер, загружаемся с USB. Я запускал операционную систему на старом Lenovo Y510P и у меня возник прикол: чёрный экран после загрузочного с логотипом Google Chrome. Система издавала какие-то звуки, но на экране пустота: сделал верный вывод, что проблема с GPU. Уже думал, что пора бросить это дело, но вспомнил, что в моём старике целых три видеокарты. Одну видеокарту можно достать, что я и сделал.

Вот это технологии делали в 2013 году.

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

Теперь это не виндоноут, а миленький хромбук.

Решил, что нужно продолжить тестирование и нашёл ноутбук динозавра с ещё более впечатляющими характеристиками – HP 450 G2. У этого компьютера как раз минимальные требования для этой операционной системы. Думаю, что вы представляете, как он работает на последней виндоус (никак).

Как тебе такое, Сатья Наделла?

Впечатления

Первые впечатления обманчивые, но мне понравилось. Камера, микрофон, Wi-Fi, Bluetooth и другая периферия заработали прямо из коробки. На обычном линуксе пришлось бы еще два часа возиться и искать нужные пакеты.

Нарядный лаунчпад, как в макос.

Самое главное – она реально быстрая. Даже на обычном жестком диске, на старом процессоре и с 4 или 8 гигабайтами оперативной памяти. После виндоус, где приложения могут запускаться по 30 секунд или минуте на такой конфигурации, как глоток свежего воздуха.

Все приложения в Chrome OS – это веб-приложения, поэтому у меня возник логичный вопрос, как кодить. Оказалось, что всё проще простого и можно запускать линукс приложения через Crostini. Я не попробовал запустить Android Studio или VS Code, потому что под рукой только стик на 16 гигабайт, но кажется, что с этим не будет проблем.

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

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

А зачем это всё, когда есть убунту/дебиан/аниме? Давно хотел написать про то, почему я не использую линукс на основном компьютере, но люблю его на серверах и в эмбеддед. За компьютером хочется работать, а не заставлять его работать. К сожалению, в большинстве дистрибутивов наоборот и, скорее всего, так и будет. Гугл снова выпустил дистрибутив лучше бубунты.

Earlier ↓