Планы-то есть, конечно, но я посчитал лучшим решением всё-таки для отладки пойти по такому тернистому пути. Я думал над идеей просто повесить на виртуалку ios + купить акк разработчика, но там тоже много нюансов именно с регионом/оплатой и прочим, несмотря на то, что apple сейчас очень лояльна относительно смены региона из РФ для оплат. И это будет хорошим наставлением студентам/школьникам, которые пытаются идти в разработку мобильных приложений, и которые хотят без лишних затрат тестировать свои небольшие пет-проекты, поэтому я всё равно доволен результатом :)
Тут формулировка была упрощена. package-lock.json сам по себе не разрешает апдейты. Тут речь о том, что npm install может пересобрать lockfile, если в package.json стоят диапазоны версий, а потом npm ci поставит уже зафиксированную в lockfile версию. То есть npm ci не обходится мимо lockfile, а наоборот, воспроизводит его как есть. В статье я именно за это и топлю: lockfile должен быть фиксированным, а в production-сборках только npm ci, никогда npm
Xeon вполне жизнеспособный вариант, просто у него другой профиль компромиссов.
Плюсы: дешёвая ECC-память, много ядер за копейки на вторичке, надёжность корпоративного железа. Если брать что-то вроде E3-1225v6 или E-2134 в маленьком корпусе типа Fractal Node 304, то получается вполне компактно.
Минусы (по моему мнению для данного кейса): потребление в idle у серверных Xeon заметно выше, чем у N150 - там 20-40 ватт против моих 8, это уже другой счёт за электричество за год. Плюс iGPU у Xeon до определённого поколения слабее или вообще отсутствует на некоторых вариантах, а QuickSync для Jellyfin - это ключевое требование в моём стеке.
Но если у вас уже есть такое железо или вы нашли дёшево б/у, то это отличная основа. Особенно если планируете много контейнеров или виртуалок, там запас ядер реально пригодится.
По Vaultwarden согласен, логика с копиями на нескольких устройствах действительно снимает главный страх. Может пересмотрю своё решение держать пароли в облачном сервисе, особенно если бэкапы настроены нормально.
По почте интересно, что у вас нормально ходит даже с экзотическим TLD. Я, наверное, немного перестраховался в статье с формулировкой "никогда". Mailcow это не голый Postfix руками, там всё преднастроено включая DKIM/DMARC/SPF, и порог входа заметно ниже. PTR запись - это уже на стороне хостера решается. Учту это в дальнейшем, спасибо :)
Планы-то есть, конечно, но я посчитал лучшим решением всё-таки для отладки пойти по такому тернистому пути. Я думал над идеей просто повесить на виртуалку ios + купить акк разработчика, но там тоже много нюансов именно с регионом/оплатой и прочим, несмотря на то, что apple сейчас очень лояльна относительно смены региона из РФ для оплат. И это будет хорошим наставлением студентам/школьникам, которые пытаются идти в разработку мобильных приложений, и которые хотят без лишних затрат тестировать свои небольшие пет-проекты, поэтому я всё равно доволен результатом :)
Добрый вечер, проверьте пожалуйста обновлённый пакет v0.5.0
Добрый вечер, проверьте пожалуйста обновлённый пакет v0.5.0
Пришлите пожалуйста ссылку на репозиторий и проверьте обновлённый пакет v0.5.0
Пришлите пожалуйста ссылку на репозиторий и проверьте обновлённый пакет v0.5.0
Проект отделяет чисто AI-README от остального проекта. Если только README написан ИИ, то проект и выдаст "ИИ README, остальное - человек"
Пришлите пожалуйста ссылку на репозиторий и проверьте обновлённый пакет v0.5.0
Поздравляю с успехом! Рад, что всё получилось, пусть и не без помощи нейросети :)
Не думал об этом, спасибо
Спасибо :)
Спасибо, учту это
Спасибо, учту это при релизе v 0.4
Можете пожалуйста репо прислать? Я проанализирую. В ЛС или сюда, если не секрет
Спасибо, не нашёл информацию об этом при поиске, учту на будущее
Да, но я его исходно заблокировал, чтобы не делать ещё одну настройку, а сейчас вернул ограниченно
https://github.com/ShyDamn/3D-Kino
Тут формулировка была упрощена.
package-lock.jsonсам по себе не разрешает апдейты. Тут речь о том, чтоnpm installможет пересобрать lockfile, если вpackage.jsonстоят диапазоны версий, а потомnpm ciпоставит уже зафиксированную в lockfile версию. То естьnpm ciне обходится мимо lockfile, а наоборот, воспроизводит его как есть. В статье я именно за это и топлю: lockfile должен быть фиксированным, а в production-сборках толькоnpm ci, никогдаnpmXeon вполне жизнеспособный вариант, просто у него другой профиль компромиссов.
Плюсы: дешёвая ECC-память, много ядер за копейки на вторичке, надёжность корпоративного железа. Если брать что-то вроде E3-1225v6 или E-2134 в маленьком корпусе типа Fractal Node 304, то получается вполне компактно.
Минусы (по моему мнению для данного кейса): потребление в idle у серверных Xeon заметно выше, чем у N150 - там 20-40 ватт против моих 8, это уже другой счёт за электричество за год. Плюс iGPU у Xeon до определённого поколения слабее или вообще отсутствует на некоторых вариантах, а QuickSync для Jellyfin - это ключевое требование в моём стеке.
Но если у вас уже есть такое железо или вы нашли дёшево б/у, то это отличная основа. Особенно если планируете много контейнеров или виртуалок, там запас ядер реально пригодится.
По Vaultwarden согласен, логика с копиями на нескольких устройствах действительно снимает главный страх. Может пересмотрю своё решение держать пароли в облачном сервисе, особенно если бэкапы настроены нормально.
По почте интересно, что у вас нормально ходит даже с экзотическим TLD. Я, наверное, немного перестраховался в статье с формулировкой "никогда". Mailcow это не голый Postfix руками, там всё преднастроено включая DKIM/DMARC/SPF, и порог входа заметно ниже. PTR запись - это уже на стороне хостера решается. Учту это в дальнейшем, спасибо :)
Про Forgejo отличная идея, честно не подумал об этом, спасибо :)