Dmitriy_2014 : Стоит ли поработать над тегами/метками, так чтобы поубирать лишние где отображается только одна статья, а оставить лишь те где хотя бы две статьи будут
Поработать стоит, но не так, как вы написали. Теги группируют статьи в пересекающиеся группы по какому-то общему признаку. Соответственно, вам нужно добавлять одинаковые теги к разным статьям, чтобы количество статей в теговых группах увеличивалось. Тег (как группу/категорию) можно и удалить, если он малополезный (неправильно выбран).
Как выше написали, у мобильных операторов и некоторых проводных провайдеров все плохо. А вот из хорошего дата-центра достучаться до зарубежных серверов можно обычно.
Например стек, удобный вроде бы подход к записи динамических данных, вызовов процедур и возврат обратно, но он может затереть данные или код программы при плоской памяти
Обычно на дне прикладного стека (каждого прикладного потока) присутствует т.н. "стоп-фрэйм". Нужно сильно постараться, чтобы его "перепрыгнуть". У стеков ядра строение может быть таким же или еще сложнее.
Секция кода (после релокации) обычно защищена от записи на уровне страниц.
Кстати, в IA-32 даже для линейного (виртуального) адресного пространства была возможность защищать пространство вне стека на уровне сегментации: code/data(bss)-сегменты "растут" снизу или покрывают все прикладное пространство, а стековый "растет" сверху прикладного пространства (user space). Подобный стековый сегмент мог быть у каждого прикладного потока или охватывать все стековое пространство процесса. У ядра, в разработке которого я участвовал, была такая опция.
Как выше написали, вам не помешает научиться лучше объяснять. Возможно, после этого вас будут лучше понимать. А просто опускать собеседника вместо объяснения любой д. может.
Владимир Коток#: Lets Encript для локального сервера невозможен.
Легко возможен. Даже если нет доступа к серверу извне. И даже для метода валидации HTTP-01. Просто выпускаете для публичного домена, а используете с одноименным частным.
Александр Воробьев#: В общем случае да, но тут речь об очень конкретном случае. И только.
Я об этом и писал. Если у вас в шаблоне маршрута не описана строка запроса (хотя маршрутизатор позволяет), то соответственно запросы по адресам с вопросительным знаком на конце будут приводить к вызову обработчика ошибки, который выдает 404 и т.п. Например, посмотрите сайт у меня в подписи. Там используется каркас, не порождающий дубли. На уровень Web-сервера вынесена только обработка трэйлинг-слэшей. Все остальное внутри каркаса, в частности завершающий вопросительный знак будет "отброшен" при помощи общего шаблона адреса. Его окончание:
(\\?p=[1-9]\\d{0,9})?$#
Т.е. либо строка запроса по формату, либо никакой, включая разделитель вопросительный знак.
Александр Воробьев#: Изначально вопрос был именно о более конкретном случае: когда после "?" вообще ни чего нет. И тут суть в том, что это общее правило, на мой взгляд, для подавляющего большинства сайтов.
Да, адреса с вопросительным знаком на конце используются редко для какой-то другой функциональности, чем 404/301.
Александр Воробьев#: По этому я и размышлял единожды засунуть редирект в настройки nginx
Если у вас шаблоны адресов в маршрутах описывают в том числе и строку запроса (query string) или ее отсутствие, то специально что-то общее можно не писать. Общая проверка на ранних этапах обработки запроса может быть даже хуже, чем частные или более комплексные общие на поздних. Даже несмотря на то, что в последнем случае нужно еще передавать управление php, etc.
Это норм? )))
Стоит ли поработать над тегами/метками, так чтобы поубирать лишние где отображается только одна статья, а оставить лишь те где хотя бы две статьи будут
А при чем тут сервер?
Не знаю 😊
С серверов в РФ спокойно подключаюсь к зарубежным серверам. Напрямую с клиентских устройств - нет.
Проложите маршрут через какой-нибудь сервер в РФ.
Как выше написали, у мобильных операторов и некоторых проводных провайдеров все плохо. А вот из хорошего дата-центра достучаться до зарубежных серверов можно обычно.
Обычно на дне прикладного стека (каждого прикладного потока) присутствует т.н. "стоп-фрэйм". Нужно сильно постараться, чтобы его "перепрыгнуть". У стеков ядра строение может быть таким же или еще сложнее.
Секция кода (после релокации) обычно защищена от записи на уровне страниц.
Кстати, в IA-32 даже для линейного (виртуального) адресного пространства была возможность защищать пространство вне стека на уровне сегментации: code/data(bss)-сегменты "растут" снизу или покрывают все прикладное пространство, а стековый "растет" сверху прикладного пространства (user space). Подобный стековый сегмент мог быть у каждого прикладного потока или охватывать все стековое пространство процесса. У ядра, в разработке которого я участвовал, была такая опция.
ЗЫ. Да кому я это объясняю.
Как выше написали, вам не помешает научиться лучше объяснять. Возможно, после этого вас будут лучше понимать. А просто опускать собеседника вместо объяснения любой д. может.
Может ли он зависнуть напрочь как в MS-DOS или Linux полностью защищен от таких эффектов?
Приложение может вызвать что-нибудь уровня ядра, что может подвесить систему.
Также иногда в механизмах аппаратно-программной защиты находят ошибки, которые позволяют прикладному коду переключиться в режим ядра.
упрощенку отменят
Вроде бы оставят для тех, у кого выходит не больше 20 млн/год.
В.В. выразил надежду, что 22% НДС - это временно. Правда, я не понял, потом будет еще больше или все-таки обратно откатят 😊
Lets Encript для локального сервера невозможен.
В общем случае да, но тут речь об очень конкретном случае. И только.
Я об этом и писал. Если у вас в шаблоне маршрута не описана строка запроса (хотя маршрутизатор позволяет), то соответственно запросы по адресам с вопросительным знаком на конце будут приводить к вызову обработчика ошибки, который выдает 404 и т.п. Например, посмотрите сайт у меня в подписи. Там используется каркас, не порождающий дубли. На уровень Web-сервера вынесена только обработка трэйлинг-слэшей. Все остальное внутри каркаса, в частности завершающий вопросительный знак будет "отброшен" при помощи общего шаблона адреса. Его окончание:
Т.е. либо строка запроса по формату, либо никакой, включая разделитель вопросительный знак.
Изначально вопрос был именно о более конкретном случае: когда после "?" вообще ни чего нет. И тут суть в том, что это общее правило, на мой взгляд, для подавляющего большинства сайтов.
Да, адреса с вопросительным знаком на конце используются редко для какой-то другой функциональности, чем 404/301.
По этому я и размышлял единожды засунуть редирект в настройки nginx
Если у вас шаблоны адресов в маршрутах описывают в том числе и строку запроса (query string) или ее отсутствие, то специально что-то общее можно не писать. Общая проверка на ранних этапах обработки запроса может быть даже хуже, чем частные или более комплексные общие на поздних. Даже несмотря на то, что в последнем случае нужно еще передавать управление php, etc.