Хм, я не понял в каком случае мы проигрываем производительность, а в каком наоборот? Асинхронный ввод/вывод — один из тех немногих случаев, когда компромиссов мы не делаем: выигрыш идет по всем параметрам.
Насчет обсуждения возможности вызова произвольного сискола асинхронно я тоже помню — но не помню, где видел. По факту это все тот же пул потоков плюс/минус специальные «костыли» в скедьюлере.
В любом случае, описать prefork, select и poll, но не упомянуть асинхронный ввод/вывод (независимо от того, насколько ужасна его реализация) — это несколько поверхностно, не находите?
Для асинхронного I/O. Точка. Больше ничего в стандарте на этот счет не сказано. Асинхронный вывод нужен там, где операция ввода/вывода может занять неопределенное время (то есть там же, где и «неблокирующий»). То есть при работе с сетью тоже. Все остальное — Ваше ЛИЧНОЕ мнение пока Вы не подтвердите его цитатой.
он динамически растёт и можно задавать максимальные границы с помощью SO_RCVBUF.
Позволю себе процитировать источник, который, как Вы успели заметить, мне не нравится, что не освобождает Линукс от необходимости следования ему «The SO_RCVBUF option requests that the buffer space allocated for receive operations on this socket be set to the value, in bytes, of the option value.»
Я вообще не упоминал «мою любимую винду», но да — там это сделано по уму (хотя WinSock мне не очень нравится — уж очень сильное влияние BSD sockets).
Поведение WSARecv с нулевым буфером неопределено, и у меня есть серьезные подозрения, что это закончится AV. Фактически выделение буфера (даже с MEM_COMMIT) — это резервирование места в пейджфайле. Ну то есть система обещает нам дать столько, если мы попросим. Если не попросим — единственной «проблемой» будет увеличение циферки в таск менеджере, а если попросим — так какая разница (в разрезе количества памяти) «неблокирующая» операция или асинхронная? Есть и другой вариант: система пообещала что даст нам некое количество памяти, но на самом деле оставляет за собой право убить любого кто на самом деле запросит эту память (оверкоммит и оомкиллер).
в линуксе есть vmsplice/splice
Zero-copy был назван как один из бенефитов асинхронных операций (и, повторюсь, я полностью осознаю, что TOE находится вне контекста данного обсуждения, как не помогающий в решении «проблемы» c10k — у него совершенно другие задачи) и невозможен без полного оффлоада протокола. Stateless оффлоады (как впрочем и отсутствие оффлоадов вообще) могут помочь только доставить в память (по DMA естественно) сетевой фрейм. Далее эти фреймы нужно пересобрать (с отрезанием заголовков и упорядочиванием) — для этого необходимо копирование. Даже если бы Линукс поддерживал TOE, при неблокирующем вводе/выводе, лучшее на что можно надеяться это прямая запись в буфер драйвера транспорта (TCP) — копирование из этого буфера в пользовательский все еще необходимо. vmsplice/splice здесь не помощник.
забыли упомянуть про то что нужен будет раундтрип для того чтобы снова сделать WSARead
На latency это никак не отразится: мы же запостим два буфера, так? И пока один закомплитится и наполняется второй — мы запостим третий.
Хотя в случае когда будем использовать нулевые буфферы для уведомления, а потом неблокирующее чтение — получим три раундтрип
Оставляя в стороне саму возможность работоспособности подобного решения (мне лень тестить и я не нашел ничего подобного в MSDN, но «мне кажется», что WSARecv просто упадет если подсунуть ему нулевой буфер), у Вас есть хоть один пример использования подобного подхода в «дикой природе»?
Как оказывается, еще более поразительным является то, что даже те, кто вроде бы и знают о существовании асинхронного ввода/вывода, совершенно не представляют себе что это такое и почему это единственный правильный способ.
ну начнём с того что это апи для работы с фс, а не сетью.
Ну начнем с того, что подтвердить это утверждение очень просто — нужно всего лишь привести цитатку из стандарта. Предупреждая Вашу попытку выставить aio_fildes как доказательство, отмечу, что socket возвращает как раз его: «Upon successful completion, socket() shall return a non-negative integer, the socket file descriptor».
Более того, в Линуксе есть асинхронные операции предназначенные исключительно для работы с диском, пусть это и является довольно уродливым решением с точки зрения дизайна.
а закончим тем что в случае с проактор паттерном приходится выделять буфферы для чтения на каждый сокет чтобы пропихнуть его в aio_read
Вот Вы сейчас противопоставляете необходимость выделения буфера под прием данных чему? Неужели сокет сам по себе не имеет буфера на прием? Неужто SO_RCVBUF в Линуксе по умолчанию установлен в 0 и любые данные, на которые нет outstanding read мгновенно теряются. Вот это новость.
Но позвольте мне продолжить Вашу мысль:
В-третьих: мы избавляемся от лишнего копирования: сначала в буфер драйвера tcp, а потом в пользовательский (пользователь в данном случае — это пользователь API, то есть программист). К тому же при наличии TOE (да, я знаю, что он не решает «проблему» c10k, но он очень хорошо вписывается в модель асинхронного ввода/вывода) количество копирований можно сократить до 0 (НУЛЯ): с «провода» сразу в пользовательский буфер по DMA.
В-четвертых: мы снижаем задержки (latency) и снижаем нагрузку на процессор. С неблокирующим вводом/выводом нам нужно как минимум два раундтрипа в ядро и обратно: сначала с нотификацией, что есть данные, а потом поход за самими данными. В то же время асинхронный ввод/вывод разбудит нас сразу с данными.
В-пятых: асинхронный ввод/вывод концептуально чище: он превращается в синхронный (блокирующий или нет) всего лишь оберткой с одним дополнительным wait-ом в конце, в то время как синхронный в асинхронный не превращается никак (можно придумать схемы с пулом потоков или с порождением новых потоков на каждую операцию, но они будут либо слишком «дорогими», либо слишком неустойчивыми к «нестандартной» нагрузке, либо и то другое вместе).
Список можно продлжать, но на мой взгляд, то что приведено выше — уже достаточно веские основания задуматься.
В заключение хочу отметить, что конкретная РЕАЛИЗАЦИЯ асинхронного ввода/вывода может быть очень плохой (что в случае Линукса меня бы совершенно не удивило), что не отменяет моего изначального тезиса о том, что настоящий асинхронный ввод/вывод имеет кучу преимуществ перед «неблокирующим», в то время как обратное несправедливо: нет ни одного преимущества «неблокирующего» ввода/вывода перед асинхронным.
Что поразительно так это то, насколько регулярно в подобных обзорах/обучающих материалах «забывают» про единственный правильный способ: асинхронный ввод/вывод, который наконец-то появился даже в юниксах. Можете назвать хоть одно преимущество «неблокирующего» ввода/вывода перед настоящим асинхронным?
А при чем здесь винда? Это select сам по себе такой. Более того, оригинально он еще и битмаски использовал, что мешало ему работать с дескрипторами имеющими номер выше определенного (насколько я знаю apache делает кучу dup2 для перемещения несокетных дескрипторов «вверх» и сокетных — «вниз»). Вообще, история c10k в юниксах (включая wannabe — типа линукса) — это леденящий душу триллер.
Наша песня хороша.
Вот Вам нужно, чтоб в семерке были улучшенные кодеки. Мне — чтоб там были AppContainer-ы (и EPM в IE), nested job-ы, DirectComposition, ReFS, клиентский гипервизор, овощи там рожь, вот это все. Кто-то жить не может без Store, а еще кому-то подавай непременно искоробочную поддержку iso, vhd и пр…
Кроме того, IE10, PS3, .net4.5 и прочие бекпортированные компоненты всенепременно должны быть «искаропки», а не устанавливаться отдельными даунлоадами. Причем бекпортировано все должно быть как минимум до NT3.1 (включая Win95/98 — и не спрашивайте меня как это технически возможно, они ДОЛЖНЫ и все).
Что у нас получается? Правильно — Win8. Ваша претензия сводится к тому, что Вы хотите чтоб Win8 Вам дали бесплатно, а деньги пусть делают продавая (прямо или косвенно) Ваши личные данные заинтересованным лицам.
Да, панель та же самая, что и на Вашем видео. Просто BupycNet говорил о тач интерфейсе андроида — я и сказал о том, как вытащить эту панель на тач интерфейсе (причем этот способ доступен еще то ли с DP то с CP — уже точно не помню, но точно уже довольно долго).
Для 10 приложений есть жест «свайп из-за левого края экрана и не прекращая жеста — вернуться обратно». Он вызывает ту же самую панель, которая с клавиатуры открывается по Win-Tab. Оттуда можно приложения утаскивать вниз для закрытия или тапать для активации.
После чего «Play to» с любого компьютера. Отдельный минус за использование AutoIt: жать по кнопочкам в интерфейсе это настолько же убого, насколько и «юникс-вей», когда программы пытаются «понять» и контроллировать UI других программ. UI — это USER interface (будь то CLI или Graphical), а для управления одних программ другими придумали такую штуку, как API (шок!).
Ну, вопрос не такой уж глупый на самом деле. GDI redirection включается только если включен DWM. Более того, сам DWM его явно и включает вызовом DwmStartRedirection. На безопасность это мало влияет, потому что хоть GDI и редиректится, но все объекты все так же доступны всем процессам (кроме случаев, когда «гайки подтянуты» с помощью JOBOBJECT_BASIC_UI_RESTRICTIONS, но надо полагать с этими ограничениями есть проблемы совместимости, потому что сам MS не использует их в Protected Mode IE песочницах). Mirror Driver-ы несовместимы с WDDM и сразу выбивают Windows в Basic Mode (с отключением композитинга и перенаправления). Только что проверил, Basic Mode в Win8 использует композитинг — просто рисует все «классически».
Ну а в Win8 была введена новая модель для приложений — они изначально изолированы от всех остальных и могут общаться только через ограниченный (и полностью контроллируемый системой) набор контрактов — и MS с радостью решили все проблемы безопасности, вызванные требованием обратной совместимости. Повторюсь, в новой модели работают только Metro приложения (ну по-крайней мере большинство из них) и песочницы десктопного IE в режиме EPM. Об AppContainer-ах пока известно довольно мало, так что расспрашивать меня о подробностях бесполезно.
В общем резюмируя, хочется самоограничений? На Win7 и ниже следует использовать job object-ы, restricted token-ы (может быть одним из ограничений job object-а), low integrity (MIC) и (опционально) отдельный десктоп/сессию. На Win8 и выше можно использовать все то же самое, но лучше воспользоваться инфраструктурой AppContainer-ов
Нет, если Вы хотите решить все проблемы сразу не особо задумываясь о дизайне, то Вам в Линукс. Правда потом придется эти опять решать эти же проблемы. Все и сразу.
Давайте теперь на секундочку остановимся и помоделируем угрозы. Прежде всего Вы предлагаете хранить настройки в KTHREAD-е, то есть сделать так чтобы разные потоки в одном адресном пространстве имели разный уровень доверия? Уже одного этого достаточно, чтобы отмести всю идею целиком, как не заслуживающую внимания (да-да, в Линуксе именно так и сделано). Impersonation token-ы, которые хранятся для каждого потока предназначены не для ограничения недоверенного кода, а как раз таки для того, чтобы исполнять ДОВЕРЕННЫЙ код с правами клиента.
Далее, для всех «родных» NT-шных объектов (те, которые в \ObjectTypes) — restricted token-ов более чем достаточно. Более того, они одновременно обеспечивают и большую гибкость и лучшую целостность решения, по сравнению с тем, что предлагаете Вы. Что же до «тяжкого наследия» — USER/GDI объектов, то здесь все довольно печально. Вряд ли можно сделать что либо реально безопаснее (а не просто дающее ложное чувство безопасности), чем существующий UIPI в пределах одной сессии (разные сессии и так отлично изолированы друг от друга) без довольно кардинального «перепиливания» кучи подсистем. Любой «поток», которому Вы разрешите NtGdiBitBlt сотоварищи сможет читать информацию из любого окна в приложении. Не стоит этим пренебрегать: подумайте о переписке в чате/почте, секретных вопросах от банкинга и прочих онлайн аккаунтов и т.п. — ведь мы же хотим РЕШИТЬ вопрос, а не просто сделать вид, что мы типа теперь «стали более лучше» обеспечивать сохранность данных, да?
Хорошие новости: насколько я знаю каждый AppContainer в Win8 имеют собственный набор USER/GDI объектов и таким образом они полностью изолированы друг от друга и от остальной системы. Все Metro приложения (включая Metro IE), а также десктопный IE со включенным Enhanced Protected Mode используют AppContainer-ы для изоляции кода с разным уровнем доверия. Подготовительная работа как ни странно была сделана еще в Висте: композитинг это не только стекляшки и анимашки, это еще и «виртуализация» (перенаправление) GDI ресурсов, а раз они уже виртуализованы, то им можно перестать быть глобальными в пределах десктопа.
Насколько я знаю — да. Но в момент передачи по наследству они становятся обычным доходом и весь остаток целиком включается в годовой доход получателя и если у него уже есть доход, то и с налоговой точки зрения этот дополнительный доход будет считаться по верхним бакетам.
Ну давайте тогда уж и среднюю ожидаемую продолжительность жизни учитывать. Если даже допустить, что пенсии будут честно индексироваться вслед за инфляцией, то начиная работать в 22-23 года (айтишники чаще всего таки получают высшее образование) и выйдя на пенсию в 60 (если за время Вашей жизни не повысят до 65) Вы выплачиваете пенсионный налог в течение 444-х месяцев. В то же время средняя ожидаемая продолжительность жизни мужчины в Украине — 62.1 года. Таким образом в среднем Вы получаете пенсию 25 месяцев.
Только 401(k) — он не государству, а себе же (ну следует иметь в виду, что деньги там лежат в акциях/бондах, так что могут и «сгореть» за ночь). Вплоть до того, что со своего пенсионного счета можно забрать деньги (не все и при условии, что потом положишь обратно), если очень нужно.
Более того, выплаты идут before tax (хотя есть еще after tax и roth). Это т.н. отложенный налог, то есть, когда ты работаешь и получаешь много ты уменьшаешь налоогоблагаемую базу (не платишь гигантские проценты из верхних бакетов), а когда выходишь на пенсию — начинаешь снимать со своего 401(к) деньги по 10-20к в год (к примеру — ведь государственная пенсия тоже полагается) и платишь с этого «дохода» деньги. Другими словами, 401(k) это способ перенести свой теперешний доход в будущее.
Ну и еще стоит учесть, что для поощрения личных накоплений большинство крупных работодателей имеют matching program. То есть на каждый доллар, который работник откладывает себе на 401(к) работодатель платит 0.5-1 доллар сверху. И опять-таки, это не отражается на текущих налогах — налоги с этого заработка платятся в момент снятия.
Насколько я понял, он имеет в виду это. Триллион долларов на «оборону» — и рост почти в 3 раза за последние 10 лет. Envy — что с него взять (с другой стороны, в самих США тоже мало кто счастлив по этому поводу, хотя чаще всего в гораздо более конструктивной форме, чем это делают из России).
Нашел вот такую статью. Насколько я знаю, можно заплатить за часть года обоим, а можно если количество дней проведенных в штате позволяет, то можно заплатить одному из штатов за полный год, а другому — разницу между полной суммой за часть года, проведенную во втором штате и суммой, которая уже заплачена за эту часть первому штату.
Да, думаю стоит добавить, что «tax return» вполне может быть и отрицательным. И хотя бы тезисно объяснить что это. Работодатель на основании W-4 вычитает некоторую приблизительную сумму из каждой зарплаты, а в начале следующего года исходя из реального заработка за год заполняется «tax return» (форма 1040) и IRS выплачивает тебе (или ты выплачиваешь IRS, что возможно, но встречается реже) разницу.
Насчет обсуждения возможности вызова произвольного сискола асинхронно я тоже помню — но не помню, где видел. По факту это все тот же пул потоков плюс/минус специальные «костыли» в скедьюлере.
В любом случае, описать prefork, select и poll, но не упомянуть асинхронный ввод/вывод (независимо от того, насколько ужасна его реализация) — это несколько поверхностно, не находите?
Для асинхронного I/O. Точка. Больше ничего в стандарте на этот счет не сказано. Асинхронный вывод нужен там, где операция ввода/вывода может занять неопределенное время (то есть там же, где и «неблокирующий»). То есть при работе с сетью тоже. Все остальное — Ваше ЛИЧНОЕ мнение пока Вы не подтвердите его цитатой.
Позволю себе процитировать источник, который, как Вы успели заметить, мне не нравится, что не освобождает Линукс от необходимости следования ему «The SO_RCVBUF option requests that the buffer space allocated for receive operations on this socket be set to the value, in bytes, of the option value.»
Я вообще не упоминал «мою любимую винду», но да — там это сделано по уму (хотя WinSock мне не очень нравится — уж очень сильное влияние BSD sockets).
Поведение WSARecv с нулевым буфером неопределено, и у меня есть серьезные подозрения, что это закончится AV. Фактически выделение буфера (даже с MEM_COMMIT) — это резервирование места в пейджфайле. Ну то есть система обещает нам дать столько, если мы попросим. Если не попросим — единственной «проблемой» будет увеличение циферки в таск менеджере, а если попросим — так какая разница (в разрезе количества памяти) «неблокирующая» операция или асинхронная? Есть и другой вариант: система пообещала что даст нам некое количество памяти, но на самом деле оставляет за собой право убить любого кто на самом деле запросит эту память (оверкоммит и оомкиллер).
Zero-copy был назван как один из бенефитов асинхронных операций (и, повторюсь, я полностью осознаю, что TOE находится вне контекста данного обсуждения, как не помогающий в решении «проблемы» c10k — у него совершенно другие задачи) и невозможен без полного оффлоада протокола. Stateless оффлоады (как впрочем и отсутствие оффлоадов вообще) могут помочь только доставить в память (по DMA естественно) сетевой фрейм. Далее эти фреймы нужно пересобрать (с отрезанием заголовков и упорядочиванием) — для этого необходимо копирование. Даже если бы Линукс поддерживал TOE, при неблокирующем вводе/выводе, лучшее на что можно надеяться это прямая запись в буфер драйвера транспорта (TCP) — копирование из этого буфера в пользовательский все еще необходимо. vmsplice/splice здесь не помощник.
На latency это никак не отразится: мы же запостим два буфера, так? И пока один закомплитится и наполняется второй — мы запостим третий.
Оставляя в стороне саму возможность работоспособности подобного решения (мне лень тестить и я не нашел ничего подобного в MSDN, но «мне кажется», что WSARecv просто упадет если подсунуть ему нулевой буфер), у Вас есть хоть один пример использования подобного подхода в «дикой природе»?
Ну начнем с того, что подтвердить это утверждение очень просто — нужно всего лишь привести цитатку из стандарта. Предупреждая Вашу попытку выставить aio_fildes как доказательство, отмечу, что socket возвращает как раз его: «Upon successful completion, socket() shall return a non-negative integer, the socket file descriptor».
Более того, в Линуксе есть асинхронные операции предназначенные исключительно для работы с диском, пусть это и является довольно уродливым решением с точки зрения дизайна.
Вот Вы сейчас противопоставляете необходимость выделения буфера под прием данных чему? Неужели сокет сам по себе не имеет буфера на прием? Неужто SO_RCVBUF в Линуксе по умолчанию установлен в 0 и любые данные, на которые нет outstanding read мгновенно теряются. Вот это новость.
Но позвольте мне продолжить Вашу мысль:
В-третьих: мы избавляемся от лишнего копирования: сначала в буфер драйвера tcp, а потом в пользовательский (пользователь в данном случае — это пользователь API, то есть программист). К тому же при наличии TOE (да, я знаю, что он не решает «проблему» c10k, но он очень хорошо вписывается в модель асинхронного ввода/вывода) количество копирований можно сократить до 0 (НУЛЯ): с «провода» сразу в пользовательский буфер по DMA.
В-четвертых: мы снижаем задержки (latency) и снижаем нагрузку на процессор. С неблокирующим вводом/выводом нам нужно как минимум два раундтрипа в ядро и обратно: сначала с нотификацией, что есть данные, а потом поход за самими данными. В то же время асинхронный ввод/вывод разбудит нас сразу с данными.
В-пятых: асинхронный ввод/вывод концептуально чище: он превращается в синхронный (блокирующий или нет) всего лишь оберткой с одним дополнительным wait-ом в конце, в то время как синхронный в асинхронный не превращается никак (можно придумать схемы с пулом потоков или с порождением новых потоков на каждую операцию, но они будут либо слишком «дорогими», либо слишком неустойчивыми к «нестандартной» нагрузке, либо и то другое вместе).
Список можно продлжать, но на мой взгляд, то что приведено выше — уже достаточно веские основания задуматься.
В заключение хочу отметить, что конкретная РЕАЛИЗАЦИЯ асинхронного ввода/вывода может быть очень плохой (что в случае Линукса меня бы совершенно не удивило), что не отменяет моего изначального тезиса о том, что настоящий асинхронный ввод/вывод имеет кучу преимуществ перед «неблокирующим», в то время как обратное несправедливо: нет ни одного преимущества «неблокирующего» ввода/вывода перед асинхронным.
Well, that's why we have backup systems here
Другими словами: хорош писать чушь.
Вот Вам нужно, чтоб в семерке были улучшенные кодеки. Мне — чтоб там были AppContainer-ы (и EPM в IE), nested job-ы, DirectComposition, ReFS, клиентский гипервизор, овощи там рожь, вот это все. Кто-то жить не может без Store, а еще кому-то подавай непременно искоробочную поддержку iso, vhd и пр…
Кроме того, IE10, PS3, .net4.5 и прочие бекпортированные компоненты всенепременно должны быть «искаропки», а не устанавливаться отдельными даунлоадами. Причем бекпортировано все должно быть как минимум до NT3.1 (включая Win95/98 — и не спрашивайте меня как это технически возможно, они ДОЛЖНЫ и все).
Что у нас получается? Правильно — Win8. Ваша претензия сводится к тому, что Вы хотите чтоб Win8 Вам дали бесплатно, а деньги пусть делают продавая (прямо или косвенно) Ваши личные данные заинтересованным лицам.
После чего «Play to» с любого компьютера. Отдельный минус за использование AutoIt: жать по кнопочкам в интерфейсе это настолько же убого, насколько и «юникс-вей», когда программы пытаются «понять» и контроллировать UI других программ. UI — это USER interface (будь то CLI или Graphical), а для управления одних программ другими придумали такую штуку, как API (шок!).
Ну а в Win8 была введена новая модель для приложений — они изначально изолированы от всех остальных и могут общаться только через ограниченный (и полностью контроллируемый системой) набор контрактов — и MS с радостью решили все проблемы безопасности, вызванные требованием обратной совместимости. Повторюсь, в новой модели работают только Metro приложения (ну по-крайней мере большинство из них) и песочницы десктопного IE в режиме EPM. Об AppContainer-ах пока известно довольно мало, так что расспрашивать меня о подробностях бесполезно.
В общем резюмируя, хочется самоограничений? На Win7 и ниже следует использовать job object-ы, restricted token-ы (может быть одним из ограничений job object-а), low integrity (MIC) и (опционально) отдельный десктоп/сессию. На Win8 и выше можно использовать все то же самое, но лучше воспользоваться инфраструктурой AppContainer-ов
Restricted token-ы появились в винде почти 15 лет назад. Есть статьи о сендбоксинге в винде от самих разработчиков MS, которым уже 5 лет.
Давайте теперь на секундочку остановимся и помоделируем угрозы. Прежде всего Вы предлагаете хранить настройки в KTHREAD-е, то есть сделать так чтобы разные потоки в одном адресном пространстве имели разный уровень доверия? Уже одного этого достаточно, чтобы отмести всю идею целиком, как не заслуживающую внимания (да-да, в Линуксе именно так и сделано). Impersonation token-ы, которые хранятся для каждого потока предназначены не для ограничения недоверенного кода, а как раз таки для того, чтобы исполнять ДОВЕРЕННЫЙ код с правами клиента.
Далее, для всех «родных» NT-шных объектов (те, которые в \ObjectTypes) — restricted token-ов более чем достаточно. Более того, они одновременно обеспечивают и большую гибкость и лучшую целостность решения, по сравнению с тем, что предлагаете Вы. Что же до «тяжкого наследия» — USER/GDI объектов, то здесь все довольно печально. Вряд ли можно сделать что либо реально безопаснее (а не просто дающее ложное чувство безопасности), чем существующий UIPI в пределах одной сессии (разные сессии и так отлично изолированы друг от друга) без довольно кардинального «перепиливания» кучи подсистем. Любой «поток», которому Вы разрешите NtGdiBitBlt сотоварищи сможет читать информацию из любого окна в приложении. Не стоит этим пренебрегать: подумайте о переписке в чате/почте, секретных вопросах от банкинга и прочих онлайн аккаунтов и т.п. — ведь мы же хотим РЕШИТЬ вопрос, а не просто сделать вид, что мы типа теперь «стали более лучше» обеспечивать сохранность данных, да?
Хорошие новости: насколько я знаю каждый AppContainer в Win8 имеют собственный набор USER/GDI объектов и таким образом они полностью изолированы друг от друга и от остальной системы. Все Metro приложения (включая Metro IE), а также десктопный IE со включенным Enhanced Protected Mode используют AppContainer-ы для изоляции кода с разным уровнем доверия. Подготовительная работа как ни странно была сделана еще в Висте: композитинг это не только стекляшки и анимашки, это еще и «виртуализация» (перенаправление) GDI ресурсов, а раз они уже виртуализованы, то им можно перестать быть глобальными в пределах десктопа.
Более того, выплаты идут before tax (хотя есть еще after tax и roth). Это т.н. отложенный налог, то есть, когда ты работаешь и получаешь много ты уменьшаешь налоогоблагаемую базу (не платишь гигантские проценты из верхних бакетов), а когда выходишь на пенсию — начинаешь снимать со своего 401(к) деньги по 10-20к в год (к примеру — ведь государственная пенсия тоже полагается) и платишь с этого «дохода» деньги. Другими словами, 401(k) это способ перенести свой теперешний доход в будущее.
Ну и еще стоит учесть, что для поощрения личных накоплений большинство крупных работодателей имеют matching program. То есть на каждый доллар, который работник откладывает себе на 401(к) работодатель платит 0.5-1 доллар сверху. И опять-таки, это не отражается на текущих налогах — налоги с этого заработка платятся в момент снятия.