Проект внутренний, он живёт внутри нашей панели управления хранилищем и плотно завязан на нашу инфраструктуру, поэтому выкладывать его в open source мы не планируем.
В статье я хотел показать сам подход, его можно повторить у себя под свою инфру.
Речь больше про идею и реализацию, прокси берёт access key из запроса, по таблице в памяти находит, на каком кластере живёт ключ, и отправляет запрос туда как есть, подпись при этом проверяет сам кластер.
Если интересно, могу отдельно написать подробнее, как это устроено внутри.
2.4 ГГц на самом SoC: phy0, драйвер ath11k, узел qcom,ipq9574-wifi. 5 ГГц отдельным QCN9274 по PCIe: phy1, ath12k_pci, 17cb:1109. У первого только Band 1, у второго только Band 2. Больше радио нет.
На шине тоже пусто: корневой порт и одно устройство. У IPQ9574 четыре контроллера PCIe, в дереве включён один, pcie@20000000, три остальных disabled.
QCN9274 сам по себе 6 ГГц умеет, его в другие платы ставят именно под это. Здесь board data отдаёт верхнюю границу 5835 МГц, и драйвер 6 ГГц не поднимает.
Спасибо, полез проверять по даташитам, и для FTDI вы правы. У FT232R порог входа на UART-пинах от 1.0 до 1.5 В при любом VCCIO (таблица 5.4 в даташите), так что 1.8 В он читает с запасом. С дешёвыми адаптерами уже не так гладко, у CP2102 и CH340 VIH от 2.0 В, то есть 1.8 В формально ниже нормы. Скорее всего тоже заведётся, но если полезут битые символы, дело может быть как раз в этом.
Ещё момент, у всех этих чипов RX подтянут к своему питанию (у FT232R через 200 кОм, у CH340 подтяжка заметно сильнее), поэтому немного тока всё равно пойдёт в 1.8-вольтовый пин роутера через защитные диоды. Для чтения лога это не страшно, но на адаптере с CH340 я бы поставил перемычку на 3.3 В, а не на 5.
Так что для этой истории такого подключения хватило бы, бутлог сразу показал бы BaseR link failed и зависание, и вышло бы быстрее, чем с логами во флеш. А вот писать в консоль, например остановить U-Boot и загрузить образ по TFTP, так уже не получится, там нужен нормальный преобразователь уровней.
Да, тут согласен, написал коряво. Мысль была простая: это не про язык общения внутри команды, а про язык интерфейса для разных пользователей.
Внутри команды люди хоть на английском, хоть на русском могут общаться, но пользователю всё равно удобнее, когда кнопки и ошибки в интерфейсе на его языке.
Спасибо, что ткнули в это место, поправлю формулировку в статье.
По верхнему уровню у нас, конечно, есть пересечение - две панели, S3, передача файлов, прогресс задач. Я не пытаюсь делать вид, что таких инструментов больше нет, рынок уже давно не пустой.
Разница скорее в подходе. AeroFTP выглядит как универсальный клиент, когда нужен один инструмент сразу под много протоколов. Я же делал акцент на другом - на повседневной работе именно с S3 и S3-compatible, где важны не только «скачал/залил», но и вся рутина вокруг бакетов, версий, ACL, multipart, очереди и особенностей совместимых endpoint.
Поэтому это не история - «кто лучше вообще». Если нужен комбайн на все случаи - AeroFTP может быть отличным вариантом. Если основная работа крутится вокруг S3, мой клиент заточен именно под такой сценарий.
Да, сейчас проект в формате бинарных релизов, без открытого исходного кода. Это осознанное решение на текущем этапе. В статье я это отдельно и явно допишу, чтобы не было ощущения недосказанности: формат проприетарный, исходники пока не публикуются, ставить или не ставить каждый решает сам.
При этом я не называл проект open source и не обещал аудит кода сейчас. Поэтому формулировка про “обман” мимо. Можно не принимать такой формат, это абсолютно нормально. Но лучше спорить с тем, что реально заявлено, а не с тем, что додумали за меня.
Ваш критерий “без кода не запускаю на рабочих машинах” понятный и здравый. Тогда тут всё просто: вы пропускаете этот релиз, я двигаюсь в своём формате дальше. Без обид и без попытки кого-то переубедить.
Если хотите пользы, приносите факты: конкретный баг, шаги, где ломается. Если хотите продолжать в формате “либо open source по моим правилам, либо всё мусор”, это не про качество софта, это про попытку диктовать чужому проекту свои условия. Такой диалог мне не интересен. Формат публикации я обозначил прямо, дальше каждый сам решает, пользоваться или проходить мимо.
спасибо за объективную оценку, ваш комментарий очень важен для нас :) на ваш код я тоже смотрел помнится уже давно, здорово что решили делать на Rust, и прекрасно что вы как никто освоили как это сейчас модно “вайбкодинг” не в обиду исключительно мое сугубо-личное мнение, в любом случае приятно что заглянули и немного времени уделили прочтению но сути вы так и не поняли к сожалению.
Далее кратко про ваш продукт:
раз речь про доверие и качество, я тоже посмотрел ваш код. Там есть хорошие инженерные вещи, но и колкие моменты тоже: заглушка repository = https://github.com/org/s4, публичные demo-логины/ключи в README, и мелкие косяки в примерах конфигурации.
Для раннего проекта это не катастрофа, но тогда и тон “я один делаю правильно” выглядит странно.
У меня тоже ранний этап, только другая модель публикации.
Чтобы без недомолвок: да, на GitHub у меня сейчас нет открытого исходного кода. Я использую его как площадку для релизов, changelog и обратной связи.
GitHub давно уже не только про open source код, там много проектов живут как release‑страницы с документацией и issue‑трекером, это нормальная практика.
Почему не открыл код прямо сейчас: не хочу делать это «для галочки». Сначала хочу спокойно закрыть вопросы по формату публикации, лицензии и тому, как это потом нормально сопровождать.
По комментариям к статье тоже поясню: я никого не прошу писать хвалебные отзывы, люди пишут как чувствуют.
Если для вас принципиально только open source формат, это ок, просто у проекта сейчас другой этап.
Прошу строго не судить, моя первая статья на хабре, в следующей постараюсь раскрыть больше деталей и рассказать более подробно про все пункты на которые вы указали
Информация
В рейтинге
170-й
Дата рождения
Зарегистрирован
Активность
Специализация
Системный администратор, Инженер по доступности сервисов
Проект внутренний, он живёт внутри нашей панели управления хранилищем и плотно завязан на нашу инфраструктуру, поэтому выкладывать его в open source мы не планируем.
В статье я хотел показать сам подход, его можно повторить у себя под свою инфру.
Речь больше про идею и реализацию, прокси берёт access key из запроса, по таблице в памяти находит, на каком кластере живёт ключ, и отправляет запрос туда как есть, подпись при этом проверяет сам кластер.
Если интересно, могу отдельно написать подробнее, как это устроено внутри.
Тут не так. Полез смотреть, что реально на плате.
2.4 ГГц на самом SoC: phy0, драйвер ath11k, узел qcom,ipq9574-wifi. 5 ГГц отдельным QCN9274 по PCIe: phy1, ath12k_pci, 17cb:1109. У первого только Band 1, у второго только Band 2. Больше радио нет.
На шине тоже пусто: корневой порт и одно устройство. У IPQ9574 четыре контроллера PCIe, в дереве включён один, pcie@20000000, три остальных disabled.
QCN9274 сам по себе 6 ГГц умеет, его в другие платы ставят именно под это. Здесь board data отдаёт верхнюю границу 5835 МГц, и драйвер 6 ГГц не поднимает.
Спасибо, полез проверять по даташитам, и для FTDI вы правы. У FT232R порог входа на UART-пинах от 1.0 до 1.5 В при любом VCCIO (таблица 5.4 в даташите), так что 1.8 В он читает с запасом. С дешёвыми адаптерами уже не так гладко, у CP2102 и CH340 VIH от 2.0 В, то есть 1.8 В формально ниже нормы. Скорее всего тоже заведётся, но если полезут битые символы, дело может быть как раз в этом.
Ещё момент, у всех этих чипов RX подтянут к своему питанию (у FT232R через 200 кОм, у CH340 подтяжка заметно сильнее), поэтому немного тока всё равно пойдёт в 1.8-вольтовый пин роутера через защитные диоды. Для чтения лога это не страшно, но на адаптере с CH340 я бы поставил перемычку на 3.3 В, а не на 5.
Так что для этой истории такого подключения хватило бы, бутлог сразу показал бы BaseR link failed и зависание, и вышло бы быстрее, чем с логами во флеш. А вот писать в консоль, например остановить U-Boot и загрузить образ по TFTP, так уже не получится, там нужен нормальный преобразователь уровней.
Да, тут согласен, написал коряво. Мысль была простая: это не про язык общения внутри команды, а про язык интерфейса для разных пользователей.
Внутри команды люди хоть на английском, хоть на русском могут общаться, но пользователю всё равно удобнее, когда кнопки и ошибки в интерфейсе на его языке.
Спасибо, что ткнули в это место, поправлю формулировку в статье.
сравнение с AeroFTP реально в тему.
По верхнему уровню у нас, конечно, есть пересечение - две панели, S3, передача файлов, прогресс задач. Я не пытаюсь делать вид, что таких инструментов больше нет, рынок уже давно не пустой.
Разница скорее в подходе. AeroFTP выглядит как универсальный клиент, когда нужен один инструмент сразу под много протоколов. Я же делал акцент на другом - на повседневной работе именно с S3 и S3-compatible, где важны не только «скачал/залил», но и вся рутина вокруг бакетов, версий, ACL, multipart, очереди и особенностей совместимых endpoint.
Поэтому это не история - «кто лучше вообще». Если нужен комбайн на все случаи - AeroFTP может быть отличным вариантом. Если основная работа крутится вокруг S3, мой клиент заточен именно под такой сценарий.
Да, сейчас проект в формате бинарных релизов, без открытого исходного кода. Это осознанное решение на текущем этапе. В статье я это отдельно и явно допишу, чтобы не было ощущения недосказанности: формат проприетарный, исходники пока не публикуются, ставить или не ставить каждый решает сам.
При этом я не называл проект open source и не обещал аудит кода сейчас. Поэтому формулировка про “обман” мимо. Можно не принимать такой формат, это абсолютно нормально. Но лучше спорить с тем, что реально заявлено, а не с тем, что додумали за меня.
Ваш критерий “без кода не запускаю на рабочих машинах” понятный и здравый. Тогда тут всё просто: вы пропускаете этот релиз, я двигаюсь в своём формате дальше. Без обид и без попытки кого-то переубедить.
Если хотите пользы, приносите факты: конкретный баг, шаги, где ломается. Если хотите продолжать в формате “либо open source по моим правилам, либо всё мусор”, это не про качество софта, это про попытку диктовать чужому проекту свои условия. Такой диалог мне не интересен. Формат публикации я обозначил прямо, дальше каждый сам решает, пользоваться или проходить мимо.
спасибо за объективную оценку, ваш комментарий очень важен для нас :) на ваш код я тоже смотрел помнится уже давно, здорово что решили делать на Rust, и прекрасно что вы как никто освоили как это сейчас модно “вайбкодинг” не в обиду исключительно мое сугубо-личное мнение, в любом случае приятно что заглянули и немного времени уделили прочтению но сути вы так и не поняли к сожалению.
Далее кратко про ваш продукт:
раз речь про доверие и качество, я тоже посмотрел ваш код. Там есть хорошие инженерные вещи, но и колкие моменты тоже: заглушка repository = https://github.com/org/s4, публичные demo-логины/ключи в README, и мелкие косяки в примерах конфигурации.
Для раннего проекта это не катастрофа, но тогда и тон “я один делаю правильно” выглядит странно.
У меня тоже ранний этап, только другая модель публикации.
Чтобы без недомолвок: да, на GitHub у меня сейчас нет открытого исходного кода. Я использую его как площадку для релизов, changelog и обратной связи.
GitHub давно уже не только про open source код, там много проектов живут как release‑страницы с документацией и issue‑трекером, это нормальная практика.
Почему не открыл код прямо сейчас: не хочу делать это «для галочки». Сначала хочу спокойно закрыть вопросы по формату публикации, лицензии и тому, как это потом нормально сопровождать.
По комментариям к статье тоже поясню: я никого не прошу писать хвалебные отзывы, люди пишут как чувствуют.
Если для вас принципиально только open source формат, это ок, просто у проекта сейчас другой этап.
Прошу строго не судить, моя первая статья на хабре, в следующей постараюсь раскрыть больше деталей и рассказать более подробно про все пункты на которые вы указали