Т. е. автор решил сделать крайне узкоспецифичную админскую задачу - организовать vpn-сервер на одном хосте, но выходить в интернет через vpn-клиент. При этом взял решение "для домохозяк", которое настроено по умолчанию на стандартный кейс "выходить в интернет через vpn-сервер". И теперь жалуется что это не тривиально, и вообще keenetic отстой. Но если вам надо решать такие задачи - берите что-то другое, зачем брать то что нацелено на другой сегмент пользователей?
PS. Стандартный кейс для связывания двух keenetic - ikev2 site-to-site, настраивается очень просто. Далее для выхода в интернет через другой роутер, вроде останется только маршрутизацию поменять.
Алгоритмические задачи, конечно, на бэкендера вообще не сдались. Они хороши для каких-нибудь мейнтейнеров ядра Линукс, разработчиков енкодеров всяких, в конце концов писателей софта под роверы на Марсе, но точно не бекедера. 99% работы бэкендера - это вытянуть правильно данные из базы, поработать над ними и положить обратно. И вот тут полно неучей которые не умеют запрашивать связи в ORM для избегания N+1 запросов, не умеющих составлять сложные запросы оптимально, да даже тупо индексы в таблице не могут правильно расставить.
Мы у себя в проекте используем полнотекстовый поиск, и могу добавить на собственном опыте два самых неудобных момента при его использовании:
1) Словари считываются каждую (!) сессию что очень замедляет запросы при больших словарях. Проблема решаема с помощью shared_lspell, но его надо компилировать. Почему это нет "из коробки" - для меня загадка.
2) Так как словари - это, по сути, файлы конфигурации то вносить слова и синонимы очень неудобно. Притом у нас БД - храни все словари в табличке, да радуйся, но нет.
Установка куки botcheck=1 - слишком банально. Обычно даже для обычного http-парсера все куки копируются из браузера ПОСЛЕ прохождения проверок, что уже обходит первый этап блокировки ботов. По хорошему нужно присылать на странице botcheck.html некий ключ и timestamp, который должен выполнить браузер в js и уже на основании вычисления устанавливать куку или ещё что. А сервер должен соответственно отсекать то что неверно.
Мне тоже больше нравится 4ка, но именно продуманным геймплеем, после него в 3шку играть "странно". Но в 4ке отвратная графика, нет нормального генератора случайных карт, и сложности с созданием модификаций, что не дало сообществу его развивать дальше. Все мечтаю о миксе 3 и 4 версии)
Стандарты менее HDR1000 можно даже не включать, в большинстве случаев это просто маркетологический обман и проблемы с отображением SDR при включенном HDR. Реального эффекта почти не будет.
Для себя же я сделал вывод, что мне HDR не нужен: на своем телеке HDR1000 провел тест, скачал один и тот же фильм в SDR и HDR, и сравнил. В итоге да, HDR ярче, но в тенях в итоге полный провал, ощущение что тупо контраст выкрутили, и в тенях стало ничего не видно. Может, конечно, что-то где-то не так и не по настоящему, но на 4 матрицах в доме везде одно и тоже: в SDR нормальная картинка где все видно, в HDR вырвиглазная контрастная картинка.
Чтобы докер билд работал, надо прописать прокси в конфигах, но только engine version>=23 /etc/docker/daemon.json: { "proxies": { "http-proxy": "http://proxy.example.com:3128", "https-proxy": "https://proxy.example.com:3129", "no-proxy": "*.test.example.com,.example.org,127.0.0.0/8" } }
Да есть статься, правда она о другой камере писалась немного. А когда появилась камера NetSurveillance, а главное роутер Keenetic, многое из той статьи стало не актуально. В частности в боте я теперь смотрю статус клиента подключаясь к API роутера, а не пытаясь arp-сканирование проводить. В целом неплохо было бы написать новую статью.
А как быть с web components и кастомными элементами? Браузер не будет знать, должен этот тэг быть самозакрывающимся всегда или нет, поэтому не определено поведение на случай не закрытого тэга. Поэтому рекомендация "давайте не будем использовать само закрывающийся синтаксис" означает что мы не можем писать <custom-input/>
Ну практика показывает, что загружается это далеко не один раз, а практически каждый раз, начиная с тупо протухания кэша статики, заканчивая постоянными релизами, а следовательно обновлением бандла.
Неудивительно, ведь теперь в spa в js зашиваются все вьюхи для компонентов, сама логика из Бэка по большей части переехала во фронтенд, и если не настроена динамическая погрузка, а все зашит в один бандл, то итоговый размер js будет жирным. А ещё зависимости погоняют зависимости и очень много кода по сути не используется, или используется в крайне редких случаях. В общем современный веб во всей красе.
На заре интернета все делалось на сервере, и получали лёгкие страницы чисто с внешним видом, а сейчас из Бэкенда фактически только rest api осталось, то есть бэк почти как тупая база данных, а вся логика и представление - во frontend.
Т. е. автор решил сделать крайне узкоспецифичную админскую задачу - организовать vpn-сервер на одном хосте, но выходить в интернет через vpn-клиент. При этом взял решение "для домохозяк", которое настроено по умолчанию на стандартный кейс "выходить в интернет через vpn-сервер".
И теперь жалуется что это не тривиально, и вообще keenetic отстой. Но если вам надо решать такие задачи - берите что-то другое, зачем брать то что нацелено на другой сегмент пользователей?
PS. Стандартный кейс для связывания двух keenetic - ikev2 site-to-site, настраивается очень просто. Далее для выхода в интернет через другой роутер, вроде останется только маршрутизацию поменять.
Алгоритмические задачи, конечно, на бэкендера вообще не сдались. Они хороши для каких-нибудь мейнтейнеров ядра Линукс, разработчиков енкодеров всяких, в конце концов писателей софта под роверы на Марсе, но точно не бекедера. 99% работы бэкендера - это вытянуть правильно данные из базы, поработать над ними и положить обратно. И вот тут полно неучей которые не умеют запрашивать связи в ORM для избегания N+1 запросов, не умеющих составлять сложные запросы оптимально, да даже тупо индексы в таблице не могут правильно расставить.
Мы у себя в проекте используем полнотекстовый поиск, и могу добавить на собственном опыте два самых неудобных момента при его использовании:
1) Словари считываются каждую (!) сессию что очень замедляет запросы при больших словарях. Проблема решаема с помощью shared_lspell, но его надо компилировать. Почему это нет "из коробки" - для меня загадка.
2) Так как словари - это, по сути, файлы конфигурации то вносить слова и синонимы очень неудобно. Притом у нас БД - храни все словари в табличке, да радуйся, но нет.
В общем, работать можно, но неудобно.
Установка куки botcheck=1 - слишком банально. Обычно даже для обычного http-парсера все куки копируются из браузера ПОСЛЕ прохождения проверок, что уже обходит первый этап блокировки ботов. По хорошему нужно присылать на странице botcheck.html некий ключ и timestamp, который должен выполнить браузер в js и уже на основании вычисления устанавливать куку или ещё что.
А сервер должен соответственно отсекать то что неверно.
Краткое содержание:
Как точно нарисовать квадрат 3х3? Попросить пользователя линейкой измерить диагональ и ввести в поле. А мы знаем супер формулу.
В общем математика - сила, а статья... ну такая.
Мне тоже больше нравится 4ка, но именно продуманным геймплеем, после него в 3шку играть "странно". Но в 4ке отвратная графика, нет нормального генератора случайных карт, и сложности с созданием модификаций, что не дало сообществу его развивать дальше. Все мечтаю о миксе 3 и 4 версии)
Добавлю в копилочку свои варианты:
торрент - deluge, он мне больше всего зашёл по интерфейсу
code-server - облачный vscode
Стандарты менее HDR1000 можно даже не включать, в большинстве случаев это просто маркетологический обман и проблемы с отображением SDR при включенном HDR. Реального эффекта почти не будет.
Для себя же я сделал вывод, что мне HDR не нужен: на своем телеке HDR1000 провел тест, скачал один и тот же фильм в SDR и HDR, и сравнил. В итоге да, HDR ярче, но в тенях в итоге полный провал, ощущение что тупо контраст выкрутили, и в тенях стало ничего не видно. Может, конечно, что-то где-то не так и не по настоящему, но на 4 матрицах в доме везде одно и тоже: в SDR нормальная картинка где все видно, в HDR вырвиглазная контрастная картинка.
В первую очередь HDR это о том, чтобы задрать яркость в определенные периоды и определенные зоны вне стандартного диапазона
Мои начальные слова такие: Стенд, кварц, Олимп, гуашь.
Подбирал по сервису исходя из двух факторов:
1) частота букв
2) старался не использовать топ гласных в начале, чтобы на последующие слова было больше вариантов
Уверен, что возможно это не самые оптимальные слова, но не угадывать слова с ними у меня ещё ни разу не получилось)
Как то офлайн приложения для такого уже прошлый век. Тут по идее же сразу захочется в поездке доступ к своим файликам с телефона.
Чтобы докер билд работал, надо прописать прокси в конфигах, но только engine version>=23
/etc/docker/daemon.json:
{"proxies": {
"http-proxy": "http://proxy.example.com:3128",
"https-proxy": "https://proxy.example.com:3129",
"no-proxy": "*.test.example.com,.example.org,127.0.0.0/8"
}
}
Ещё прокси для докера можно прописать прямо в /etc/docker/daemon.json:
{ "proxies": { "http-proxy": "http://proxy.example.com:3128", "https-proxy": "https://proxy.example.com:3129", "no-proxy": "*.test.example.com,.example.org,127.0.0.0/8" } }а почему костыльный?
Да есть статься, правда она о другой камере писалась немного. А когда появилась камера NetSurveillance, а главное роутер Keenetic, многое из той статьи стало не актуально. В частности в боте я теперь смотрю статус клиента подключаясь к API роутера, а не пытаясь arp-сканирование проводить. В целом неплохо было бы написать новую статью.
Я делал ровно тоже самое, только php и ftp - все крутится на роутере keenetic)
А как быть с web components и кастомными элементами? Браузер не будет знать, должен этот тэг быть самозакрывающимся всегда или нет, поэтому не определено поведение на случай не закрытого тэга. Поэтому рекомендация "давайте не будем использовать само закрывающийся синтаксис" означает что мы не можем писать
<custom-input/>Ну практика показывает, что загружается это далеко не один раз, а практически каждый раз, начиная с тупо протухания кэша статики, заканчивая постоянными релизами, а следовательно обновлением бандла.
Неудивительно, ведь теперь в spa в js зашиваются все вьюхи для компонентов, сама логика из Бэка по большей части переехала во фронтенд, и если не настроена динамическая погрузка, а все зашит в один бандл, то итоговый размер js будет жирным. А ещё зависимости погоняют зависимости и очень много кода по сути не используется, или используется в крайне редких случаях. В общем современный веб во всей красе.
На заре интернета все делалось на сервере, и получали лёгкие страницы чисто с внешним видом, а сейчас из Бэкенда фактически только rest api осталось, то есть бэк почти как тупая база данных, а вся логика и представление - во frontend.
если добавить "youtubepp.com" попадаем на сервис который умеет склеивать звук. Правда в РФ он сейчас не открывается.