Pudjak, если задача в том, чтобы в файле ничего не появилось, то надо проверять, что стандартный вывод является терминалом, см. первый попавшийся пример. Если же задача в том, чтобы файл не перезаписался при таком перенаправлении, то это НЕВОЗМОЖНО. Даже если программа ничего не выведет, файл всё равно будет создан/перезаписан как файл нулевого размера. Причём открыт на перезапись ещё до запуска самой программы.
mayton2019
Не совсем, если написать так, как написано, stdout попадёт в файл, а stderr - в stdout. Перенаправление 2>&1 следует поставить последним, чтобы в итоге оба потока попали в файл.
RSS вообще никогда не задумывался как поставщик контента за секунды. Для такого на своём сервисе лучше поискать другие механизмы (например, использовать вебсокеты), а насиловать чужой сервис без спросу вообще неприлично.
Когда из интернета фильм качался несколько суток (если ещё и не падал каждые три дня, что было довольно обычным делом), а из локалки 20 минут, это имело смысл. Когда фильм из локалки качается 20 минут, а из интернета пусть даже час, смысла в локалке становится мало, потому что в интернете гораздо больше контента. А сейчас интернеты даже превосходят былые локалки по скорости.
И, конечно, развитие глобальных сервисов. Все эти ютубы, соцсети и прочие стимы. Зачем сейчас вообще тусить в мелком районном чатике со школотой, если вконтактик предлагает всю страну, всех друзей и родственников и много новых знакомств по интересам? Зачем качать видео, если его можно посмотреть онлайн сразу же? И всё такое в том же духе.
Поздравляю с переизобретением торрент-трекеров! Они нонче часто делают всего лишь магнет-ссылки с хешами, но это всё равно не позволяет им избежать претензий.
Ну а по делу: если сайт будет мелким и никому не известным, то можно ещё трястись за домен, чтобы не растерять абонентскую базу. Если же сайт станет очень популярным, то пользователи сами завалят поисковики запросами о том, какой у него актуальный домен, как это происходит с nnmclub, бухтой и сайхабом...
Базы данных по хешам некоторых типов встречались, например https://web.archive.org/web/20150326101125/http://... , а также встречаются узкоспециализированные сайты типа anidb.net, где хеши файлов также имеются (видны только после регистрации, в основном собираются пользователями с помощью специальной утилиты avdump). Универсальные сайты, судя по всему, оказались не очень живучи. Вероятно, потому что в них стреляют со всех сторон правоприхлебатели всех мастей. Также и потому, что общее число разных файлов исчисляется астрономическими суммами, а атаковать базу хешей проще простого - достаточно генерить тысячами случайный мусор.
Если на сайте кроме хешей будут ссылки на скачивание, то сайт станет ещё более уязвим к юридическим атакам. В таком случае лучше сразу идти в onion/i2p, а в большом интернете сделать только лендинг с описанием.
Ну и надо понимать, что на взлетание проекта уйдут годы, даже если он взлетит хоть как-то. Можно попытаться договориться с какими-нибудь крупными базами контента, чтобы ускорить этот процесс, но шансы малы, что кто-то будет делиться своими данными.
PS: в целом, чем абузоустойчивее хостинг, тем он дороже, ну и качество их часто хромает, сами они живут очень непредсказуемо и могут как исчезнуть в туман с деньгами клиента, так и оказаться закрытыми по причине ареста владельцев (такие случае тоже были).
У WP есть одно большое достоинство - его огромная популярность. Поэтому по нему просто море разных рецептов, плагинов и патчей. Малоизвестная альтернатива может показаться на первый взгляд более простой, но быстро окажется, что чего-то маленького не хватает: то слайдшоу из галереи некрасиво выглядит, то облако тэгов вообще не предусмотрено, то календарь показывает недели с воскресенья... И тут уже часто не получится просто доставить плагин или внести небольшую правку в шаблон, может понадобиться дописывать полноценный функционал самому. Это явно не то что мы хотим от простого движка?
До кучи, считать WP недостаточно простым как-то странно. Это как считать, что у макинтошевских мышек слишком много кнопок :)
А зря. Это так не работает. Частота вертикальной синхронизации - это неотъемлемое свойство видеорежима (наряду с разрешением), список которых для каждого монитора ограничен его техническими характеристиками.
Зачем использовать много ключей? Генерим один ключ и со всех клиентских хостов ходим с его помощью на сервера, на серверах, соответственно, один ключ в authorized_keys.
Управление можно реализовать кучей разных способов.
Например, если в боте совсем немного настроек, то можно сделать конфиг-файл и перезапускать бота. Или пусть он сам регулярно перечитывает конфиг.
Можно реализовать командами в самом боте. В том числе сделать так, чтобы управляющие команды работали только у пользователей из выделенного списка администраторов.
Можно сделать так, чтобы данные бота хранились исключительно в базе, и настраивать его через прямое редактирование базы. Или написать отдельное приложение для редактирования базы. Можно web, можно cli, можно gui...
Можно сделать web-интерфейс в самом боте. Особенно если он и так на вебхуках, то есть веб-сервер у него будет в комплекте изначально.
Можно сделать вообще API-интерфейс в боте. И к нему клиента. Можно web/cli/gui, а можно даже мобильное приложение.
В общем, море вариантов, и никто, кроме тебя, не может принять решение, исходя из сложности самого бота, требованиям к разработке управленческого интерфейса, собственных компетенций, наличия времени, в конце концов (супер-идея потребует супер-затрат).
SHA_bash, в описании матрицы n - это размерная константа, а не итератор. То есть матрица 10x10 будет всегда матрицей 10x10, а не матрицей [любое число от 1 до 10]x[любое число от 1 до 10].
Как пошутили в камментах, i и j :) Собственно, в математике часто итерируют по этим переменным, и программисты это часто повторяют:
for (i = 0; i < n; i++)
for (j = 0; j < n; j++)
do_something_awesome(i, j);
mk11, я привёл наивный алгоритм. Возможно, уже придуманы алгоритмы, которые позволяют оптимизировать процесс. Плюс во многих есть режимы от лёгкого до сложного, скорее всего, это определяется количеством чисел, которые удаляются при подготовке.
В одной реализации судоку я заметил, что там часто бывает тройка одних и тех же чисел в одной строке, только в вертикальном столбце квадратов 3x3 эта строка имеет разный порядок. Но так было не всегда, но даже в иных случаях часто это выражалось в том, что одно из чисел тройки просто перекочёвывало в другую строчку в каком-то из квадратов. Вероятно, это был побочный дефект использованного автором алгоритма, который в погоне за простотой и скоростью обеспечивает не совсем случайное распределение цифр.
mk11, нет, вполне очевидно, что просто оставить 17 произвольных чисел недостаточно. Например, если оставить 9 чисел в 1 строке и 8 во второй, то судоку будет иметь много решений, хоть в нём и будет 17 чисел.
Суть ограничения в 17 чисел состоит в том, что вообще никакое судоку с раскрытием меньшего количества чисел не будет иметь единственного решения.