smilingcheater

Такое ощущение, что код пропустили через какой-то markdown-редактор, который посчитал, что запись вида u.id это адрес сайта и автоматически заменил на соответствующий markdown-синтаксис ссылок. Такое может быть, например, при пересылке кода как обычного текста в мессенджерах.

Ну а малограмотный кодер вставил этот markdown-код не задумываясь.
Так что причина - копипаста без знания синтаксиса конкретного диалекта SQL.

SELECT [u.id](u.id)

а где вы такой синтаксис нашли? Совершенно очевидно непонимание от сервера, что вы этим пытаетесь сказать, я тоже не понимаю, что этот синтаксис должен значить.
https://dev.mysql.com/doc/refman/8.4/en/identifier...

Когда сбрасываю локально git reset --hard master то не могу запушить в репозиторий, только сделать pull

После такого надо форс пуш делать.

Удалить origin/develop и создать новый от origin/master

background-position

Вы некорректно поставили вопрос. Никакой репозиторий не может быть рабочим каталогом. Рабочий каталог репозитория и сам репозиторий это разные сущности и лежат в разных местах. Обычно репозиторий лежит в подкаталоге .git основного рабочего каталога проекта.

Вы наверное хотели спросить — может ли во внешнем общем репозитории тоже быть свой рабочий каталог?

Да, может, но с некоторыми ограничениями. Например нельзя пушить в ветку вышестоящего репозитория, если она в данный момент там активна и распакована в рабочий каталог. Если в общем репо HEAD стоит на ветке main, то вы легко сможете другие ветки отправить, но main не сможете и получите ошибку. И это логично.

Забирать коммиты вы сможете из любой ветки, даже из активной.

И у вас изначально ошибка вот тут:

Создаю на сервере репозиторий git init. Создаю у себя репозиторий

Для чего? Вы создали две отдельные истории. Даже если в обоих случаях получилась ветка с названием main, это всё равно будут разные ветки без общей истории. Не нужно так делать. Репозиторий следует создавать в одном месте, а затем уже клонировать в другие.

Очень многие наступают на эти же грабли, когда инициализируют репозиторий локально, а затем создают НЕ ПУСТОЙ репозиторий на гитхабе. Потом удивляются, почему не получается их связать. ))

Ни пуш ни пулл не работают.

Причина неработоспособности первого заключается в том, что ветка активна. Второй не функционирует из-за отсутствия коммитов в вышестоящем репозитории, поэтому нечего скачивать.

Поэтому общие репозитории проще делать без рабочего каталога, зачем он там?
Но теоретически можно работать децентрализованно. Допустим если вы все сидите в одном офисе, то можно некоторых коллег добавить как remote со ссылками в локальной сети и спокойно обмениваться коммитами в любую сторону. Почему бы и нет? Вы только не сможете пушить ветки, над которыми коллеги у себя в данный момент работают и не сможете сломать им код.

php -f /{path}/console.php

