Windows 10 - ядро: 10.0
Windows Server 2016 - ядро: 10.0
Отличия версии ядра 10.0.xxxxxx связано с тем, что у Windows 10 и Windows Server 2016 разный формат выхода обновлений. Для Windows 10 используется rolling-relise, где обновления функционала не изменяет номера версии, а только номер сборки. А на смену Server 2016 готовится Server 2019 (хотя разница больше для маркетологов). При таком подходе версии ядра Windows 10 должны в дальнейшем примерно совпадать и с ядрами windows Server 2019, но тут время покажет.
PS.
Отсюда только один вывод... ну ладно, два - ты соврал или хотел выпендриться, но не удалось, пришёл Ёж и плюхнулся на прекрасно укачивающий, как на волнах, водный матрас (или прыгнул в бассейн с шариками).
Ezhyg, Ага, только интересный факт:
Использовал на Win10 Hyper-V с поднятым Server 2016. (Кстати попробуйте на Win7 поднять Hyper-V как на Server 2008, отличия сразу закончатся)
IIS виртуального Windows Server и IIS поднятый на Win10 используют одни и те же настройки. При изменении их в Win10 они меняются и на сервере, и наоборот.
Так что не стоит утрировать одно ядро не означает одинаковые системы, а вот на Win10 можно сделать все, что может Server 2016, чего не скажешь о предыдущих редакциях
LightParticle, Не совсем так. Если говорить про https (раз речь зашла о браузере), то порядок действий примерно такой:
Открывая страницу сайта вы получаете сертификат данного сайта. В этом сертификате находится информация о названии сайта, открытом ключе для данного сайта и Центра сертификации, который этот сертификат выдал. Вся эта информация подписана цифровой подписью Центра Сертификации, совпадение с которой подтверждает, что сертификат предоставил именно его владелец.
Дальше проверяется центр сертификации, затем тот кто выдал сертификат ему и так далее, до момента пока цепочка не дойдет до центра сертификации, помеченном как "Корневой доверенный" т.е. тот которому Браузер доверяет, без поручения другого сертификата.
Затем, убедившись, что сертификат верен, с помощью открытого ключа в данном сертификате шифруется сессионный ключ - который используется для шифрования передаваемых данных. Сервер, получив ответ, расшифровывает его использую закрытый ключ от этого сертификата, который есть только у владельца сертификата. Таким образом у обеих сторон есть сессионный ключ шифрования, неизвестный никому кроме них. Дальнейшая передача информации шифруется данным ключом, весь срок его действия. После истечения генерируется новый ключ.
Теоретически вся цепочка может закончиться после проверки сертификата и работать без шифрования, но для корректной работы обе стороны должны использовать или не использовать шифрование.
АртемЪ, Вы пять смотрите только половину функций.
Сертификат (SSL или любой другой), в терминологии законов РФ Цифровая подпись может использоваться:
- Для проверки подписи владельца т.е. проверки что содержимое соответствует тому, что было вложено владельцем сертификата.
- Для шифрования данных т.е. сокрытия передаваемой информации от сторонних наблюдателей.
Чтобы не продолжать полемику отмечу сразу. Сертификат ничего не шифрует - он предоставляет ключ шифрования, протокол шифрования только определяет как это делать, а всю работу выполняет процессор или криптомодуль.
Не совсем так.
SSL - Secure Sockets Layer, транспортный протокол, использующий шифрование. Данные в протоколе HTTPS передаются поверх криптографических протоколов SSL или TLS.
При установлении HTTPS, FTPS или любого другого протокола с шифрованием в первую очередь происходит проверка сертификатов и установление защищенного канала. Именно этот момент проверки сертификата вы и описали, но после этого есть еще ряд этапов, которые происходят или нет, в зависимости от результата проверки.
Текст с вашей же ссылки. Для перекодирования видео на лету нужна не оперативная память, а мощный процессор или видеокарта. Каждый конкретный вариант нужно проверять реальным опытом (ищите форум владельцев, и спрашивайте) т.к. разные кодеки, при использовании разного софта требуют разную поддержку железа. Или тратте деньги, чтобы мощностей хватало "с головой". Никто не гарантирует, что завтра не выйдет в топ новый супер-мега-кодек, который ваша железка не потянет.
P.S MKV это не кодек, а контейнер. В нем может лежать как какой-нибудь распространенный AVI формат видео, так и редкий lost-less. Тогда в первом "матрешку" нужно просто развернуть и передать поток, то во втором его придется "переварить" до формата, воспринимаемого apple-tv. С первой задачей сейчас даже телефон справится.
Александр Новиков, нет все верно. Если вы хотите направить трафик ОТ какого-то конкретного ПК по определенному маршруту - то логичнее привязываться к IP-адресу источника пакета т.е. src-address.
Если ваша цель направить пакеты ДО определенного ПК, то следует привязываться к целевому адресу т.е. dst-address.
Иннокентий Иванов, Пакет chocolatey делится на 3 части:
Nuget-package - то с чего начинается работа по установке. Хранит информацию о пакете, версии, сборщике, зависимостях и прочему. Так же указывает на GIT-репозиторий, где хранятся скрипты установки данного пакета.
Install.ps1 - скрипт выполняемый при установке пакета ПО.
Собственно ПО - может храниться как вместе со скриптом в GIT-репозитории, так и скачиваться, по указанной в install.ps1 ссылке.
При выполнении команды choco install 7zip (для примера), chocolatey обращается к nuget-серверу в поисках пакета с таким именем, и получает по нему всю информацию.
Затем скачивает инсталл скрипт и, при наличии, инсталлятор ПО в директорию c:\chocolatey\7zip (по умолчанию). После чего просто запускает инсталятор с указанным набором команд для тихой установки.
choco get 7zip выполняет все те же операции, только без последнего шага установки.
P.S. В Windows 7 и старше можно, после установки WMF 5.1 использовать штатный инструмент работы с пакетами PackageManadger, построенный на базе Chocolatey
Вопрос стоимости стоит не так остро и перевод на домен как-раз проходит тестирование.
В предложенной вами схеме все хорошо, кроме ситуации, когда в пакете драйверов прилетает обновление какого-нибудь драйвера. Все клиенты его начинают качать и обновлять, а он вдруг отказывается работать или в случае с видео-драйвером меняет разрешение экрана, на "более комфортное по мнению производителя".
Вот я и ищу систему, в которую можно будет добавить некоторый набор драйверов, которые в дальнейшем при необходимости дополнять. Т.е. изменение набора драйверов строго контролируемое.
Такое решение хорошо, когда список используемых драйверов ограничен.
При первоначальной настройке ПК проблемы в установке драйверов нет, можно и руками поставить, хоть и не совсем удобно.
А когда этот ПК установлен за 400 км. от тебя и обслуживанием железа занимается подрядчик, которому админских прав давать нельзя? Он может только поменять железку на аналогичную по функционалу, из тех что у него нашлись. И таких ПК по всей России раскидано несколько тысяч, на отдел из 15 человек, это же становится проблемой.
Александр, На сколько я понимаю принцип работы WSUS он получает некий пакет обновлений (например базу драйверов) и распространяет его по подконтрольным ПК. Если драйвера в этом пакете нет, то он его и не найдет. А вмешаться в пакет обновлений и добавить что-то свое представляется маловероятным и не совсем безопасным. Возможно я не прав и пробую изобрести велосипед?
P.S. Мне не требуется постоянно обновлять драйвера имеющиеся в системе. Риск положить группу устройств из-за некорректно обновившегося драйвера не оправдан.
Вячеслав, Так же учитывайте, что вам придется поддерживать данную конструкцию в будущем, поэтому стоит предпочесть стандартное решение с управляемым свитчем.
Вячеслав, для управляемого коммутатора не важно, что находится на другом конце провода, ему нужно знать лишь распределение VLAN.
На нужном порту вы указываете, что в него могут отсылаться пакеты VLAN 90 и 20, в этом нет ничего нестандартного. А вот поскольку, в порт приходят не тэгированные, которые нужно правильно промаркировать и маршрутизировать - уже начинаются костыли.
В зависимости от используемого оборудования, нужно определяться с механизмом разделения трафика. Если как в Linux есть возможность обрабатывать пакеты в pre-routing, и в зависимости от ip-адреса тегировать пакеты, то проблем особых не возникает.
Если такой возможности нет, то нужно или организовать маршрутизацию, чтобы пакеты прошли по нужным vlan и получили тэги, или тэгировать их на конечных устройствах - ПК и точках доступа, если это возможно.
На практике это решается покупкой управляемого коммутатора. Новый микротик на 24 порта, обойдется порядка 10000 рублей. Б\у маршрутизатор на авито, в зависимости от города от 1500 до 5000
Как проставить метки на вашем оборудовании - зависит от оборудования. В Линукс и Mikrotik есть prerouting куда можно добавить правило добавления метки vlan.
Sergey Yamskoy, Jung производитель оборудования стандарта KNX, ценник у него будет заоблачный, да и применимость его под вопросом из-за архитектуры самого KNX.
Александр Скуснов, Я не говорил о смешении. Просто архитектурно они очень между собой похожи.
В пользу этого говорит и то, что HDL производит оборудование для сетей KNX
Я бы не сказал, что она получается дешевле, но у них есть весьма интересные железки. В том числе и совместимые с KNX.
А вот HDL как протокол не совсем понятен. Вроде идея та же что KNX, только реализованная другой фирмой, на сколько я понял.
lazix, Как я понял, у Вас модем настроен в режиме HiLink?
В таком случае нужно смотреть, что в момент отключения происходит в модеме. Не забывайте, что между RouterOS и USB-модемом у вас находится кусок сети, хоть он и не имеет физических устройств. Там как же назначается IP-адрес по DHCP, у которого так же есть время аренды адреса.
Если взять за пример Huawei 7232, то в нем целых две операционных системы: урезанный Android, отвечающий за общение модема с ПК и пользовательский интерфейс, и VxWorks, отвечающая за соединение с сетью в реальном времени.
Самая банальная причина - перегрев модема. Когда процессор скидывает частоту, то приоритет отдается системе жесткого реального времени (VxWorks), а остальное получает Андроид. Соответственно могут подвисать интерфейсы.
Так что для ответа на ваш вопрос нужны логи и с Микротика и с Модема. Иначе это гадание на кофейной гуще.
Про OpenBSD мало пишут, потому что в ущерб оперативности обновлений и новых рюшек, они выбрали стабильность и качественное тестирование. Пользуются ей в основном в проектах, рассчитанных на долгое сопровождение, с поддержкой от людей, которые ее знают от и до. Интернету больше интересна версия FreeBSD.
RouterOS - Линукс, заточенный под работу с сетью. Идут большие споры, по поводу лицензионности т.к. ROS не предоставляет исходники модифицированного ядра, утверждая что оно "ванильное". Заточки под экосистему Microtik особо нет, но совместимость некоторых протоколов с теми же Cisco или Juniper не всегда 100%.
Ну а *WRT это сборка того же Линукса для встраиваемых сетевых систем. Спор о том что лучше DD-WRT или OpenWRT и прочее, c родни спорам о RHEL и Debian.
Отличия версии ядра 10.0.xxxxxx связано с тем, что у Windows 10 и Windows Server 2016 разный формат выхода обновлений. Для Windows 10 используется rolling-relise, где обновления функционала не изменяет номера версии, а только номер сборки. А на смену Server 2016 готовится Server 2019 (хотя разница больше для маркетологов). При таком подходе версии ядра Windows 10 должны в дальнейшем примерно совпадать и с ядрами windows Server 2019, но тут время покажет.
PS. к чему это было и с каких пор на "ТЫ"?