Илья, С чего это не поможет, если мыши абсолютно идентичны, то обычно раздалбывается/стирается именно корпус, чуть реже, от хороших полетов, рушится пайка. Тогда донорство переставляйка какраз спасает. На прошлой работе так кучу мышей пересаживали, если у одних выломано колесико, а у других сенсор почил.
lifecom, Для SATA они не нужны, чипы - обычные МК отвечающие за "серверные" sas фичи, типо той же индикации, которая отдается на них по i2c, контроля питания, определения какой диск в каком гнезде сидит и тп. разъемчик какраз для диагностики/прошивки чипа, в работе не используется
Нормального сетевика там надо на место пригласить.
Уход в /23 маску на китетиках с wi-fi и симкартами - та еще идея.
Чую следующим вопросом будет "сеть слегла неизвестно от чего"
Хотя если там IoT то может относительной производительности и условно хватит
IDE и FDD никогда не были последовательными интерфейсами, просто были шлейфы на один и два канала.
У Sata помню были хабы позволявшие подключить 5 дисков к одному порту, но звездой а не шиной.
Дмитрий, я бы, данные случаи отнес к 10 метровым кабелям между пк и тв которые подключены к разным фазам питания. Вот там да разностью потенциалов и статикой может отшарашить порт, а на рядомстоящих ниразу порты на горячую не вылетали
Не знаю точно как обстоят дела с программами, но в технике, в частности фотоаппаратах, ограничение времени записи видео было связано с лицензированием кодеков. Типо >30мин - это уже хорошие $$$, поэтому производители ставили ограничение в 29мин на ролик
nedophilosoph, При том что настройки IE распространяются на всю винду как дефолтные. И скайп со времен поглощения мелкомягкими использует давально много зависимостей IE. И помню, раньше, на закате популярности скайпа, сброс настроек IE помогал от многих глюков.
Точнее: вынуть батарею - положить на полочку - подождать полгодика до критического саморазряда - выкинуть батарею.
Программный режим "хранения батареи", да, при рациональном использовании, может продлить службу. Но вынимание - однозначно нет.
Zerg89, Оборудование ядра в любом случае по количеству пользователей не выбирается, тем более в таких сетях. По количеству пользователей (точек подключения) можно выбирать только свичи доступа. Маршрутизаторы же, только, на месте после примерки в схему и расчета нагрузки. Потому как: тупо дать nat и наваять фильтрацию/маршрутизацию по спискам и прочему это очень разные вещи. А также будет ли весь трафик филиала (включая инэт, smb, rdp, rtsp и т.д.) уходить в VPN или туда будут идти только несколько SQL/HTTP баз, а все каналоемкое будет гулять внутри своих подсетей.
igivanov1111, тут вопрос не в количестве хостов, а в правилах работы.
от 500 хостов уже считается крупная сеть и там нужно пилить всякие маршрутизации, ограничения доступов, фильтрации и тп, а также это все не единожды резервировать.
Дык вот пихать это все на одну железку, пускай и в 16 ядер - крайне не хороший тон. В таких сетях ядро должно состоять из 10ка маршрутизаторов разделенных по функционалу. Одни занимаются непосредственно разделением и фильтрацией внутренних сетей, другие разбрасывают dmz по сервакам, третьи переваривают vpn, четвертые непосредственно защищают wan. И это все пару раз надо зарезервировать чтоб не полетело
А также требование AD со всеми ее плюшками и лицензиями и прочим прочим прочим прочим
В общем ЭКСЧ - это если в организации минимум 5 000 работников с почтой и уже есть устоявшаяся и активно использующаяся структура на AD.
А на 60 чел (или всетаки ящиков?) можно даже готовых бесплатных линуксовых сборок понаходить.
2k21, Я бы на уже 70+ хостах на уровне маршрутизации не ограничивался железкой "все в одном", а как минимум брал пару в active/standby и/или один на фильтрацию/маршрутизацию, второй на шифрование/доступ. Тогда можно будет рядом ставить высокопроизводительные шифраторы с не скоростными портами.
