Griboks, нет, господин хороший, я многим рекомендую линукс. Но тут ситуация другая. Вместо нормального линукса человек взял самосборный дистрибутив.
Это примерно тоже самое, что дистрибутивная сборка виндовс с обрезанным функционалом, заблокированными службами и выкинутой локализацией. Работай - не хочу. Часто там даже сервисов печати нет и доступа к виндовым шарам.
Viktor T2, а вот этого не нужно делать! Тогда звука вообще не будет., или будет только в конкретном приложении, ибо alsa не умеет в многопоточность и не умент шарить карточки.
Или нужно ставить pulseaudio или jackd.
И pipewire не низкоуровневый, а альтернатива puleaudio. Причем совместим и по плагинам и по утилитам.
И hdajackretask работает тллько с jackd, не путайте!
Вот вопрос, риторический... Я поставил kali linux, но нифига в линуксах не понимаю, зачем я это сделал?
Мне бы обычную машинку, седан там, или хеч, а не багги для песочного пляжа, для езды по городу...
Поставьте что нибудь более юзерфриндли. Ubuntu там, Fedora, да даже AltLinux...
А когда понадобится Kali (мне он ни разу не понадобился за 30 лет работы в юниксах) тогда уж и понятно будет.
Akina, Не совсем так, проверка вверх-вниз достаточно 72 милисекунд по стандарту для 100 base-t и 288 ms для 1000 base-t ... Так что на херовых кабелях или проблемах на той стороне просто может могргать, если связались на 100 и пытаемся ускакать на 1000.
Кстати, а на другой стороне что стоит?!
Epic18, Ну и чего же тогда об лампочках беспокоиться? Сначала нужно проверить, все ли хорошо с перформансом, а уж потом и в набаты (рынду) стучать :)))
rad_li, dnsmasq ставьте и настройте локальную зону.
Но обычно это делается на dhcp сервере, который скорее всего у вас роутер домашний, который раздает ip-адреса. Как минимум на нем нужно прописать ваш новый dns- сервер.
Jack444, Во первых, во всех скриптах прописывать не нужно (библиотеки и принцип SOLID), просто скидывайте куда нибудь в кафку или в nosql, подключайте воркеров сколько не жалко, или сразу пишите куда нибудь в TSDB.
1) Все равно это статистика,все равно не нужно до сотых граммов
2) Если и нужна точность, то у меня будет другая система, не зависящая и не трогующая данных биллинга, а тем более лицевых счетов.
3)Не будет никаких задержек и непонятных внутренних эффектов типа блокировок, откатов транзакций ( мне же из всех этих "статистических таблиц откатить надо")...
4) Не будет никаких эффектов с восстановлением из бекапов или шардированием базы
5) Если не хватает вычислительных ресурсов, их всегда легко добавить, база при этом будет гораздо спокойнее.
6) Отладка будет шелковистее, а то засандалил проводку, а база хрен знает что внутрях вертит...
В общем, да триггер повесить просто. Но это как кол себе вбить, вроде бы и кепочку держит, но головой не шевели.
Так что Ваш пример абсолютно неубедителен.
Ну и что касается OLTP - чем больше триггеров на базе, тем реакция системы непредсказуемее.
А считать статистику изменения цен можно и в памяти в потоке, изредка подгружая предыдущие значения. При этом это будет на порядок быстрее триггера: ибо не пишем, а читаем (а если и пишем, то только разницу или результат), нет лишних запросов (и транзакций), база не тормозит...
Да, еще такой вопрос - хорошо, если постгрес, а если покупная база?! С лицензией на per-CPU? Еее тригеерами нагрузить - себя в ад отправить, ибо лицензию за 10 минут не купить, а воркеры я даже на офисных компах могу назапускать.
