И чем это отличается от обычной загрузки операционной системы?
Не знаю, я у вас пытаюсь выяснить, если разницы нигде и ни в чем нет, то почему работа при большом количестве памяти это преимущество только новых ОС? Старые точно такие же преимущества получают. Ну да, нужно им немного помочь, потому что время ушло и никто в них не написал такую поддержку нативно, хоть даже в виде workaround-а, которым помещение на RAM диск является.
Если система дырявая как решето, какая вообще разница что там запускается а что нет, ценности она не представляет ни в каком виде.
Это как-то противоречит всенародно любимому статусу, который приобрели некоторые ОС. Если такое решето, что ж на них сидели десятки лет после EOL, а не бежали на новые системы?
Ничего не мешает и никто не запрещает, но ведь не пойдете же.
Так что же получается, вообще ничего не запускать, ведь еще столько неоткрытых уязвимостей и каждый день новых досыпают!
чтобы запустить ОС полностью с рам диска надо все 6-7 гб сначала скопировать в ram диск, а только потом начинать запуск самой ОС.
Ну, как бы не обязательно. Если у нас и так загрузчик, который копирует с диска в RAM, что мешает ему скопировать нужное для запуска и начать запуск, а параллельно наполнять память оставшейся частью.
Кроме того, ОС то не понимает что она на рам диске. И все файлы оттуда будет копировать еще раз в RAM, уже не так критично но абсолютно бесполезно.
Ну пусть копирует. Это все равно меньше на порядок, чем 11 винде копировать свои ужасно важные 12 Гб с диска в память. Не удивлюсь, если умный контроллер памяти вообще ничего по факту копировать не будет, а просто пометит у себя, что двум виртуальным адресам одно и то же место физически соответствует...
Во втором случае сначала загрузится ядро, потом откроется рабочий стол и вы уже можете начинать работать пока в фоне там догружается и кешируется все остальное.
Ну прямо же в статье говорилось, что рабочий стол зависит от кучи компонентов и загрузить нужно много всего, пока вы сможете там как-то работать.
Ну поставьте, с удовольствием послушаю что получилось..
Вы как будто не читали то, что следующей строкой цитируете.
Да их в общем то и для ДОС тоже собрать можно.
Наверное можно, только это будет уже не программа для ДОС, ДОС там скорее всего проще выкинуть будет, чем что-то из нее заимствовать.
В целом вот тут неплохо объяснено
В каких-то единичных случаях так и работает, когда к делу подходят люди, которые работали в эпоху дефицита памяти. Но в 80% потребляет больше памяти = и не думали об оптимизации.
А в чем смысл тут сейчас воображать как бы там было бы если бы ХР была бы безопаснее бы (12 лет не получая security обновлений)?
При чем тут обновления безопасности? Это что-то новенькое, что незапускаемая программа из-за них вдруг становится запускаемой. Может пример есть какой? Обычно наоборот бывает
Если вы считаете что ХР не имеет уязвимостей
Я так не говорил и не считаю, но я не понимаю, какие такие уязвимости мешают вам запускать программы. Как раз наоборот, патчение уязвимостей обычно запрещает запускать что-то не то, а не разрешает. Приведите хоть один пример обратного.
Тогда почему за эталон берется XP а не 95 или дос?
ДОС слишком примитивная и многими за ОС не считается вообще, а нестабильность 95 стала притчей во языцах. XP же завоевала народную любовь не просто так. Поэтому и сравнивать логично с ней.
Copilot, Sandbox, WSL, Hyper-V, BitLocker, Windows Store, OneDrive, PowerShell, Defender.
То есть просто расширенный набор программ, которые еще не во всех редакциях есть, и ничего не мешает их на XP поставить (если бы задались целью их собрать для нее, конечно). Что им все нужно именно от ОС такого, чего нет у XP, непонятно.
Где я писал про долгий запуск без какого либо профита?
Ну как бы вот:
К слову, вы переоцениваете пользу от RAM диска, ОС и так умеет кешировать файлы в памяти - вы просто получите более долгий запуск
Кстати, не вижу, почему запуск должен быть дольше, чем у 11 винды. Загрузить XP в память - это 7 Гб, а 11-й нужно загрузить 12 Гб. 7 явно загрузятся быстрее, чем 12.
Вы сами то пробовали так делать? Я - да, если что. Не получите вы никаких плюсов
Нет, не пробовал. Ну если от ускорения к файлам на диске на порядок нет никакого профита, то почему вы говорите
Только он не понимает что там где в процессе работы условные ХП или ДОС будет по полминуты жестким диском трещать
Неправда, получается? Не будет шуршать?
Очень просто - если на том что занимает 800 мб я не могу запустить требуемые приложения по причине проблем с безопасностью и отсутствием необходимой функциональности, то очевидно что даже эти 800мб на все 100% неэффективны и бесполезны.
А если не можете запустить на 12 Гб по причинам "проблем с безопасностью" (что это за причины такие?), а на 800 Мб можете, то что тогда получается? 800 Мб эффективны, а 12 Гб нет?
и отсутствием необходимой функциональности
Боюсь, во многих случаях по этому параметру старые программы выигрывают. Во всяком случае уж деградацию настроек в винде кто только не пинал.
Вряд ли он может автоматизировать больше 80%, согласно известному принципу. А если автоматизирует самую сложную часть работы, то и вовсе, это только 20%.
Как и между XP и 95 например, чем оправданы 800мб RAM и 6-7Гб на диске?
Ничем, я же и говорю.
А в 1981 на одну дискету меньше мегабайта умещалась. Тоже простое наблюдение.
Да. Но все-таки возможностей там было объективно меньше, чем в XP. Автоматически устройства не настраивались, графики никакой, нет многозадачности и изоляции процессов. А между XP и 11 какие различия? Копилот встроенный, которые 1.5 человека запустят 1.5 раза?
ОС и так умеет кешировать файлы в памяти - вы просто получите более долгий запуск
Это ответ на ваше предложение:
Только он не понимает что там где в процессе работы условные ХП или ДОС будет по полминуты жестким диском трещать, на современных ос все сработает мгновенно из кеша.
Если получаем более долгий запуск без какого-либо профита, то почему вы преподносите это как плюс Windows 11? Я вам и говорю -- поставьте всю XP в RAM, и она те же самые плюсы получит + еще место останется.
Если оперативная память свободна, какой смысл держать ее максимально пустой?
Экономить электроэнергию? Не максимально пустой, но и лишнее зачем туда пихать? Тем более
ОС и так умеет кешировать файлы в памяти
Сравнивать то надо не кто меньше памяти потребляет, а кто эффективнее ей управляет. Заполненность сама по себе не показывает вообще ничего.
Кто эффективнее: тот, у кого необходимые компоненты занимают 800 Мб (6-7 Гб, если вообще полностью в RAM) или тот, у кого 12 Гб? Как вы меряете эту эффективность?
поскольку несколько гигабайт памяти вместо кеша или полезной нагрузки будет занято тем что точно ни одному приложению или сервису не понадобится
Зачем нам кешировать то, что и так лежит в RAM (т.е. в том же самом кеше)? Это просто бесполезное задвоение информации. И среди 12 Гб у Windows 11 наверняка 10 точно ни одному приложению или сервису не понадобится
Вот видите. Простое наблюдение: в 2001 году ВСЯ операционная система занимала 6-7 Гб, а 20 лет спустя 10+ Гб -- это только какой-то кусочек, который всем непременно потребуется прямо вот щщщас? Что-то незаметно в декстопе таких прорывов, которые бы это оправдывали. Установите систему на RAM диск, и XP будет летать еще шустрее, чем 11, в меньшем объеме памяти.
Ну это все же значит, что со старта в памяти 10Гб+ какого-то мусора, которого не было в 2001 году. Что это все такое? Фильмы в FullHD? Ну не триллионы же инструкций кода, там все написанное человечеством ПО сразу в память что ли загружают?
Стандарт об этом ничего не говорит, они часть перемещенного объекта и следовательно, там случайное значение.
Но в реальном коде такого не может быть.
К сожалению, компилятор не может полагаться на статистику и рейтинги говнокодости. В реальности и исключения в при выполнении конструкторов кидаются редко (а из move конструкторах и того реже), но за exception safety почему-то топят.
но сам по себе вызов move ничего не портит
Так никто и не утверждает, что портит move. Испортить может Base(Base&&), а компилятор может не видеть, что в теле этого конструктора делается.
Кстати, с помощью CRTP базовый класс вполне может легально пользоваться полями унаследованного и никто ничего плохого в этом паттерне не видит.
пока в конструкторе Derived не берутся данные из базового класса.
Они и не берутся
И компилятору не нужно ничего различать.
Компилятор в принципе и ошибки не обязан вам объяснять, достаточно просто сказать, что что-то не так. А в 2026 ожидаешь от компилятора помощи, а не насмешек по поводу недостаточно полного знания талмуда.
Не move меняет состояние объекта, а конструктор.
Об этом никто и не спорит
Derived(Derived&& other)
// Вызов Base(&&) меняет состояние other
// теперь там неизвестно что
: Base(std::move(other))
// берем из неизвестно чего
, derived_data_(std::move(other.derived_data_))
Осмысленно использовать b затруднительно исключительно потому, что мы не знаем, какое в нем после этого лежит значение.
Вот именно. Но ведь в качестве идеоматического подхода реализации конструктора Derived(Derived&&) нам именно это и предлагают сделать. Сомневаюсь, что хоть в каком-то месте это будет удовлетворительное поведение
Как функция базового класса может что-то сделать с полем, определенном в производном классе?
static_cast / dynamic_cast / вызов виртуального метода у other?
Физически. А логически очень даже перемещен, иначе зачем функция называется move? По-приколу?
Например, после a = std::move(b); в b может оказаться значение, бывшее до присваивания в a - если поменять значения местами дешевле, чем создать пустое значение.
И что вы будите дальше с этим делать? Вот представьте, что в a чувствительные данные, вы правда хотите организовать их утечку через b? Поэтому использовать b после этого -- плохой тон.
Она получает ссылку на базовый класс, и не может ничего сделать с полями производного класса.
Кто вам сказал? Нет никаких запретов на то, что может делать функция.
Не обязательно пустой. В неизвестном валидном состоянии.
То есть в случайном
Можно использовать, если нам не важно, что в нем.
Но в данном случае-то важно. Если не важно, зачем вообще в конструкторе Derived из него данные брать?
Ничего не заканчивает
Тогда бы состояние объекта не менялось, а оно меняется
Никак не помечает
То, что он вам об этом не сообщает, не значит, что этого не делает. Как вы отличите объект в неспецифицированном состоянии от объекта в специфицированном? А если различать не нужно, то зачем вообще вводить это состояние?
Ну так после передачи "в функцию, принимающую rvalue ссылку" здесь объекта больше нет. Он перемещен в эту функцию. Даже если она пустая (а в общем случае компилятор не знает, что внутри функции -- брала она данные из объекта или не брала), логически-то объект после этого пустой. И использовать его после этого -- ну, дурно пахнет.
Объект помечается как rvalue
Ну так я так и говорю:
Но навешивает флаг,
Передача объекта с флагом заканчивает его (время жизни? Не совсем, он же не разрушается. Скажем, "полезность") в точке передачи, после передачи компилятор помечает его перемещенным.
Ну он может и лучший, но такой дорогой, зараза, что чуть менее лучший, но зато кратно дешевый, уделывает его по всем остальным статьям.
Не знаю, я у вас пытаюсь выяснить, если разницы нигде и ни в чем нет, то почему работа при большом количестве памяти это преимущество только новых ОС? Старые точно такие же преимущества получают. Ну да, нужно им немного помочь, потому что время ушло и никто в них не написал такую поддержку нативно, хоть даже в виде workaround-а, которым помещение на RAM диск является.
Это как-то противоречит всенародно любимому статусу, который приобрели некоторые ОС. Если такое решето, что ж на них сидели десятки лет после EOL, а не бежали на новые системы?
Так что же получается, вообще ничего не запускать, ведь еще столько неоткрытых уязвимостей и каждый день новых досыпают!
Ну, как бы не обязательно. Если у нас и так загрузчик, который копирует с диска в RAM, что мешает ему скопировать нужное для запуска и начать запуск, а параллельно наполнять память оставшейся частью.
Ну пусть копирует. Это все равно меньше на порядок, чем 11 винде копировать свои ужасно важные 12 Гб с диска в память. Не удивлюсь, если умный контроллер памяти вообще ничего по факту копировать не будет, а просто пометит у себя, что двум виртуальным адресам одно и то же место физически соответствует...
Ну прямо же в статье говорилось, что рабочий стол зависит от кучи компонентов и загрузить нужно много всего, пока вы сможете там как-то работать.
Вы как будто не читали то, что следующей строкой цитируете.
Наверное можно, только это будет уже не программа для ДОС, ДОС там скорее всего проще выкинуть будет, чем что-то из нее заимствовать.
В каких-то единичных случаях так и работает, когда к делу подходят люди, которые работали в эпоху дефицита памяти. Но в 80% потребляет больше памяти = и не думали об оптимизации.
При чем тут обновления безопасности? Это что-то новенькое, что незапускаемая программа из-за них вдруг становится запускаемой. Может пример есть какой? Обычно наоборот бывает
Я так не говорил и не считаю, но я не понимаю, какие такие уязвимости мешают вам запускать программы. Как раз наоборот, патчение уязвимостей обычно запрещает запускать что-то не то, а не разрешает. Приведите хоть один пример обратного.
ДОС слишком примитивная и многими за ОС не считается вообще, а нестабильность 95 стала притчей во языцах. XP же завоевала народную любовь не просто так. Поэтому и сравнивать логично с ней.
То есть просто расширенный набор программ, которые еще не во всех редакциях есть, и ничего не мешает их на XP поставить (если бы задались целью их собрать для нее, конечно). Что им все нужно именно от ОС такого, чего нет у XP, непонятно.
Ну как бы вот:
Кстати, не вижу, почему запуск должен быть дольше, чем у 11 винды. Загрузить XP в память - это 7 Гб, а 11-й нужно загрузить 12 Гб. 7 явно загрузятся быстрее, чем 12.
Нет, не пробовал. Ну если от ускорения к файлам на диске на порядок нет никакого профита, то почему вы говорите
Неправда, получается? Не будет шуршать?
А если не можете запустить на 12 Гб по причинам "проблем с безопасностью" (что это за причины такие?), а на 800 Мб можете, то что тогда получается? 800 Мб эффективны, а 12 Гб нет?
Боюсь, во многих случаях по этому параметру старые программы выигрывают. Во всяком случае уж деградацию настроек в винде кто только не пинал.
Вряд ли он может автоматизировать больше 80%, согласно известному принципу. А если автоматизирует самую сложную часть работы, то и вовсе, это только 20%.
Ничем, я же и говорю.
Да. Но все-таки возможностей там было объективно меньше, чем в XP. Автоматически устройства не настраивались, графики никакой, нет многозадачности и изоляции процессов. А между XP и 11 какие различия? Копилот встроенный, которые 1.5 человека запустят 1.5 раза?
Это ответ на ваше предложение:
Если получаем более долгий запуск без какого-либо профита, то почему вы преподносите это как плюс Windows 11? Я вам и говорю -- поставьте всю XP в RAM, и она те же самые плюсы получит + еще место останется.
Экономить электроэнергию? Не максимально пустой, но и лишнее зачем туда пихать? Тем более
Кто эффективнее: тот, у кого необходимые компоненты занимают 800 Мб (6-7 Гб, если вообще полностью в RAM) или тот, у кого 12 Гб? Как вы меряете эту эффективность?
Зачем нам кешировать то, что и так лежит в RAM (т.е. в том же самом кеше)? Это просто бесполезное задвоение информации. И среди 12 Гб у Windows 11 наверняка 10 точно ни одному приложению или сервису не понадобится
Вот видите. Простое наблюдение: в 2001 году ВСЯ операционная система занимала 6-7 Гб, а 20 лет спустя 10+ Гб -- это только какой-то кусочек, который всем непременно потребуется прямо вот щщщас? Что-то незаметно в декстопе таких прорывов, которые бы это оправдывали. Установите систему на RAM диск, и XP будет летать еще шустрее, чем 11, в меньшем объеме памяти.
*мошен
никосодержащийИзвините
Пылесос тоже перебрасывает из одного в другое, чуть более замкнутое. На 90% это никак не тянет. Просто технологический совок.
И на какие же 90% функционал пылесоса отличается от метлы?
Ну это все же значит, что со старта в памяти 10Гб+ какого-то мусора, которого не было в 2001 году. Что это все такое? Фильмы в FullHD? Ну не триллионы же инструкций кода, там все написанное человечеством ПО сразу в память что ли загружают?
И две цифры 2 на первой картинке, причем ни та, ни другая не соответствуют цифре 2 в тексте... Короче говоря, шелуха какая-то
Стандарт об этом ничего не говорит, они часть перемещенного объекта и следовательно, там случайное значение.
К сожалению, компилятор не может полагаться на статистику и рейтинги говнокодости. В реальности и исключения в при выполнении конструкторов кидаются редко (а из move конструкторах и того реже), но за exception safety почему-то топят.
Так никто и не утверждает, что портит
move. Испортить можетBase(Base&&), а компилятор может не видеть, что в теле этого конструктора делается.Кстати, с помощью CRTP базовый класс вполне может легально пользоваться полями унаследованного и никто ничего плохого в этом паттерне не видит.
Они и не берутся
Компилятор в принципе и ошибки не обязан вам объяснять, достаточно просто сказать, что что-то не так. А в 2026 ожидаешь от компилятора помощи, а не насмешек по поводу недостаточно полного знания талмуда.
Об этом никто и не спорит
Вот именно. Но ведь в качестве идеоматического подхода реализации конструктора
Derived(Derived&&)нам именно это и предлагают сделать. Сомневаюсь, что хоть в каком-то месте это будет удовлетворительное поведениеstatic_cast/dynamic_cast/ вызов виртуального метода уother?Физически. А логически очень даже перемещен, иначе зачем функция называется
move? По-приколу?И что вы будите дальше с этим делать? Вот представьте, что в
aчувствительные данные, вы правда хотите организовать их утечку черезb? Поэтому использоватьbпосле этого -- плохой тон.Кто вам сказал? Нет никаких запретов на то, что может делать функция.
То есть в случайном
Но в данном случае-то важно. Если не важно, зачем вообще в конструкторе
Derivedиз него данные брать?Тогда бы состояние объекта не менялось, а оно меняется
То, что он вам об этом не сообщает, не значит, что этого не делает. Как вы отличите объект в неспецифицированном состоянии от объекта в специфицированном? А если различать не нужно, то зачем вообще вводить это состояние?
Ага, его еще очень практиковали в средние века, используя серебристые и желтые кругляшки.
Который к тому же описан неправильно. Ни в одном из примеров, где получается двузначное число в левой столбце, не происходит двукратного умножения:
А если бы это и работало, то по описанию непонятно, подсчет цифр нужно делать до того, как откинем дробную часть или после.
Ну так после передачи "в функцию, принимающую rvalue ссылку" здесь объекта больше нет. Он перемещен в эту функцию. Даже если она пустая (а в общем случае компилятор не знает, что внутри функции -- брала она данные из объекта или не брала), логически-то объект после этого пустой. И использовать его после этого -- ну, дурно пахнет.
Ну так я так и говорю:
Передача объекта с флагом заканчивает его (время жизни? Не совсем, он же не разрушается. Скажем, "полезность") в точке передачи, после передачи компилятор помечает его перемещенным.