Каждый раз, когда нужно перекинуть файл, код или ссылку с ПК на телефон (или другу в той же Wi-Fi сети), начинается классическая возня. Либо гоняешь через «Избранное» в мессенджерах (где режется качество и файлы вечно висят в облаке), либо поднимаешь локальные веб-серверы через консоль. Мне это надоело, и я решил написать свою утилиту — FlashStash.
Основная идея: софт должен запускаться в один клик, работать без интернета внутри локалки, иметь всеядный предпросмотр файлов прямо в браузере и не требовать от пользователя установки Питона или настройки окружения.
После нескольких итераций проект дорос до версии 1.6, и я хочу поделиться тем, как устроена утилита изнутри и с какими техническими проблемами пришлось столкнуться.
Что под капотом и как это работает
Бэкенд написан на Python + Flask, а фронтенд работает на чистом JS. Процесс использования максимально упрощен:
Запускается один исполняемый файл FlashStash.exe.
Программа сама определяет локальный IP-адрес компьютера, поднимает сервер и автоматически открывает веб-интерфейс в браузере хоста.
Чтобы подключить смартфон или другой ПК к общему пространству, нужно просто ввести в адресную строку браузера IP-адрес, который отображается в консоли сервера.
При этом для каждого загруженного файла в интерфейсе генерируется отдельный QR-код — это позволяет мгновенно скачивать конкретные файлы на телефон через камеру, не вбивая ссылки вручную.
Проект собран как Zero-Dependency Portable Build. Внутри архива лежит скомпилированный .exe файл со своей иконкой и встроенное портативное ядро Python. То есть утилиту можно закинуть на абсолютно «голую» Windows (желательно прямо на Рабочий стол), кликнуть, и всё сразу заведётся.
Как развивался проект: от костылей к нормальной архитектуре
В процессе разработки вылезло несколько неочевидных проблем, которые пришлось оперативно закрывать.
1. Борьба с «одноразовой» безопасностью
Изначально я добавил функцию защиты файлов паролями при загрузке. Но в первых версиях все пароли хранились в обычном Python-словаре в оперативной памяти. Стоило перезапустить сервер, как словарь очищался, файлы оставались в папке, но скачать их мог любой желающий без всякого пароля.
В версии 1.6 я переписал эту логику. Теперь все хэндлы, пароли файлов и история текстового буфера обмена намертво пишутся в локальные JSON-файлы. Данные идеально выдерживают перезапуск сервера и не нагружают систему лишними тяжелыми СУБД.
2. Закрытие уязвимости Path Traversal
Когда пишешь локальный веб-сервер для обмена файлами, легко забыть про базовую безопасность путей. В первых билдах бэкенд принимал имя файла из адресной строки практически «как есть».
Продвинутый пользователь в локальной сети мог провернуть атаку Path Traversal, отправив запрос вида ../, выйти за пределы папки обмена и стянуть системные файлы с хост-машины. Чтобы это исправить, я внедрил жесткую фильтрацию и санитаризацию входных путей через os.path.basename. Теперь бэкенд отсекает любые попытки побега из папки shared_files.
3. Всеядный предпросмотр (All-in-One)
Мне не хотелось, чтобы пользователь скачивал файл только ради того, чтобы узнать, что внутри. Поэтому фронтенд получил встроенные плееры для аудио и видео, просмотрщик картинок и текстовых документов. Из интересного — добавил просмотрщик архивов: структура файлов внутри .zip и .rar отображается прямо на веб-странице до скачивания самого архива.
Наведение порядка: Wipe_All_Data
Поскольку Питон при работе создаёт скрытый кэш (__pycache__), а папка shared_files постепенно забивается реальными файлами, перед заливкой проекта на GitHub или передачей папки другу её нужно как-то чистить. Сам запущенный Питон свои процессы и кэш удалить не может (Windows выдаёт Access Denied).
Для этого я написал отдельный служебный батник Wipe_All_Data.bat на английском (чтобы кодовая база репозитория выглядела аккуратно). Он делает три вещи:
Жестко тушит активные процессы сервера через taskkill.
Под ноль вычищает папки с файлами, паролями и текстами.
Сканирует дерево директорий и сносит весь кэш компилятора Питона, сжимая вес папки до исходного минимума.
Итоги
Проект получился именно таким, каким я хотел его видеть в повседневной жизни — легким, быстрым и независимым. Исходный код полностью открыт, пощупать портативный билд v1.6 и оценить реализацию можно на гитхабе.
Наконец видно результат работы моей системы синхронизации чатов:
Версия окна чатов
Пока концентрируюсь на работе персональных чатов (это чаты между двумя собеседниками). У такого чата отображается имя собеседника, последнее сообщение, временная метка и аватарка.
Особую сложность вызывала система кэширования медиа. Начал разрабатывать систему кэширования медиафайлов, а потом узнал что существуют готовые решения 😆
Частично реализовал работу групповых чатов. Но не полностью, с ними еще много работы. Сейчас отображается имя чата, имя собеседника, который отправил последнее сообщение, само осообщение, временная метка.
Сегодня переделывал систему отображения онлайн-статуса пользователя. Сейчас онлайн-статус пользователя вроде работает и обновляется 😅 То есть можно будет видеть кто в сети, а кто не в сети.
Сразу же добавил возможность скрывать свой статус, полезная функция для тех, кто не хочет чтобы их видели 😎
Все же пришел к тому, что нужно делать веб-версию приложения 😅 Зачем? Времена сложные, приложения могут выкидывать из магазинов (например из AppStore выкинули банковские приложения, Avito), блокировать. Размещение приложения на личном сайте поможет хоть как-то защититься от этого. Во всяком случае с сайта можно будет скачать приложение для Android или настольных компьютеров (Windows/Linux/IOS).
--
Кому интересно, можете подписаться куда-нибудь на меня, попробуете мессенджер в числе первых. Постепенно буду продолжать делиться успехами разработки :)
Итак, я подобрался к jitsi вплотную. Установить это пол беды, хотя это даже не беда, что там не ждут меня. Что не сохранил с тобой себя.... три, четыре, закончили. Настроить JWT токены это тот еще геморрой.
В начале было слово, а какое не скажу. Потому что не знаю, это все равно что спросить "а кто изобрел колесо". Естественно, после установки нужно добавить параметры что у нас не анонимные пользователи, а авторизованные. подключил в конфигах токены. И понеслась...
1 Битва. Prosody не видит токены. Видишь токены? и я не вижу, а он есть. в логах пишет: modulemanager: Unable to load module 'auth_token': /usr/lib/prosody/.../mod_auth_token.lua: No such file or directory modulemanager: Error initializing module 'auth_token': module 'inspect' not found: Суть оказалась проста, Prosody искал плагины не там, где они были. так же ему не хватало библиотеки из Lua, которая нужна для работы в jwt. Собственно, через luarocks поставил inspect. так же в конфигах нужно прописать путь к плагинам : plugin_paths = { "/usr/share/jitsi-meet/prosody-plugins/" }, кто поймет, тот поймет, а кто не поймет, тот не поймет. Да, я капитан очевидность. И..... Prosody таки увидел плагины и начал их грузить!
2 Битва. Пользователи таки стали проходить аутентификацию, но когда подключается второй клиент - давай до свидания, вылетают тут же оба. Client disconnected: connection closed. Сразу оба два.
В настройках : c2s_require_encryption = true а было false, не помогло, если что, это это настройка Prosody XMPP сервера, опять же, кто то понял, кто то нет. да и какая разница. А, ну да, эта настройка определяет обязательно ли шифрование или нет. Вскрытие показало что пациент умер от вскрытия. По любому этот параметр тоже влиял, но, как могла подумать моя многоуважаемая публика, а может и не влиял. Скорее всего да. Но, визуально ничего не поменялось, ошибки все те же самые.
Хм..... хмыкнул я, но и это не помогло. а вдруг права доступа к файлам не права доступа к файлам? а вдруг все под рутом? А у Prosody и пользователь prosody. Права установил, но и это не помогло! Хотя, вскрытие показало что все файлы были под правами рута. При этом Jicofo очень даже молодец, видит, принимает. Если что, он отвечает за управление, фокусировку, координацию участников.
Но вылеты при коннекте продолжаются.
3 Битва. Финал. Порты.
Ну по логике, когда подключение без токенов, оно работает, ну значит и машина не виновата же? А вот Фиг Вам, называется, привет, Шарик. Вскрытие в очередной раз показало что без токенов коннектится по порту 443/TCP, а с токенами используются чуть чуть другие порты, которые для медиа более эффективны: 10000/UDP и 4443/TCP.
Ну а поскольку я брал облачный vps в timeweb (ни в коем случае не реклама) то стало быть настройки где то там в панели. И, в кое то веки вскрытие показало что пациент ожил от вскрытия!!! Оно стало работать!
после выхода с конференции перекидывает на главную страницу
Да, у меня два монитора, очень удобно,
точки и запятые насыпал вот тут: .............,,,,,,,,,,,,,,,, кому важно могут брать оттуда и расставлять по своему усмотрению.
сделал следующую стадию: Календарь. учитель может сделать слот с занятием, назначить тему, цену, время, ученика. Ученик, в свою очередь, должен этот урок подтвердить.
Тут хотелось бы выслушать "отзывы и предложения" по работе слотов, что улучшить, что доделать.
желтый, как вы понимаете, неподтвержденный урок. он ожидает подтверждения от ученика, чуть позже добавлю туда клавишу "подключиться к видеоконференции".
Вид со стороны ученика:
И... как долго я ругался с этим фронтом, ненавижу js! С сервером проблем нет и небыло за все время! написал сервисы, эндпоинты, энтити, все работает, curl запросы отправляет, данные ходят во все стороны, но на странице нормально не отображается, или вообще модальное окно не открывается вовсе. Но, я победил.
следующий этап: "оставьте отзыв" на преподавателя и кастомизация подключение jitsi.
еще пришла в голову идея сделать тесты для пользователей, чтобы учитель мог сделать на платформе тестовые формы, и мог давать их своим ученикам.
точки и запятые насыпал вот тут: .............,,,,,,,,,,,,,,,, кто "чувствительный" могут брать оттуда и расставлять по своему усмотрению.
Всем привет! Давно ничего не писал про проект, потому что скрупулезно работал. Итак, она все еще разрабатывается, но, доступна по ссылке - https://learnika.ru/ пока что в демо режиме, но с рабочим функционалом. Иногда будет недоступна, когда я буду что либо с ней делать. Да, проект еще не полностью готов, и, думаю, есть наличие уязвимостей, это еще будет прорабатываться.
На данный момент - обычная регистрация через почту с одноразовым паролем с возможностью просматривать карточки уроков и возможностью написать преподавателю. Ранее хотел сделать регистрацию через госуслуги, но, это оказалось геморроем, потому что постоянно "сервис временно недоступен". потому я отложил на время госуслуги и задействовал яндекс верификацию. Чтобы начать выкладывать карточки своих уроков необходимо пройти регистрацию через яндекс. Впринципе, если с госуслугами не получится, то останусь на яндексе и переведу регистрацию полностью через него. Как ни странно, но система аутентификации у яндекса мне нравится. При регистрации защиту от ботов предоставляет google recaptcha.
Главная страница
Последнее нововведение - чаты. Реализация через webSocket, это накладывает некоторые ограничения на количество пользователей, до, 32 тысяч человек за раз там +-. Но это пока что не критично.
Чаты пока пустые, писать неком
Следующая реализация - видеоконференция и календарь. Видеоконференцию я возьму от jitsi, и кастомизирую для лёрники. календарь будет мой. В идеале что бы в чате можно было списаться пользователям, учитель откроет календарь, и поставит урок на тот день и на то время, когда это им удобно а ученик подтвердит. При этом, думаю, реализовать отмену или перенос урока нужно так же через подтверждение от обеих сторон.
Загрузка аватара пользователя и загрузка обложки урока работает по одному принципу - пережимает изображение на сервере, исходное изображение удаляется с сервера и на нем остается сильно сжатое для экономии памяти.
Вчера весь день запускал сервер. я взял обычную vps, и первое с чем я столкнулся - сайт открывается, но регистрация не работает, постоянная ошибка. логи сервера в начале показали что запросы до spring boot доходят, но сам spring их блокирует. Пришлось повозиться с конфигами nginx, но там было не сложно. Потом, при попытке зарегистрироваться, запрос от hibernate идет на БД, но запись не появляется. Магия, подумал я, но нет, по какой то причине миграция БД с созданием схемы не работала. Решил проблему прямым запросом в саму базу. И вуаля, запись появилась. Но, следующий подвох - письма не приходят, точнее, не отправляются. Ну, первое что я проверил - работают ли порты? при попытке послушать 465 порт мертвые с косами стоят и тишина... тоже самое и с 587 портом, проблему так же решил путем включения портов в панели управления хостингом. Я такого не ожидал, потому что ранее не сталкивался.
Еще немного поработал с логотипом, мучался и сам, и с нейронками, в итоге пришел к виду вот такого логотипа:
стилизованная буква "Л", как по мне, выглядит современно.
Как то так, продолжаю работу над проектом, в планах закончить и полностью запустить до нового года. Всем спасибо за внимание!
Друзья! Много ли платформ вы знаете, где для написания пользовательских приложений используется стек… веб-технологий, причём это единственный нативный способ писать программы? Услышав о HTML5 + CSS + JS, на ум приходит разве что webOS — которая используется в современных телевизорах от LG (а ранее использовалась ещё и в Palm Pre — уникальный смартфон, единственный в своём роде), а олды вспомнят ещё и про FireFox OS, в которой вся оболочка (включая многозадачность, шторку уведомлений и все приложения) также была реализована на JS. Но ни webOS, ни FFOS в своё время не суждено было стать массовыми ОС на смартфонах: сказывались аппаратные ограничения устройств, да и проблемы с портированием уже существующих приложений с других платформ (например, игр). Однако несколько лет назад, проект FireFox OS был форкнут и на свет появилась новая система, предназначенная для… умных кнопочных телефонов с LTE! И имя ей — KaiOS. Вероятно, многие мои читатели слышали о ней и о новых умных кнопочниках от Nokia. Но что из себя представляет система под капотом и чем она может быть интересна гику? Читайте в новом материале!
❯ Предыстория
В наше время, стек веб-технологий стал чуть ли не вторым по важности для разработки клиентских приложений. С появлением PWA и модных MVC-фреймворков, а также таких проектов, как Electron, визуальная составляющая многих приложений радикально поменялась: стало возможным реализовывать кастомный, гибкий и адаптивный интерфейс с поддержкой тем и анимаций буквально в несколько строчек кода. Такой подход значительно упрощает и удешевляет разработку клиентских приложений для популярных сервисов: например, «набросать» своё приложение для MP3-плеера может даже зелёный джун, который только начал писать код.
Первой попыткой сделать PWA-приложения «нативными» был, как ни странно, первый iPhone. iOS 1.0, которая в те годы ещё называлась iPhone OS, не имела AppStore и поддержки нативных ipa-приложений и предлагала просто выносить значки нужных сайтов на рабочий стол. При этом возможность отображения полноценных десктопных сайтов была одна из самых сильных сторон iPhone в те годы! Как показала практика, Стив Джобс немного поспешил с интеграцией PWA на смартфонах и в iOS 2.0 уже был добавлен AppStore, куда разработчики могли публиковать нативные и быстрые приложения!
Alcatel OneTouch Fire E — один из двух смартфонов на FireFox OS в моей коллекции!
Но всё это итак знакомо многим моим читателям: подписчики часто жалуются на то, что современные приложения жиреют и лагают, а ещё тащат за собой целый CEF и миллион npm-пакетов из-за чего даже какие-то простые приложения начинают требовать слишком большие ресурсы. Но кто бы мог подумать, что веб-стек найдет своё место на… кнопочных мобильниках! Казалось бы, дешевые кнопочники не имеют ресурсов для запуска полноценного браузера, их главная задача — именно звонить. Но ведь на складах всё ещё лежат, полагаю, целые стеллажи бюджетных смартфонных процессоров 10-летней давности, которые вполне способы запустить Android… смекаете, к чему я? :)
KaiOS появилась как форк и концептуальное продолжение провалившейся FireFox OS: система от Mozilla предлагала множество интересных концепций и шустро работала даже на очень-очень бюджетных смартфонах, несмотря на веб-направленность. Минимальные требования системы были скромными: ОС шустро работала на бюджетном ZTE Open с 256Мб ОЗУ и чипсетом MSM7225A из 2012 года. FireFox OS работала на ядре Linux, основой был браузерный движок Gecko, а поскольку Mozilla, полагаю, не смогла заручиться поддержкой вендоров чипсетов и хотела, чтобы систему мог портировать на своё устройство любой желающий, для взаимодействия с железом устройства система использовала драйвера для… Android! Поскольку Gecko собирался с использованием стандартного libc, а драйверы использовали bionic, FireFox OS активно использовала библиотеку libHybris, что позволяло портировать систему на уже существующие смартфоны с любыми чипсетами.
LG fx0 — редчайший смартфон на FireFox OS. Правда на фото он на Android :)
Идея системы простая: формально, это один большой браузер (оболочка Gaia), который при запуске приложений создаёт ещё маленькие «браузеры» (элемент webview, это не iframe). Плюсы такого подхода очевидны: отказоустойчивость (потенциально, весь рестарт Gaia — это WebView.Refresh. В случае Android — это закрытие всех приложений и перезапуск app_process), безопасность (нельзя вызвать Private API), лёгкость отладки и малый вес конечных приложений (причём вес — основной критерий для публикации приложения в официальном магазине KaiOS, пакет до 20Мб). Стоит ли говорить о том, что приложение на такое устройство сможет написать даже ребенок, а игру в стиле «Змейки» можно реализовать за пару часов? Порог вхождения значительно ниже даже чем на Android!
В основном, KaiOS разрабатывалась как система, которая должна вывести кнопочные телефоны из разряда «просто-звонилок» и позволить использовать на привычных устройствах современные мессенджеры и различные сервисы (например, тот-же YouTube). Пожалуй, это отнюдь не «прокачанные бабушкофоны», как некоторые могут подумать, а перспективные девайсы с современным железом (поддержка дисплеев высокого разрешения, 3D GPU, LTE) и заделом на будущее, пусть пока и без крутых девайсов в стиле Nokia N-серии. Концепция умных кнопочников не ограничена KaiOS: выходят различные девайсы и на Android, об одном из таких смартфонов я даже писал две отдельные статьи с обзором и моддингом.
Сейчас на барахолках можно найти дешевые девайсы на KaiOS до 2х тысяч рублей, правда свежие Nokia ценятся обычно выше. Мне же достался в подарок Nobby 240 LTE от моего читателя jameskod007, за что ему большое спасибо! Чем такие девайсы могут быть интересны гику? Давайте посмотрим!
❯ Что «под капотом»?
Под капотом у устройств на KaiOS трудятся старые и такие знакомые многим читателям бюджетные чипсеты, как MediaTek MT6572 (использовался в смартфонах до 3-4х тысяч рублей в 2014-2015), SpreadTrum SC7731E (наследник SC7731 2014 года с другим GPU) и Qualcomm 205 (судя по всему, наследник Snapdragon 200 — популярного чипсета 2014-2015 года, который использовался, например, в Lumia 520). Само собой, это позитивно сказывается на цене устройства: зачем в девайс с дисплеем 240x320 ставить 800'ый Snapdragon? :)
Значительным плюсом подобных устройств является простота обслуживания. По правде сказать, здесь и ломаться то особо нечему: дисплей относительно надежно защищен от внешнего влияния с помощью воздушной прослойки и защитного стекла, а элементная база смартфона весьма маленькая и «не ломучая». Разбирается смартфон просто: достаточно лишь открутить несколько винтов с обратной стороны корпуса и расщелкнуть телефон пластиковой картой. Что забавно — такие формы корпусов будто «унифицированы» среди производителей дешевых телефонов, никто, почему-то, не экспериментирует с корпусами в стиле а-ля Nokia N-серий.
Перед нашим взором открывается плата. К сожалению, я пока не видел на кнопочных смартфонах UART в открытом виде, иначе давно бы реализовал что-то типа такого. На плате мы можем заметить, что LTE-версия Nobby 240 работает на достаточно свежем Spreadtrum SC9820E с двумя 64-битными ARMv8 ядрами Cortex-A53 на частоте 1.3ГГц и GPU Mali T820 MP1, а также с LTE модемом. Чип выполнен по техпроцессу 28Нм, максимальное разрешение дисплея — 480x854 (т. е. DSI матрицы всё таки поддерживаются, параллельно с DBI). Весьма шустрый чипсет для девайса такого класса, его едва ли можно назвать «бабушкофонским», подобные характеристики были флагманскими для смартфонов ~2012 года. Для сравнения — простые кнопочники все еще работают на ARMv5 ядрах на частоте около 200-300МГц.
Дисплей припаян и приклеен к плате, подключен к процессору при помощи 16-битного протокола 8080, а не MIPI DSI, как в современных смартфонах. Его разрешение — классические 240x320. Поиск его замены скорее всего не составит труда, хотя точная модель контроллера мне пока неизвестна (предполагаю, либо ILI9341/ILI9325, либо ST7731, либо так любимый китайцами GC9306).
А вот клавиатура — болячка таких девайсов. По каким-то причинам, пластиковые толкатели кнопок очень быстро изнашиваются и кнопки начинают дребезжать (нажиматься несколько раз одновременно), либо не прожиматься. Это очень обидно и неприятно, но быстрофикс есть — напечатать крохотные проставки на 3D-принтере.
В остальном, конструктивно девайс вполне хорош и надежен. Корпус почти не поддается трещинам и царапкам, при аппаратных болячек его относительно легко диагностировать. Ну не замечательно ли? Давайте глянем, чем интересен девайс с точки зрения веб-разработчика!
❯ Веб-разработка
Для разработки нам потребуется совсем немного: любой текстовый редактор (хоть блокнот), FireFox 59 и platform-tools с adb для Android. В первую очередь, на смартфоне необходимо включить режим отладки, который активируется набором кода *#*#33284#*#* (DEBUG) в номеронабирателе. После этого, в шторке уведомлений появится значок «жука». На некоторых устройствах, режим отладки активируется прямо в настройках. После этого, смартфон будет виден через adb и мы сможем дебажить на нем свои приложения!
Теперь нам необходимо накатить «древний» FireFox 59, это последняя версия с поддержкой WebIDE и возможностью деплоя под FireFox OS от 2018 года. WebIDE — это дебаггер и менеджер приложений для экосистемы Mozilla, активируется с помощью хоткея Shift + F8. Не забудьте отключить авто-обновление в настройках браузера!
После этого, нам необходимо связать WebIDE с нашим смартфоном с помощью «Remote Runtime». Однако перед этим, нам необходимо форварднуть adb-сокет с помощью команды:
После этого, мы жмем «Remote Runtime» и «Runtime Info», дабы получить информацию о нашем девайсе и убедится что всё нормально:
Создаём новое приложение и вперед творить! По правде сказать, я практически не знаю, каких приложений особо не хватает на KaiOS. ВК частично есть, YouTube почти полноценный, WhatsApp тоже реализован… не хватает разве что Telegram? Но я лично не смог бы полноценно чатится с телефона такого типа (и дело не в форм-факторе), поэтому я решил запилить ради прикола приложение-виджет для просмотра погоды в моём городе :)
У каждого приложения есть манифест, который объявляет используемые разрешения, значки и различные данные, необходимые для публикации приложения в магазине приложений. Существует три типа приложений: «web» (Hosted web apps — или, фактически, PWA), «privileged», и «certified» (приложения с доступом к критичным функциям смартфона типа СМС. В привилегерованном режиме, приложения могут обращаться к службам KaiOS, таким, как например Bluetooth и настройках сети.
Сначала я сверстал простенький интерфейс для приложения. Логика простая: поскольку это приложение-виджет, при его запуске отображается прелоадер (анимация загрузки), а как только данные загружены — программа показывает блок content и скрывает анимацию загрузки. Никаких фреймворков типа React я тащить не стал, но для более сложных приложений придётся продумывать более сложную логику для реализации диалогов.
Не ругайте за <center>! Я не веб-разработчик, адаптивные верстки делать не умею :))
Фетчить данные мы будем с OpenWeatherMap, хотя можно попросить доступ к API и у Gismeteo. Формат запросов у API очень простой — фетчим данные о погоде в локации относительно координат широты/долготы, при этом встроенный API для геокодинга поможет найти координаты того или иного района в городе. Делаем вот такой GET-запрос:
queryWeather(onReady) { var req = new XMLHttpRequest(); req.onreadystatechange = () => { if(req.readyState == XMLHttpRequest.DONE) { var json = JSON.parse(req.responseText);
Вся логика программы уложилась в 85 строк кода. Преимущества веб-подхода и «жабоскрипта» при грамотном использовании очевидны, согласитесь? Опять-же повторюсь, я не веб-разработчик, мои познания в JS ограничиваются «олдовым» стилем уровня начала-середины 2010х годов, я, вон, даже jquery тащить не стал.
❯ Рут
Изначально материал должен был состоять из двух частей: обзор «клиентской» части девайса с приложениями на веб-стеке и выкидывание B2G, дабы реализовать нечто подобное одной из моих более ранних статей. Но вендор смартфона подложил «свинью»: у устройства залочен загрузчик и разблокировать его штатными средствами невозможно. Вообще, инфраструктура FireFox OS имеет много общего с Android изнутри, так что я попробовал с помощью патчера magisk'а пропатчить бут и залить в него su… но увы, девайс валился на верификации signed-образа и отказывался прошивать раздел! За это жирнющий минус вендору.
Если хотите взять подобный девайс для моддинга и экспериментов, присмотритесь к девайсам на Android, или KaiOS на базе MT6572/SC7731 — те обычно разблокированы с завода. Например, год назад я сделал первую кастомную прошивку для Android-кнопочника и написал для него кастомный лаунчер.
Я лично буду очень рад, если ЕС обяжет вендоров смартфонов давать возможность заводской разлочки загрузчиков, иначе это ущемление в правах тех людей, которые покупают смартфон с изначально открытой системой!
❯ Заключение
Вот такой материал про KaiOS у нас с вами получился. Теперь вы и сами знаете, что девайс может быть интересен не только как «бабушкофон» или продвинутая звонилка, но и как платформа для реализации каких-то собственных прикольных фишек :)
Какие применения могут быть у такого девайса? Да самые разные! Например:
Маленький фронтэнд для данных с микроконтроллера: тут уже и дисплейчик небольшой есть, и кнопки, а также GPU, если нужно показывать какие-то данные в 3D. Почему-бы и нет?
BT-плеер в машину: пилим фронтэнд к ВК Музыке/Спотику или еще какому-либо сервису, коннектим по BT и получаем миниатюрный автомобильный самодостаточный плеер, который еще и аккумулятор относительно долго держит :)
Часы с погодой: частичную реализацию этого проекта я уже представил в статье. Собственно, а почему-бы и нет? Многие смартфоны от Motorola и Sony с док-станциями сейчас так и используют. Почему бы не заюзать для этого и девайс на KaiOS?
Надеюсь вам было интересно! Пишите своё мнение, есть ли перспективы у смартфонов на KaiOS? Также у меня есть свой Telegram-канал, куда я выкладываю бэкстейдж со статей, различные заметки о ремонте, моддинге и программировании под девайсы прошлых лет и вовремя публикую линки на новые статьи. Подписывайтесь!
Насчёт машины
Друзья! Те читатели, которые подписаны на меня наверняка знают о том, что я коплю на покупку ТАЗика, дабы реализовать интересный проект с разработкой самопального ГУ "из того что было" по самому дешману. Сейчас у меня есть чуть более 100.000 рублей, из которых 8.000 рублей - донаты читателей! В Ейске, на юге, за такие деньги купить относительно живой по мотору и, что немаловажно, с +- целым дном тазик сложновато. Я даже Волгу и Москвич рассматривал как вариант, но Волга ушла, а у Москвича мотор не родной. Если вам нравятся мои статьи и вы хотите помочь материально будущему проекту - с помощью формы ниже можно помочь проспонсировать проект!
Если вы вдруг живете в Ейске или в 50км от Ейска и вы или ваши знакомые продают относительно живой ТАЗик (кроме классики, критерии - на ходу, чистые документы и не совсем панорамное дно. Машинка может быть помята, с плохим ЛКП и конечно другими косяками, машина ведь не новая!) - пишите в ТГ @monobogdan!
Приветствую друзья. Не так давно наткнулся на гитхабе на вебморду для сервера wireguard. Вполне себе, скажу я Вам, удобная штука. У меня WG крутится на одноплатнике OrangePI Zero с арамбианом на дебиане, вполне себе все встало и отлично работает. Вдруг кто-то такой же ленивый и развращенный виндой, что захочет вертеть WGшечкой не через конфиги, а через красивый интерфейс...
