На всякий случай — это такое заглядывание в далёкое и неизбежное будущее, я не говорю, что сейчас так надо делать.
Производительность будет выше, т.к. нет процессов, нет kernel и user, нет IPC, нет классического клипбоарда (любая передача данных — просто ссылка на managed-объект, а все объекты пусть будут read/only, как в чистом лиспе).
Падений не будет, т.к. ВЕСЬ код формально верифицирован и доказана правильность выполнения при корректных входных данных. А проверка корректности входа будет выполнятся единожды при передаче на вход алгоритма. Там, где доказательство провалилось, проверки будут как обычно (к слову, постоянный challenge для математиков: если какая-то сортировка не доказывается формально, а интуитивно правильная, это надо исправлять и фиксить «компилятор»)
Транслируется в 1 sql-запрос, который выберет лучшего клиента (по кол-ву дорогих заказов). Границы между данные в базе и загруженными в память стёрты (хотя можно гибко управлять политиками загрузки, если требуется оптимизация).
Если отвлечься от практики и потеоретизировать, направление на managed-среды в ОСестроительстве давно просматривается (Microsoft чтобы внезапно не оказаться отставшей понемногу тоже пилит).
Плюсы понятны: убрать границы между процессами. Убрать оверхед на IPC и переключение адресных пространств. С другой стороны, будут подтягиваться компиляторы и верификаторы программ. В циклах проверка границ будет только для начального и конечного индекса, а не при каждом обращении к массиву и т.п. Это уменьшит тормоза managed-кода. В идеале компилятор научится полностью доказывать корректность алгоритма (сейчас это возможно, но очень затратно вычислительно) и ставить проверки только на входные параметры функции, а программисту давать warnings — «не могу оптимизировать, выкинув проверки, потому что в таких-то входах программа свалится».
Но пока в юзер-программах есть хоть строчка native-кода, это остаётся небезопасным.
У компании должна быть выработана политика, в которой перечислены разрешенные к употреблению приложения.
Политика вырабатывается не админом, а спускается сверху.
Есть установка делать хорошо работнику, а не превращать рабочее место в тюрьму, особенно когда ничего секретного нет. Оплата за качество и количество сделанной работы, плюс комфорт (всегда можно отвлечься и отдохнуть) делают чудеса: юзеры не отсиживают с 9 до 18 и галопом по звонку домой, а могут без напряга и до 22 поработать. В результате все в выигрыше.
Вариантов полно
Не понимаю, в чём зло фиксированных адресов, что вы готовы столько костылей нагородить в их защиту. При заведении рабочео места просто адрес берётся из соответствующего диапазона, который везде прописан для какой-то политики и всё. Единственный минус, когда за компом могут работать в разные смены, но как правило политика для таких юзеров общая (а если нет, дешевле отдельный комп поставить, и работнику будет комфортнее)
js среди динамических языков занимает место, которое принадлежит C++ у статических.
Все ругают, но в то же время стандарт, куча библиотек, гибкость и т.п.
Юс-кейсы типа «дружбану Васе надо открыть Квейк и Старкрафт» приводят к тому, что потребуется-таки фиксировать его IP в DHCP
http-прокси привязывать к IP легче, чем к NTLM.
Потому что каждый второй автор опен-сорс мнит себя супер-кодером и http-стек делает сам на сокетах, вместо вызова неправославного WinInet.DLL. в итоге, если поддержка прокси и есть, то либо basic, либо md5 digest.
DHCP принято использовать там, где абсолютно неважно, какой адрес схватит клиент
У нас DHCP выдаёт фиксированный адрес (соответствующий MAC).
Иначе как реализовывать хотелки начальства типа «А закрой (открой) ЭТОМУ компу в отделе полный доступ в инет»
Неизвестным MAC-ам выдаётся адрес из пула, который никуда не имеет доступ.
Дайте авторам помечтать, единый DOM на всю систему и возможность подменить из любого скрипта любую функцию системных js-объектов, это ли не торжество гибкости и открытости.
На всякий случай, отметая попытки логически обьяснить такую несуразность: ip-шник для внутренней ФОС давали «белый», просто он был изолирован от внешней сети фаирволом
Я не говорю, что есть какая-то проблема.
Мне, как и другим здесь читателям, интересно узнать, как устроена раздача IPv6 у реального провайдера в реальной ситуации.
Теоретизировать и цитировать документацию можно сколько угодно, но в реальности может быть совсем по-другому. Например, у покойного Волгателекома до запуска безлимитных тарифов было два PPP соединения (для внутреннего ФОСа и внешки), и абоненты сами мучались с маршрутизацией и оборудованием, не поддерживающем поднятие двух сессий.
Баг в том, что переходы между подгрузками сшиты неидеально. Можно выпрыгнуть из тележки на уровне Intro.
Здесь демо: www.youtube.com/watch?v=YOhSRBtatCc
Да, нужно переписать класс. Если есть сценарии, когда ссылка не инициализирована, лучше использовать указатель.
Практически, инициализация неиспользуемых ссылок dereferenced NULL-ом никогда не вызывала проблем.
В первой халфе можно было проскочить через окно тележки в начале игры. Правда, идти совcем некуда — или тупик на рельсах, или умираешь при падении вниз. В BlackMesa заюзать баг не получилось.
Производительность будет выше, т.к. нет процессов, нет kernel и user, нет IPC, нет классического клипбоарда (любая передача данных — просто ссылка на managed-объект, а все объекты пусть будут read/only, как в чистом лиспе).
Падений не будет, т.к. ВЕСЬ код формально верифицирован и доказана правильность выполнения при корректных входных данных. А проверка корректности входа будет выполнятся единожды при передаче на вход алгоритма. Там, где доказательство провалилось, проверки будут как обычно (к слову, постоянный challenge для математиков: если какая-то сортировка не доказывается формально, а интуитивно правильная, это надо исправлять и фиксить «компилятор»)
Транслируется в 1 sql-запрос, который выберет лучшего клиента (по кол-ву дорогих заказов). Границы между данные в базе и загруженными в память стёрты (хотя можно гибко управлять политиками загрузки, если требуется оптимизация).
Плюсы понятны: убрать границы между процессами. Убрать оверхед на IPC и переключение адресных пространств. С другой стороны, будут подтягиваться компиляторы и верификаторы программ. В циклах проверка границ будет только для начального и конечного индекса, а не при каждом обращении к массиву и т.п. Это уменьшит тормоза managed-кода. В идеале компилятор научится полностью доказывать корректность алгоритма (сейчас это возможно, но очень затратно вычислительно) и ставить проверки только на входные параметры функции, а программисту давать warnings — «не могу оптимизировать, выкинув проверки, потому что в таких-то входах программа свалится».
Но пока в юзер-программах есть хоть строчка native-кода, это остаётся небезопасным.
Политика вырабатывается не админом, а спускается сверху.
Есть установка делать хорошо работнику, а не превращать рабочее место в тюрьму, особенно когда ничего секретного нет. Оплата за качество и количество сделанной работы, плюс комфорт (всегда можно отвлечься и отдохнуть) делают чудеса: юзеры не отсиживают с 9 до 18 и галопом по звонку домой, а могут без напряга и до 22 поработать. В результате все в выигрыше.
Не понимаю, в чём зло фиксированных адресов, что вы готовы столько костылей нагородить в их защиту. При заведении рабочео места просто адрес берётся из соответствующего диапазона, который везде прописан для какой-то политики и всё. Единственный минус, когда за компом могут работать в разные смены, но как правило политика для таких юзеров общая (а если нет, дешевле отдельный комп поставить, и работнику будет комфортнее)
Все ругают, но в то же время стандарт, куча библиотек, гибкость и т.п.
Юс-кейсы типа «дружбану Васе надо открыть Квейк и Старкрафт» приводят к тому, что потребуется-таки фиксировать его IP в DHCP
http-прокси привязывать к IP легче, чем к NTLM.
Потому что каждый второй автор опен-сорс мнит себя супер-кодером и http-стек делает сам на сокетах, вместо вызова неправославного WinInet.DLL. в итоге, если поддержка прокси и есть, то либо basic, либо md5 digest.
Конечно, v4. Я сейчас не скажу точное название технологии, но DHCP-сервер один, а свичи умеют его как бы проксировать в сети отделов.
И как это сделать, если клиенты — Windows, а шлюз — FreeBSD либо RouterOS?
У нас DHCP выдаёт фиксированный адрес (соответствующий MAC).
Иначе как реализовывать хотелки начальства типа «А закрой (открой) ЭТОМУ компу в отделе полный доступ в инет»
Неизвестным MAC-ам выдаётся адрес из пула, который никуда не имеет доступ.
http://diamondsteel.ru/useful/handbook/6.html#6.1.3.
Мне, как и другим здесь читателям, интересно узнать, как устроена раздача IPv6 у реального провайдера в реальной ситуации.
Теоретизировать и цитировать документацию можно сколько угодно, но в реальности может быть совсем по-другому. Например, у покойного Волгателекома до запуска безлимитных тарифов было два PPP соединения (для внутреннего ФОСа и внешки), и абоненты сами мучались с маршрутизацией и оборудованием, не поддерживающем поднятие двух сессий.
Здесь демо:
www.youtube.com/watch?v=YOhSRBtatCc
Практически, инициализация неиспользуемых ссылок dereferenced NULL-ом никогда не вызывала проблем.