> сервер должен находиться географически за ее пределами.
CityCat4, хех, в теории - да, а вот по факту (на сегодня) - нет. Видимо, на серверных площадка (по крайней мере на некоторых) нет ТСПУ. Может быть это временно. По крайней мере для двух из двух моих серверов на разных провайдерах это так - но в РФ, но ютуб работает хорошо.
Как проверить торможение ютуба c какого-нибудь сервера (ну или из дома):
Этой командой мы качаем тестовый 100М файл с селектела, но в SNI используем имя ютубовского сервера.
Если есть блокировка по SNI (а ютуб так блочат) то работать не будет (или будет едва-едва).
Этой же командой, кстати, можно убедиться, что дело не в серверах гугла, а в блокировке на ТСПУ. Меняем имя хоста на любое другое (googlevideo -> g00glevideo) - и там где раньше он не работал - теперь работает.
Так можно за несколько секунд проверить, подходит ли российский VPS для обхода или нет.
Кстати, раз средства обхода советовать сейчас нельзя, я просто бессовестно (но зато легально) порекламирую хостера - у firstbyte.ru есть тарифы до 100 рублей, и вроде бесплатный тестовый доступ на 24 часа (достаточно, чтобы выполнить тот тест).
А Аезы тоже (еще проще даже, совсем в два клика) есть "терминатор" - доступ на виртуалку на 15 минут бесплатно и без смс. Мне достались московские сервера (может случайно, может всегда московские дают) - и на них тоже не тормозится. Так что 3/3 российских хостера, где я мог проверить - не блокируют ютуб.
Я сделал у себя так - у меня Raspberry Pi и ТВ LG, ТВ хоть и "модный", но не умеет (в штатном виде) ни в сторонние приложения, ни в vpn, ни даже прокси. Поэтому у меня на rpi стоит wireguard, включил там форвардинг и маскарадинг, и адрес rpi указал на телевизоре в качестве default gateway.
Можете такую же комбинацию сделать. Единственная сложность - если выключить комп (или перенастроить на нем сеть) - телевизор перестанет работаеть.
CityCat4, у нас импортные товары продаются же. Псевдоотечественные (из импортной комплектухи) - тоже. Это все стоит денег. Эти деньги не вагонами же отправляют, а банковскими переводами. Значит, какое бы впечатление от новостей не было - в реальности банковские переводы работают. Сложнее стало, не так проще как раньше - но можно. Один мой друг сам ведет международный бизнес.
Не все банки под санкциями (хотя многие, надо выбирать). Сейчас райф пока держится, про другие не знаю. Газпромбанк, возможно, тоже, как ни смешно (т.к. через него деньги за нефть и газ). Ну и что-то из мелких может быть.
momvov1, надо прояснить - к какому именно файлу базы случается эта ошибка (и посмотреть, тот ли это файл, как ожидалось). Вполне может быть вариант, что вы ХОТЕЛИ каждое приложение увязать с его собственой базой, но где-то ошибка и поэтому они все открывают один и тот же файл. Попробуйте печатать имя файла базы максимально близко к коду его открытия, а еще посмотреть, нет ли имени файла в exception, и может быть его еще распечатать.
Если бы у вас в самом деле они были полностью изолированы - то каждое приложение даже не знало бы, что другое использует какую-то другую базу.
CityCat4, не по сути вопроса, но в порядке трепа (про ленивые *опы). Это в 2000-2005 году ленивая *опа - это тот, кто от статических сайтов не перешел на динамические, которые через perl/cgi или Apache/PHP/MySQL схеме работают. А не ленивые - переходили, и у них на сайте даже guestbook работал через CGI.
Сейчас генеральная линия партии колебнулась обратно, но два раза в одну реку нельзя, поэтому река уже другая. Сейчас "моден" JAMStack - статичные сайты, которые, во-первых, раздаются из статичных файлов (то есть, раздаются быстро и сервер не бывает перегружен, даже в "черную пятницу" может быстро отдавать странички) , а во-вторых, раздаются через CDN, то есть, скорость загрузки - максимальная.
Это не просто мода, есть объективные причины: Загрузка и скорость работы сайта по такой технологии гораздо выше. Поэтому 1. Пользователи получают работающий сайт очень быстро, а пользователи любят быстрые сайты, которые их не раздражают. 2. Гугл выставляет таким сайтам высокие оценки и выше ранжирует их в SERP. (Справедливо полагая, что раз сайт делали крутые секси парни и сделали технически красиво - наверное и сайт в самом деле хорош, гораздо лучше соседнего, который школьник писал. В общем, поисковик уже по веб-технологиям, не заглядывая в бухгалтерию уже видит, где тут Кока-кола, а где Кукуевский завод безалкогольных напитков)
Ну и по функционалу, благодаря JavaScript эти статичные сайты пользуются всякими API, имеют свою логику, поэтому функционально такой сайт может все то же, что и прежние традиционные пэхапешные. Просто все что можно - отрендерено заранее и лишний раз юзер не ожидает ответа от бэкенда.
Если наш сайт, к примеру, продает авиабилеты, то главная страница будет статичной. Загрузится "моментально" с ближайшего сервера CDN. А вот запрос про билеты Москва-Владивосток на 1 Мая - будет выполняться через API. И сообщение "Сегодня через наш сайт уже продано N билетов" тоже появится по завершении запроса к API. А запрос к страничке "Контакты" - опять же статически быстро обслужится, вообще без вызовов API, так как это можно статически сделать, значит, так и надо.
Все это через статику, через всякие Hugo, Gatsby, Next.js и прочие e11ty, с использованием разных headless CMS и API.
А сайты по технологиям начала 2000 и бума CMS, при заходе на сайт PHP лезет в базу и спрашивает - а какой Title у нашей главной страницы? А в какой теме оформляем? А наша фирма по прежнему называется ООО Василек, как и последние 50 лет? И только после туевой хучи всех этих запросов формируется HTMLка и отправляется юзеру. В добавление к этому, традиционно у сайта есть полный доступ к базе (dbname, dbhost, dbuser, dbpass) поэтому уязвимость в коде плагина, который добавляет на сайт танцующих веселых поросяток приводит к тому, что всю базу могут поиметь.
Так что ленивые *опы сегодня - это те, кто в 2000 выучили php/mysql или что-то подобное, и леняться что-то новое учить. Делают так, как научились тогда-то. Ну или продают клиентам вебсайты на технологиях четвертьвековой давности. Четверть века, это как если бы в 2000 кто-то пытался делать проекты на технологиях 1975.
CityCat4, конечно! Но я уверен в двух вещах - 1) Как ты руки не мой, даже у хирурга во время операции на руках есть грязь, ну пусть пара бактерий, но остается. и 2) из первого не следует, что руки не надо мыть. Лучше иметь две бактерии на руках, чем 20 грамм бактерий. Лучше иметь средненькую анонимность, чем никакой.
Ну и правило Парето. Минимум усилий уже дают огромный эффект.
roswell, а откуда взялись те, кто предоставлял как раз то, что я ищу 25 лет назад? Откуда взялись те, кто предоставляют эту бесплатную услугу сегодня, с точно такими же высокими запросами к дисковому месту, просто делают это с SMS проверкой. Разве если человек верифицировал телефон - то в его ящике будет меньше писем что ли? :-)
Возможностей для монетизации бесплатной услуги - миллион, что мы и видим почти везде в интернете (который полон "бесплатными" сайтами, но при этом как-то зарабатывает. Мы сейчас с вами на одном таком сайте общаемся)
Да я знаю про эти сервисы SMSок и даже пользуюсь ими иногда но это для временных аккаунтов, именно для мусорных. Потому что через некоторое время этот номер окажется во владении кого-то и тут-то он и "восстановит доступ к почте через номер телефона". Зачем мне такая радость? Это прямо как почта как в 90/00-ые годы, но случайный человек на планете будет иметь возможность взломать твой ящик за 2 минуты. Что-то как-то не очень.
Почта в Узбекистане - вполне норм, если нажать на шамаскую кнопку "Я русскиййй!". Даже можно зарегистрироваться наполовину, но при попытке войти, просит номер телефона, куда вышлет SMS. Так что, нет, и в Узбекистане все не так, все не так как надо! :-)
Это немного другое.
На disposable нельзя ничего долговременного регать. Например, акк на хабре вряд ли стоит регать на mailinator.
Я же хочу почту, которая будет именно моя (как раньше на @mail.ru и везде), которую можно читать только с паролем, и никто другой не прочитает. Либо нужен вот такой вот сервис "почты из 90-ых", либо подошел бы (если вдруг есть) урезанный сервис, с которого нельзя отправлять почту.
Спасибо. Из Figma что выходит - уже HTML/CSS (для п.3) или просто картинки согласования и чтобы потом (в текстовом редакторе) повторить что-то похожее?
Владимир, вроде я это и написал. "Этого кода нет на клиентской части". Скажем (чуть наивный пример) - в целом бухгалтерия на PHP у клиента, а вот какой-то налог считается на сервере.
Можно выкусить это, написать локальную функцию расчета, но даже небольшой код для чужого проекта писать уже страшновато и сложновато. А что именно делать на сервере (в идеале, что-то, что локально реализовать было бы сложно) - это уже надо по каждому проекту отдельно решать. В общем, нужно увязать готовую программу с внешним сервисом.
А что значит "поиск начал тормозить", какие цифры? Просто у меня есть проект на python (то есть, относительно "медленный") и я тестировал на базе из 1 млн записей (все в памяти, с диска не подргружается ничего), при этом фильтрация идет по пайтоновскому выражению в запросе (скорее ближе к SELECT ... WHERE в SQL, а не быстрый-эффективный поиск по дереву, как в редисе на С).
Так вот, при всех этих замедляющих факторах, поиск всех продуктов, где "price<20" из миллиона:
четверть секунды. Это слишком много? И это на пайтоне и это фильтрация каждого из миллиона (а не поиск по ключу). Если у вас поиск по ключу, да еще и redis'ом больше занимает - что-то где-то как-то криво.
И еще вопрос - а как часто обновляются данные у вас? Потому что есть еще такая веселая идея (если обновления редки) - сделать все на статике (например, hugo) и раздавать HTMLки (или JSONки) просто как файлы с диска. Nginx найдет выплюнет статический файл с диска просто моментально. Но это уместно только если обновления редки.
CityCat4, так это LTSная версия, должна поддерживаться. Ну и для других версий, посвежее, тоже нету. Как-то это странненько... будто забили на уязвимость.
Everything_is_bad, не знаю. Пока что я вообще не уверен в ситуации - мне не верится, что большая дырка для которой есть патч может сверкать уже целый квартал. Думаю, что может быть это я что-то упускаю, путаю...
Adamos, ээммм... а сейчас ведь через GPT их легко генерировать! Только я что-то не нашел в интерфейсе ChatGPT где сид указывать - может быть это было в другой нейросети, но где-то можно. Если нейросеть по сиду сможет однозначно генерировать хокку - этот хокку-код тоже будет иногда удобен для использования! :-)
