Сергей Кузнецов

mike153: пробовал все варианты. Nextcloud - это форк Owncloud. По сути, одно и то же, хоть и NC считается более продвинутым и вообще вся опенсорсная тусовка туда ушла. Поэтому пишу о нём. Всё исключительно на правах IMHO. Плюсы:
- Самый главный - это работа с файлами именно в файловом варианте. То есть, если предположить, что "всё упало", вы можете подключить диск с рухнувшего сервера к любому линуксу и вытащить инфу из /var/www или где она там у вас храниться будет. Также можно подключать внешние хранилища, то есть, предположим, есть у вас на сервере папка с фильмами и музыкой - их можно просто подключить в NC.
- CardDAV, CalDAV из коробки.
Минусы:
- Тормозит всегда, рандомно, в любой момент времени. Независимо от того Apache или Nginx, MySQL или MariaDB, тормозит на любом софте.
- Интерфейс - УГ, ШГ

Теперь о Seafile. Плюсы:
- Турбореактивный просто. Работает очень быстро.
- Интерфейс очень приятный.
- Продвинутое версионирование.
- Умеет открывать docx, odt, xlsx и т.д. без дополнительного софта. Но без редактирования. Если нужно редактирование - нужен отдельный Document Server от Collabora или Onlyoffice.
- PRO-версия бесплатна для 3-х пользователей, но смысла особого нет, т.к. enterprise-фишки заключаются в 1. полнотекстовому поиску по документам с помощью elasticsearch, у которого просто чудовищное потребление ресурсов 2. двух-факторной авторизации 3. и что-то там ещё, не особо нужное дома
- Есть клиенты для всех основных платформ
- Устанавливать можно как вручную по мануалу на сайте, так и воспользовавшись установочным скриптом, который сам всё сделает.
Минусы:
- Файлы хранятся в собственном формате, как это правильно называется? - на уровне блоков, что ли. Доступ к инфе только через веб-интерфейс, WebDAV, ну и приложения для синхронизации. То есть, вся информация в Seafile на диске представляет просто кучу мала из папок и файлов, которые нельзя так просто взять и использовать - нужен ещё дамп базы данных. То есть, в случае проблем с системой, достать информацию будет затруднительно. Но выход есть - seaf-cli - это безгуёвый клиент для синхронизации. Смысл в том, что на сервере, на котором крутится Seafile, дополнительно можно установить seaf-cli, натравить его на директорию, и он в эту самую директорию будет складывать синхронизированную копию инфы основной базы Seafile, причём в виде нормальных файлов, которые можно расшаривать как угодно, бэкапить и т.д. Минус решения с seaf-cli в том, что нужно вдвое больше дискового пространства для хранения инфы.
- Ну и как следствие такой организации файлов - невозможность подключить внешние хранилища, в отличие от тёплого лампового Nextcloud.

В общем, лично я остановился на Seafile.

На практике редко ошибки правятся "выдиранием" одного коммита из истории, но такая операция вполне себе возможна.
Вариант номер один - интерактивный ребейз, и в нем указываешь какие коммиты дропнуть. Если коммитов много, то можно задолбаться решать конфликты
Вариант номер два - просто делаешь новый коммит с реверсом изменений из коммита, который привел к проблемам
Вариант третий - делаешь новый бранч, откатываешся до проблемного коммита, потом из полного бранча накатываешь остальные изменения.

Все сценарии приблизительные, потому что каждая проблема требует комплексоного подхода и знания возможностей инструмента, поэтому не поленись, а почитай вот это внимательно и полностью
https://git-scm.com/book/en/v2

on_reaction_add вызывается только тогд , когда сообщение было отправлено при запущенном боте (грубо)
https://discordpy.readthedocs.io/en/async/api.html...

Лучше использовать on_raw_reaction_add
https://discordpy.readthedocs.io/en/latest/api.htm...
В случае с on_raw_reaction_add(payload) id канала лежит в payload.channel_id

Ну и подобное условие вряд ли сработает, пытаетесь сравнить объект класса Channel с числом. Если сравниваете id - то сравнивайте ID, не нужно получить канал в таком случае

Судя по скриншоту в комментариях к вопросу, у вас файл в кодировке UTF-8.

В Apache

Первый способ: в файле httpd.conf самого апача, либо в файле .htaccess, который находится в той же папке, что и HTML-файл (если его там нет, то создайте) можно прописать такую директиву:

AddDefaultCharset utf-8

Или так (если кодировку нужно устанавливать только для HTML-файлов):

AddCharset utf-8 .html

В HTML

Второй способ: в самом HTML-файле в блоке <head> можно добавить тег, который скажет браузеру, что это UTF-8.

<meta charset="UTF-8"/>

https://support.atlassian.com/bitbucket-cloud/docs...
https://www.udemy.com/course/mastering-bitbucket-p...

^(?!0+$)\d+$

https://github.com/farag2/Sophia-Script-for-Windows

А Вы читать ошибку пробовали? Там же все расписано...
Нужно сделать git pull перед git push, чтобы получить изменения, которых у Вас нет локально.

Но не обнаружился ни одного релиза, который был бы доступен

Плохо искал. В статье чётко сказано название, и по нему легко можно найти репозиторий на гитхабе:
https://github.com/intel/acat
Получается, Интел выполнил своё обещание, и как раз в 2015 году.
мои дальнейшие рассуждения на актуальны.
Оставил только чтобы опровергнуть ваши заблуждения.

Почему не выложен релиз программы, тогда как в нем нуждаются множество людей

1. Она делалась специально под Хокинга и являлась частью всего комплекса средств вокруг него.
2. Возможно, в процессе разработки использовались какие-то компоненты, лицензия на которые не позволяет их распространять.
3. Интел просто не выделяет ресурсы на то чтобы провалидировать это и опубликовать.
Разработка такого софта не является профильной для интела, по тому, возможно, в разработке участвовали другие компании, и нужно получить от них разрешение на публикацию.
По тому это может занять какое-то время, но никто не хочет, тк есть работа по важнее.

Как мы знаем, программы постоянно совершенствуются

Но не все и не всегда.
Программы совершенствуются не сами по себе, а это делают люди.

Рассматриваете ли вы такой вариант, что Хокинг был лишь куклой и от его имени говорил кто то другой?

Теории заговора обсуждаются не тут.
Но лично я такой вариант не рассматриваю.

тогда как в нем нуждаются множество людей

Интел тут ничего нового не разработал, и есть несколько других компаний, которые делают что-то аналогичное. Даже в РФ.
Но название не вспомню

Я больше подозреваю, что путь кривой. пробелы, точки, русские буквы.
Может пушили с Линукс, а с винды такой путь не смог склонироваться.

Кстати, на Stackoverflow обсуждают слишком длинные имена.
Тоже можно проверить. русские буквы - в utf8 занимают больше байт, чем английские.
можно попробовать
git config --system core.longpaths true or edit gitconfig (от админа)
или попробовать склонить в папку ближе к корню диска.

git checkout -f

Сделать бэкап сайта и поместить его так, чтобы до него было не добраться (до бэкапа).
Просканировать на уязвимости - в тырнете полно сканеров сайтов на WP
Почаще просматривать логи на предмет подозрительной активности

Строки в java сравниваются методом .equals()