Это прекрасно. Ноу Linux нет COM. А у Windows она есть давным давно. Что прикажете с ней делать? Объясняю на пальцах.
У вас есть некий DLL являющийся контейнером объекта COM. Этот объект загружен и используется. И тут вы волшебным образом подменяете файл используя волшебную силу inodes. Внимание вопрос — если ещё одно приложение попробует создать этот объект — какая версия будет создана?
Вторая проблема — ресурсы. Ресурсы в Windows загружаются не в момент загрузки приграммы, а по мере использования или по запросу.
Третья проблемма — DLL. У вас есть некая системная DLL, которую использует множетсво приложений. И тут вы её находу заменяете. А потом запускается новое приложение и пытается вручную загрузить ещё один экземпляр этотй DLL. Но это уже другая DLL! А теперь учтите, что у DLL есть методы, вызываемые при первоначальной загрузке, а тут первоначальных загрухок получается две.
Не нужно считать других глупее себя. Просто пример — запустите в Windows любой исполняемый файл. А теперь переименуйте его. Фокус-покус! Файл перименовался! Причём фал не просто продолжает работать, но и может использовать ресурсы. Хотя, следуя логиrе автора быть такого ну, никак не может. Inodes в данном случае заменяет module instance handle. И не важно какая файловая система.
Не нужно считать других глупее себя. Microsoft сознательно отказалась от идеи виртуальной файловой системы ядра, так, как развязывало ей руки в применении множества других перспективных технологий.
Юниксзародился на мейнфрейме GE-600. А на PDP-7 долго влачил жалкое существование — группа разрабочиков очень хотела перейти на более мощную машину, т.к. ресурсов PDP-7 не хватало. Второе дыхание проект получил перейда на PDP-11/20, а это уже весьма мощный компьютер. Там же он обрёл соврtменные черты. Уже в конце 80х ядро линукса (только ядро!) превышало 40КБ — по тем временам очень много! Предшественник DOS — CP/M, в котором и родился FAT, занимал лишь несколько килобайт.
Дык никто про соврешенство и не говорит, но на тот момент это была весьма современная ОС. В 128 КБ ОЗУ и такое затолкать сумать нужно. Не слудет забывать, что юникс на тот момент был уделом больших ЭВМ.
Все не так просто. FAT намного проще чем любая UNIX-система. Более того, если всё так, как написано, то почему не случилось чуда при использовании NTFS? Там метаинформация отделена от данных.
Хрень. «до 2000 MIPS» это на предельной частоте за счёт весьма своеобразной системы команд ARM. MIPS'ами разные архитектуры процессоры мерить — неблагодраное дело. Плюс, эти цифры — пиковая производительность. Например Pentim3 исполняет В СРЕДНЕМ больше двух команд за такт. Atom — три. А вот 2000 MIPS на 1 GHz для Cortex — ПИКОВАЯ производительность на некоторых комнадах. Чувствуете разницу между пиковой производительностью и средним количеством команд на такт? Если считать производительность P3 по той же методике, то на командах с косвенной индексой адресацией получим целый ваго мипсов. Вот только, это — отдельные команды, а не производительность процессора.
Эффективный многоуровневый кэш, эффективная работа с невыровнеными данными, предвыборка команд, предсказание ветвлений, переименование регистров, несколько целочисленных блоков — всего этого нет в ARM. На прикладных задачах, при равной частоте ARM проигрывает современным x86 почти на порядок. Вокруг Cortex-A8 и иже с ними раздуто много шумихи, но дальше прототипов дело пока не идёт. Полный интернет чудо-нетбуков на Cortex показывающих соизмеримую с x86 производительность, но я пока что не видел ни одного сравнения их на серверной платформе на серьёзных задачах. Одно дело странички в браузере открывать и Full HD играть и совсем другое дело — Web/файловы/баз данных сервер.
А смысл? Производительность ARM принципиально ниже современных x86.
Учитывая, что за ту же $1000 можно собрать три-четыре Atom/VIA/Geode на частотах >1GHz и памятью каждого ~1GB, то можно получить более производительную систему. А один жалкий Core2Duo на паре-тройке гигагерц покажет ту же производительность, при приципиально меньшей сложности и бОльших возможностях. Короче, очень сомнительно с точки зрения целесообразности.
А где у нас в законе об авторском праве написано про «нотариально заврененный перевод»? А вот про публичную оферту очень даже написано.
Это во-первых.
А во-вторых, я уже тут с кем-то на эту тему спорил — в росси действуют любые документы на любых языках если они не противоречат российскому законодательству.
Думаю, что если бы рядом с «частной дорогой» была бы табличка запрещающая треспасинг, то всё было бы совсем по-другому. А может быть они неправильно иск составили — возможно, стоило делать упор не на фотографирование а на нарушения границ частной собственности, но не факт, что за это дали бы денег.
А, вообще, «частная дорога» и «частная собственность» в Америке разные вещи.
Очередной дизайнерский бред. Первое — зачем уменьшать диагональ? Второе — на каких современных или перспективных технологиях это может быть реализовано?
Лет восемьназад видел такие струйники в продаже. Были и модели (от HP или Canon) с аккумуляторами. Внешней дизайн практически такой же. Так что Хунг со своим концептом. малость опоздал на десяток лет.
Диски с паспортными данными продаются на рынках. Они доступны куче людей работающим у сотвого оператора. Они известны налоговой и т.п. Что мешает диллеру достать паспортные данные в любом из этих мест использовать их для продажи левых симок.
А вы тут при чём? Вы совершенно не обязаны хранить паспортные данные в тайне. более того их кроме Вас ещё уйма народу сейчас знает. так что привязка любых симок к паспортным данным — личное дело оператора. Имеет значение только Ваша подпись на договре. Так как её там нет, то это тоже проблеммы оператора. Судиться они могут до одури, но ничего не пролучат, так как первая же экспертиза установит, что подпись не Ваша.
ну, выделять 500М виртуальной, это во-первых суметь надо — само по-себе оно не выделится. Или иметь руки с совсем не правильным радиусом кривизны и сделать софтину выделяющую 500 метров обычной памяти. В любой случае, нормальные люди такие вещи без надобности не делают.
и повторяю — виртульная память к жёстким дискам не относится. Она не обязательно сброшена в файл подкачи.
Это уж, как измерять. Некоторые тесты и софтины не учитывают (это кто это?) в виртуальной памяти объем реальной памяти, занимаемой приложением, но это не верно — реальная память также является виртуальной. Ибо виртульная память — кол-во адресов памяти выделенных процессу. А уж что по этим адресам находится — настоящая память, ничего (резерв для выделения памяти), память выгруженная в файл подкачки — это вопрос второй. Выделение виртуальной памяти — процесс относительно медленный. Выделение реальной памяти — относительно быстрый. Ещё допускаю, что виртаульной памятю может называться память, выгруженная на диск, но это тоже не корректно.
Кстати, а где это Вы видели чтобы рельная память была больше реальной? Я что-то такого не наблюдал.
Тогда как влияет зоналость привода на воспроизведение DVD в Windows? pgc-то не привод раскодирует. Отсюда имеем что зональность это таки аппаратное кодирование данных на уровне привода. Это первое.
Второе: Где в Windows указывается зона системы? Т.е. вы утверждаете, что выставив страну «США», я смогу играть американские диски не смогу русские? Это не так. А если у меня американская версия Windows без MUI, то я вообще не смогу воспроизводить европейские DVD? Это тоже не так. Отсюда имеем, что в лицензионных дисках зона нигде кроме как для шифрование контента не применяется и не проверяется.
Короче, оба утверждение не имеют никакого отношения к действительности.
Важным показателем расхода в винде является поле «память» — это объём выделенной приложению физической памяти. Куда можно деть 50+ метров я не предсталяю. «Витрулаьная память» — это объём памяи зарезервированной для приложения В большинстве случаев показывает максимальный объём памяти когда-либо распределяемой приложением (Например, при загрузке.). Т.е. если программа выделила себе 50 метров, а потом освобобила 30, то занятая память будет 20 метров, а виртуальная ~50 метров. На объём свободной памяти виртуальная память никак не влияет. Т.ою можно предоположить, то QIP при работе в какие-то моменты исользует до 19 метров ОЗУ.
У вас есть некий DLL являющийся контейнером объекта COM. Этот объект загружен и используется. И тут вы волшебным образом подменяете файл используя волшебную силу inodes. Внимание вопрос — если ещё одно приложение попробует создать этот объект — какая версия будет создана?
Вторая проблема — ресурсы. Ресурсы в Windows загружаются не в момент загрузки приграммы, а по мере использования или по запросу.
Третья проблемма — DLL. У вас есть некая системная DLL, которую использует множетсво приложений. И тут вы её находу заменяете. А потом запускается новое приложение и пытается вручную загрузить ещё один экземпляр этотй DLL. Но это уже другая DLL! А теперь учтите, что у DLL есть методы, вызываемые при первоначальной загрузке, а тут первоначальных загрухок получается две.
Не нужно считать других глупее себя. Просто пример — запустите в Windows любой исполняемый файл. А теперь переименуйте его. Фокус-покус! Файл перименовался! Причём фал не просто продолжает работать, но и может использовать ресурсы. Хотя, следуя логиrе автора быть такого ну, никак не может. Inodes в данном случае заменяет module instance handle. И не важно какая файловая система.
Не нужно считать других глупее себя. Microsoft сознательно отказалась от идеи виртуальной файловой системы ядра, так, как развязывало ей руки в применении множества других перспективных технологий.
Эффективный многоуровневый кэш, эффективная работа с невыровнеными данными, предвыборка команд, предсказание ветвлений, переименование регистров, несколько целочисленных блоков — всего этого нет в ARM. На прикладных задачах, при равной частоте ARM проигрывает современным x86 почти на порядок. Вокруг Cortex-A8 и иже с ними раздуто много шумихи, но дальше прототипов дело пока не идёт. Полный интернет чудо-нетбуков на Cortex показывающих соизмеримую с x86 производительность, но я пока что не видел ни одного сравнения их на серверной платформе на серьёзных задачах. Одно дело странички в браузере открывать и Full HD играть и совсем другое дело — Web/файловы/баз данных сервер.
Учитывая, что за ту же $1000 можно собрать три-четыре Atom/VIA/Geode на частотах >1GHz и памятью каждого ~1GB, то можно получить более производительную систему. А один жалкий Core2Duo на паре-тройке гигагерц покажет ту же производительность, при приципиально меньшей сложности и бОльших возможностях. Короче, очень сомнительно с точки зрения целесообразности.
Это во-первых.
А во-вторых, я уже тут с кем-то на эту тему спорил — в росси действуют любые документы на любых языках если они не противоречат российскому законодательству.
А, вообще, «частная дорога» и «частная собственность» в Америке разные вещи.
и повторяю — виртульная память к жёстким дискам не относится. Она не обязательно сброшена в файл подкачи.
Кстати, а где это Вы видели чтобы рельная память была больше реальной? Я что-то такого не наблюдал.
Второе: Где в Windows указывается зона системы? Т.е. вы утверждаете, что выставив страну «США», я смогу играть американские диски не смогу русские? Это не так. А если у меня американская версия Windows без MUI, то я вообще не смогу воспроизводить европейские DVD? Это тоже не так. Отсюда имеем, что в лицензионных дисках зона нигде кроме как для шифрование контента не применяется и не проверяется.
Короче, оба утверждение не имеют никакого отношения к действительности.