console.php не для того чтобы его напрямую запускать с php. А для регистрации консольных команд:
Artisan::command('inspire2'
которые потом вы запускаете командой
php artisan inspire2

Дальше уже смотрите в сторону Schedule

Коротко - потому что IEEE 754

Выполняет он математические операции правильно, но некоторые числа компьютер просто не способен представить со 100% точностью, тк для них нужно было бы бесконечное количество памяти.

Точно также, как мы не можем записать все цифры числа 1/3 в десятичной системе, точно также и компьютер иногда не может записать все цифры в двоичной.

Если ты работаешь с деньгами, то тогда используй то, что делают все банки - представляй суммы денег не как дробные числа, а как целые. Например место 1.5 рублей записывай как 150 копеек. Запятую добавишь при выводе человеку.
btw тут в комментах пишут, что для денег тоже есть паттерн по-лучше конкретно для php.

Если при делении у тебя получилось дробное количество копеек - округляй так, как велит закон.

Если ты делаешь какие-то математические вычисления - возможно тебе нужны рациональные числа.
Не знаю, что обычно для этого в пхп используют, но нагуглил https://github.com/webgriffe/rational
https://github.com/markrogoyski/math-php

Но в случае с целыми числами ты всё равно можешь упереться в ограничение на максимальное число, а в случае с рациональными числами ты получишь очень сильную просадку в производительности.

Если тебе критически важна скорость, а точность - не так важна, то оставайся на IEEE754 и просто округляй то N значимых цифр (обычно больше 5 цифр мало кому нужно)

Можно делать 2 запроса в эластик - базовая агрегация без фильтра (все возможные значения) и второй запрос с примененным фильтром.
1. Получили 2 набора свойств - полный набор и ограниченный по фильтру.
2. Отрисовали фильтр на фронте согласно полному набору свойств.
3. Для свойств, которые не выбраны в фильтре (и только для них) "задизейблили" те значения, для которых агрегация с фильтром выдала 0 штук.

Таким образом у вас и фильтр "не скачет" - т.е пользователь явно видит, что такое значение в принципе есть, но не подходит по фильтру. При этом можно выбрать в текущем выбранном свойстве другие значения.

В целом, подключение классов через include/require уже устарело. Как правило, используется автозагрузка классов по стандарту PSR4, самостоятельная (spl_autoload_register) или через composer.
Но если оставаться в легаси, то я бы вынес все подключения зависимостей через require_once в начало файлов.

Проблем с временными зонами вообще не будет, если их представление выдавить максимально ближе к модели представления данных на интерфейсе пользователя.
Нужно конвертировать в строку только непосредственно перед отрисовкой дату и время из UTC, и обратно загонять время в UTC, если забираете пользовательский ввод.
Весь бек должен работать в одной временной зоне, а от пользователя знать, что он в такой-то временной зоне, только в контексте сессионной переменной, если это необходимо.

А если подумать?
Что должен выдать document.querySelector('https://vk.com/krosrs')?
Правильно, ошибку. Что и выдаёт.

что делать?

Для начала определиться, а что именно вы хотите получить этим кодом и зачем делать ссылку, а потом запрещать переход по ней.

Обычно хлам складывают в /var. К примеру почистить /var/log от старых файлов

На будущее поставить ncdu
Запускать sudo ncdu -x /

/dev/sda1 это виртуальный файл, представляющий себя раздел на носителе, содержащий файловую структуру корня системы (прописано в Mounted on)

п.с. а Линукс необходимо изучать....

Первому файлу нужно сжать 402240 точек на кадр, 20 fps, получаем в секунду 8 млн точек. Видим сжатие 817 kb/sec
Второму файлу нужно сжать 921600 точек на кадр, 60 fps, получаем в секунду 55.3 млн точек. Видим 2526 kb/sec

Сравниваем 55.3 / 8 и 2526 / 817 = 6.9125 и 3.0917992656058751529987760097919

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

По поводу размера файлов, еще обращу внимание что 128 и 104 kb/s для звука - значимо влияет на размер файла. Звук вообще может занимать четверть а то и треть, ибо сжимается хуже, чем видео.

Ну собственно и все. Тут оба видео сжаты одним и тем же кодеком, и сложно предположить, что можно как-то заметно качественнее пережать, дефолтные настройки в современных кодеках обычно fits many, и какие-то кастомные настройки обычно влияют не столько на размер, сколько на адаптацию сжатия к контенту видео.

получить более высокий фпс из кадров которых не существует?? Ну не знаю, можно просто продублировать кадры. Можно в ffmpeg попросить создать промежуточные кадры, но оно может заметно исказить оригинал, и для художественного кино это может оказаться нежелательным эффектом.

В общем тут нет некачественного сжатия. Надо сравнивать контент (наличие статических частей экрана, количество цветовой гаммы и так далее).