под корень выделить 20-50 гб. на серверное програмное наполнение хватит за глаза. у меня на домашнем компе с граф.интерфейсом и кучей всякой хомячковой фигни, под корень выделено 24 гб и то на половину заполнено.
все остальное одним разделом смонтировать в /mnt/%какоенить_имя% и использовать под самбу, бекапы и тому подобное.
если бекапы отделены от хранилища, то разделить оставшееся место на два раздела (размер сам уж думай) смонтировать по отдельности и по отдельности использовать.
ну к примеру, изза материалов, технологий, размещения блоков, каких-то качеств схемотехники и т.д. модель получает дополнительный запас прочности и может работать более высоких частотах. а это весьма круто купить недорогой проц, разогнать его и получить производительность более дорого. это для хомячков
или получить повышенную стабильность работы это для серверов, рабочих станций.
и модель становится удачной и рекомендуемой многими гуру к покупке.
нет такого понятия универсальный процессор, точне он есть но будет слишком дорог, чем набор заточенные под разные целевые характеристики процы.
есть геймеры которым только и подавай бешенные попугаи в тестах и фпс в играх,
есть прикладники/серверы которым нужно стабильность работы проца в течении долгого времени нон-стоп.
есть ноутбуки где ватты и теплорассеивание играют сильную роль.
и т.д.
даже для трех указанных целевых аудиторий нельзя сделать универсальный проц. а их и того больше...
умощнее вширь, а не в гигагерцы, к примеру делают изза применения больших скоростных кешей, различных методик максимального выжимания эффективность из набора алгоритмических блоков. многостадийные обработки инструкций привели к нескольким потокам команд (виртуальных процов) на один железный процессор (в ч86 их два, в power емнип 4 потока на ядро и т.д.)
для устройства в компанию по производству процов требуется огромное количество прикладных знаний, не связанных с твоими слишком обывательскими запросами :)
знание физики, схемотехники, языков описание аппаратуры, технологий и т.д. для этих прикладных наук есть немалое количество книжек. и обучают в соотвествующих универах
underratedaf, да он в принципе правильно написал.
нет таких книжек чтобы расписывать маркетинговые заморочки процов.
так что гуглишь все непончтные маркетинговые слова найденые в обзорах т роликах тем самым набиваешь свой череп искомыми знаниями.
Артём Брыкин, ну дык смотри логи что сбис не нашел в среде твоей системы.
запусти убунту в виртуалке. или поставь второй системой.
в чем смысл твоего рор ??
поддергай тех.поддержку накрайняк.
балансировка в указанной платке достаточно слабая и только при заряде. но вполне хватает на балансировку идентичных по характеристикам элементов. что и происходит в 90% случаев сборки батарей из литиевых банок.
подключать разные банки с разной степенью убитости к такой схеме не эффективно.
"истинных" балансирующих схем, к примеру, на переключающихся конденсаторах никто не производит, ибо дороже.
если у тебя свежие банки идентичной серии то ставь такую платку и не парься.
для такого давно уже используется seedbox. личная vpsка с установленным торрент-клиентом и доступом по веб-интерфейсу ftps или resilio sync или еще чего.
c западными ограничениями это уже большой рынок.
купить сидбокс где-нить в азии где пофиг на авторские заморочки и качать торренты через него.
гугли seedbox
poisons, список личей это как надпись на стене сарая "вася-убийца". это не доказательство.
А трафик неизвестного содержания это вообще ни о чем, большинство трафика сейчас шифровано.
провайдерский DPI не имеет таких технических возможностей чтобы вскрывать даже слабо шифрованные каналы.
OCCASS OCCASSOVICH, архиватор - программа, сжимающая указанные данные.
бинарь - бинарный исполняемый файл выполняющий указанные функции.
удивил :) под виндовс она и не создавалсь. как тебе уже сказали либо wsl либо виртуалбокс с линухой.
jambbadbalance, что-то сломалось и теперича работает в нештатном режиме.
есть два варианта
вариант1: взять осциллограф и проверить работу схему, разобраться в проблемах, разобраться в схеме и починить их.
вариант2: прикрутить костыль, который с большой вероятностью исправит последствия ошибки.
вариат1 вам я так понял не светит
так что идем по второму варианту, что я и предложил, достаточно дешево и просто в исполнении.
и если он не поможет - отдаем тому кто сможет сделать ремонт по первому варианту.
Venot, да погорячился. был уверен что в systemd.path есть зависимости от размеров... но это долго.
тогда такой вариант:
systemd.path с мониторингом закрытия открытых на запись файлов PathChanged=
в ExecCondition= засунуть проверку на размер каталога
а в Exec= удаление самых старых файлов.
ну и допилить по месту.
теоретически должно работать, но слишком часто дрочить диск будет :(...
лучше наверное через timer или крон раз в полчаса запускать проверку размера каталога и если он больше нужного то запускать обрезку старых файлов.
rodfver, теория без практики выветривается быстро :) бросай читать книжки и делай чтонибудь. теория тут уже будет следовать за практикой. возникающие проблемы будешь гуглить и вычитывать методы решения.
noob777, какая разница чем писать ?? байтики из образа надо скопировать на носитель, мудрствований тут нет.
что винда что убунта это сделает эквипенисуально.
их дохрена такто наделали.