Re: Файл подкачки и фидо-софт
 

Maxim Sokolsky написал(а) к Eugene Muzychenko в Apr 25 22:08:22 по местному времени:

Здpавствуй, Eugene!

MS>> Администратор системы должен понимать, что если он отключит файл
MS>> подкачки и по какой-то неизвестной для него причине свободное ОЗУ
MS>> внезапно закончится, то некоторые процессы вылетят с ошибкой, что
MS>> приведет к [b]внезапной[/b] потере пользовательских данных.

EM> То же самое, внезапно, произойдет, когда файл подкачки достигнет
EM> максимально возможного размера. Разница лишь в вероятности.

Если это произойдет, то не так внезапно, как без файла подкачки.

EM> Если в системе постоянно занята относительно небольшая доля памяти
EM> (как у Чеслава), то добавление файла подкачки эту вероятность
EM> практически не снижает.

Рассуждать о практическом без примеров странно, для ясности нужна конкретная ситуация. Вот допустим, Чеслав запускает некую программу, и случайно у него залипает клавиша Ввод, и нажимается она на неком приложении. Понятно, что ситуация редкая, но это хороший и наглядный пример. В его компьютере 8 GB ОЗУ. Рассмотрим эту ситуацию для 2 конфигураций: с включенным файлом подкачки на SSD с размером 12 Gb (1) и без него (2).
Чеслав вызвает Диспечер задач и пытается завершить плодящиеся процессы.
В каком из двух вариантов - (1) или (2) - у него больше шансов успеть "прибить" программу?

EM> Если же софт регулярно пытается заполнить всю память, независимо от ее
EM> размера, то вероятность опять же не получится заметно снизить.

Если ПО регулярно не хватает памяти, ее нужно расширять, и файл подкачки в таком случае не решение.

MS>> Файл подкачки дает администратору системы возможность исправить
MS>> ситуацию. В случае нехватки ОЗУ, система начинает использовать
MS>> файл подкачки активнее и начинает работать медленнее, поэтому
MS>> данные сразу не теряются. По крайней мере до тех пор, пока не
MS>> исчерпается память файла подкачки.

EM> То есть, об "исправлении ситуации" речи не идет - данные все так же
EM> потеряются.

Здесь тоже вероятность - успеет ли администратор исправить ситуацию или нет. С файлом подкачки время на реакцию есть. Плюс повышается устойчивость и надежность системы в целом, т.к. памяти больше. Плюс после голубых экранов смерти остаются необходимые для последующего разбирательства отладочные данные.

MS>> Администратору в это время приходят смс-ки системы мониторинга,
MS>> начинают звонить рассерженные пользователи и ругаться, что
MS>> система "тормозит". Т.е. у него остается время отреагировать и
MS>> попытаться исправить ситуацию с нехваткой ОЗУ.

EM> Это время у него остается, если файл подкачки лежит на НDD. Если он
EM> лежит на SSD, то тормоза будут заметны только достаточно опытному
EM> пользователю.

Давай ближе к конкретике Чеслава. Скорость записи файлов на SSD грубо около 100 MB/s в среднем. ОЗУ значительно быстрее - где-то 10Gb/s. Запуск нового экземпляра программы требует не только памяти, но времени ЦП, так что заполнение ОЗУ не будет мгновенным. Заполнение файла подкачки также потребует процессорного времени, плюс также одновременно упадет на два порядка скорость записи в виртуальную память.
Успеет ли Чеслав среагировать? Неизвестно. Но в первом случае счет идет на минуты, а втором на секунды, и вероятность успеть гораздо меньше.

EM> Кстати, в какой момент мы незаметно перешли от администрирования
EM> собственной системы, о загрузке которой ее пользователю известно
EM> практически все, к администрированию систем других пользователей?

MS>> Мало ли что в старом коде может быть, что не совместимо с WoW64.

EM> Великолепный по содержательности ответ от человека, претендующего на
EM> понимание работы системы с позиции специалиста и администратора, а не
EM> рядового пользователя. Если уж взял на себя - изволь соответствовать.

А что это ты вдруг высоким штилем заговорил?)

MS>> Ядро не может выполнять 32-битный код.

EM> Надеюсь, ты понимаешь, что оно не может его выполнять вообще никогда,
EM> а не вдруг какие-то его части? И где в тоссере вдруг может встретиться
EM> код ядра?

Не принимай эту цитату так близко к своему пламенному разработческому сердцу.) Ее я привел, чтобы показать, что происходит что-то вроде эмуляции и что среда для исполнения кода имеет ограничения.

EM> Поддержка 16-битного кода была удалена.

EM> Что еще сумеешь высосать из пальца?

А, понятно, высоким штилем - это ты для контраста, чтобы затем перейти на штиль низкий. Захотелось тебе похвалиться перед фидошниками, какой ты умный и опытный. Бывает.) Ничего плохого в этом нет. Но вот эта твоя попытка через оттопыренную губу строить из себя всезнайку при одновременном незнании азов работы твердотельных накопителей выглядит, мягко говоря, просто смешно.

MS>> Если работа идет с [b]отдельными областями[/b] файла, выигрышь в
MS>> скорости может быть весьма значительным

EM> Только при несоответствии структуры ввода/вывода логике работы с
EM> данными. В конечном итоге, это все те же самые операции чтения/записи.
EM> Отображаемые файлы могут лишь как-то спасти ситуацию по сравнению с
EM> неправильно организованными чтением/записью, но никаких чудес сверх
EM> адекватной работы с файлами они совершить не могут.

"А мало ли, друг Горацио, на свете есть различных чудес?")

Как происходит перезапись файлов на SSD ты не знаешь, и это неудивительно. Нет такого человека, которому известно все, поэтому не тешь свое самолюбие напрасно. И действительно, друг Евгений, а что ты знаешь об этом ПО. Ты его код видел? Может, ты разработчик этого тоссера и я в предыдущем письме тебя задел? Иначе, как можно утвержать полное отсутствие чудес? Как можно говорить априори об адекватной работе старой программы в новой операционной системе? Ошибка здесь такая же вероятность, и она отлична от нуля.

EM> Вообще, ты в курсе, что дискутируешь с человеком, который тридцать с
EM> лишним лет пишет под винду все виды кода - пользовательский,
EM> сервисный, ядерный, 64-, 32- и 16-разрядный? Уверен, что стоит
EM> продолжать возражать, черпая информацию из популярной литературы? :)

А я тебя с этим поздравлю. Скажу, что надеюсь, что ты не остановишься на достигутых тобой результатах и еще долгие годы будешь продолжать писать свой код.
Кстати, раз ты уже затронул тему кто есть кто. Я - MCSE, а ты хотя бы как-то сертифицирован Майкрософт как разработчик? Или может быть ты работаешь по принципу: "Зачем нужна эта сертфикация, мое дело написать на коленке код, всучить его заказчику, а дальше - трава не расти!"?)

EM> Я, кстати, даже под 64-разрядными системами предпочитаю 32-разрядный
EM> софт, в том числе очень старый (90-х - начала 2000-х), регулярно и
EM> периодически использую сотни различных приложений, и ни разу не видел,
EM> чтоб 32-разрядное приложение, достаточно надежно работающее в
EM> 32-разрядной системе примерно тех же лет выпуска, вдруг стало
EM> [b]странно_глючить[/b] в более поздней и/или 64-разрядной системе.

EM> MS можно ругать за многое, но в плане совместимости у них реально
EM> титаническая поддержка, в винде давно уже реализовано множество
EM> средств обеспечения совместимости, в них много раз добавлялись способы
EM> обхода выявленных случаев несовместимости - даже когда приложения
EM> использовали недокументированные возможности. MS всегда ставили
EM> совместимость выше эффективности и "чистоты".

О, да, работают люди в корпорации - это заметно. Хотя бы по тому, что через обновление постоянно идет поток разного рода патчей и обновлений с исправленими ошибок и уязвимостей.

EM> Если у приложения есть явная несоместимость по версиям DLL,
EM> импортируемым функциям, названиям/расположениям служебных каталогов,
EM> правам доступа и т.п., то они или сразу не работают совсем, или так же
EM> сразу начинают серьезно глючить. Нужно очень сильно постараться, чтобы
EM> [b]ненамеренно[/b] изготовить приложение, которое будет странно глючить в
EM> будущих системах, или системах бОльшей разрядности. Разумеется,
EM> вероятность этого есть, но об этом имеет смысл думать не раньше, чем
EM> отвергнуты все более вероятные объяснения. Начинать с таких
EM> предположений - явный признак некомпетентности.
EM> Не веди себя, как типичная девочка в техподдержке - "удалите куки,
EM> перезагрузитесь, переустановите систему...". :)

Вот спасибо тебе большое - ты сейчас и разъяснил, и почему-то решил похвалиться своим богатым опытом, и сыграть в детскую игру "Я здесь самый умный", и зачем-то наставления другим начал раздавать. Ты школьный учитель информатики, что ли, и у тебя так профессиональная деформация проявляется?) Возможно, в некоторых вопросах, связанных с разработкой, ты действительно что-то понимаешь, но видно, что в администрировании ты не знаешь ни бельмеса, и твой опыт в этой области не выходит за пределы настройки собственного рабочего компьютера и нескольких серверов для тестов.

Ладно, можешь особенно не извиняться за свое незнание. Это бывает часто: все не знают всего. Главная твоя проблема не в том, что ты что-то не знаешь, а в твоих закостенелых и устаревших представлениях, которые одновременно с твоим чванливым самомнением мешают тебе учиться новому.

С уважением - Maxim
--- -Да, да!.. Я вижу, вы поняли мой замысел.

Re: Файл подкачки и фидо-софт
 

Maxim Sokolsky написал(а) к Oleg Redut в Apr 25 22:11:10 по местному времени:

Здpавствуй, Oleg!

EM>>> виртуальной памяти провоцирует какой-то софт (в том числе
EM>>> системный) использовать ее экстенсивно.

MS>> Догадка в правильном направлении.) Только не большой объем памяти
MS>> провоцирует какое-то ПО использовать его, а наоборот -
MS>> пользовательское ПО так устроено, что изначально использует ее
MS>> экстенсивно.

OR> Для топикстартера, видимо, важно, чтобы своп на ssd не юзался
OR> интенсивно, уменьшая ресурс железа. А если экстенсивно, то это менее
OR> страшно.

"Системный монитор" ему в руки, два счетчика из раздела "Файл подкачки" - %использования pagefile.sys и % пик его же использования. Если большую часть времени (90% за сутки) на графике две горизонтальные линии - значит, файл подкачки почти не меняется.

Если он почти не меняется, то почему держать файл подкачки на SSD это плохо? Это какая-то мифология, прямо-таки религиозный культ. И похоже, у него есть многочисленные адепты, которые регулярно посещают Храм Живоначальной Матрицы и участвуют в обряде 'Неразмещения Свопа На SSD'. Следующий этап в данном направлении - это приглашение попа в серверную для окропления оборудования святой водой.

С уважением - Maxim
--- -Да, да!.. Я вижу, вы поняли мой замысел.

Re: Файл подкачки и фидо-софт
 

Maxim Sokolsky написал(а) к Cheslav Osanadze в Apr 25 22:14:02 по местному времени:

Здpавствуй, Cheslav!

CO>>> Я пока не определился, где глюк. Не торопливый я... Только
CO>>> локализовал, что точно на пуржинге.

CO>>> А далее - буду проверять все базы.:)

MS>> Глюки могут быть, т.к. Windows 64-разрядная, а приложение старое
MS>> и 32-битное. Если тебе эта программа нравится и для тебя важна
MS>> надежность ее работы, скачай Oracle VirtualBox и запускай ее в
MS>> отдельной виртуальной машине со старой 32-битной Windows.

CO> Нашёл битые базы, только не понял - почему такой странный вывод
CO> ошибки на экран и без вывода ошибки в лог. Может, как то хитро база
CO> сломалась, что тоссер не придумал - что ещё написать про это.:)

Тебе нужно разобраться, из-за чего базы побились. Если это произошло в процессе их переноса/копирования, тоссер здесь не причем. Не было ли сбоя электичества - это также может быть причиной. Если же ошибки записи возникли по время работы тоссера, см. выше. Это хорошая рекомендация - запускать старые программы в родной для них среде. Так гарантированно можно избежать хождения по граблям.

Насчет SSD добавлю, что кроме включенного TRIM, еще важно следить, чтобы диски SSD не заполнялись под завязку. Если свободного пространства <20%, деградация накопителя ускоряется.

С уважением - Maxim
--- -Да, да!.. Я вижу, вы поняли мой замысел.

Файл подкачки и фидо-софт
 

Cheslav Osanadze написал(а) к Maxim Sokolsky в Apr 25 21:49:30 по местному времени:

Привет Maxim!

24 Апр 25 22:14, Maxim Sokolsky -> Cheslav Osanadze:


CO>>>> А далее - буду проверять все базы.:)

MS>>> Глюки могут быть, т.к. Windows 64-разрядная, а приложение
MS>>> старое и 32-битное. Если тебе эта программа нравится и для тебя
MS>>> важна надежность ее работы, скачай Oracle VirtualBox и запускай
MS>>> ее в отдельной виртуальной машине со старой 32-битной Windows.

CO>> Нашёл битые базы, только не понял - почему такой странный вывод
CO>> ошибки на экран и без вывода ошибки в лог. Может, как то хитро
CO>> база сломалась, что тоссер не придумал - что ещё написать про
CO>> это.:)

MS> Тебе нужно разобраться, из-за чего базы побились.

Разумеется.

MS> Если это произошло в
MS> процессе их переноса/копирования, тоссер здесь не причем.

Вполне возможно, что я допустил это своими ручками и программы вообще никакие не при чём.:)
Меня сам вывод на экран - сбил с толку.

MS> Не было ли
MS> сбоя электичества - это также может быть причиной. Если же ошибки
MS> записи возникли по время работы тоссера, см. выше. Это хорошая
MS> рекомендация - запускать старые программы в родной для них среде. Так
MS> гарантированно можно избежать хождения по граблям.

MS> Насчет SSD добавлю, что кроме включенного TRIM, еще важно следить,
MS> чтобы диски SSD не заполнялись под завязку. Если свободного
MS> пространства <20%, деградация накопителя ускоряется.

Такое, вроде, не допускаю.


Cheslav.


... Женщины - жить с ними нельзя и пристрелить жалко.
---

Файл подкачки и фидо-софт
 

Eugene Muzychenko написал(а) к Maxim Sokolsky в Apr 25 09:39:37 по местному времени:

Привет!

24 Apr 25 21:56, you wrote to me:

EM>> Осталось понять, какое TRIM может иметь отношение к работе с
EM>> файлом подкачки,

MS> К операциям записи любых файлов.

Нет, давай-ка сперва разберемся с файлом подкачки. Сказал "А" - говори и "Б".

MS> И для начала тебе нужно знать азы - как работают SSD, а уже потом
MS> рассуждать про TRIM.

Азы я знаю, а рассуждать про TRIM начал ты, я тебя за язык не тянул. Но теперь тяну - будь добр, выскажись по существу.

EM>> файл подкачки с момента создания лежит на одном месте,

MS> Не на одном месте.

В терминах логических блоков - на одном.

MS> Для выравнивания износа в SSD перезапись данных производится в разные
MS> физические блоки. Я тебе сейчас Америку открою: этим занимаетя
MS> контроллер накопителя

Спасибо, кэп, я как бы в курсе. Но это, во-первых, ничем не гарантировано, а во-вторых, разные контроллеры применяют разные алгоритмы, уделяют этим вопросам разное внимание и т.п. Только TRIM гарантирует, что контроллер хотя бы примет во внимание освобождение логических блоков. На то, что использования подкачки на SSD не стоит опасаться именно потому, что там есть TRIM, начал напирать именно ты. Вот я и прошу тебя продолжить эту логическую цепочку, а не переобуваться на ходу.

MS> Т.е. по-твоему постоянная перезапись данных файла подкачки портит одни
MS> и те же блоки памяти

А это в общем случае неизвестно. Известно или для определенных моделей контроллеров, или в случаях конкретного наблюдения за их работой через средства диагностики. А втирать всем "контроллеры нынче все поголовно умные, ничего не бойтесь, они все сделают за вас" - это примерно как "если ваш любимый антивирус не счел исполняемый файл подозрительным, то смело запускайте, невзирая на то, откуда он к вам попал". :)

MS> не думаешь ли ты, что в SSD имеются ферромагнитные пластины, головки и
MS> шпиндель?

Я думаю, что ты совершенно не умеешь определять интеллектуальный и образовательный уровень собеседника.

Всего доброго!
Евгений Музыченко
fi-do@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20180707

Файл подкачки и фидо-софт
 

Eugene Muzychenko написал(а) к Maxim Sokolsky в Apr 25 10:35:49 по местному времени:

Привет!

24 Apr 25 22:08, you wrote to me:

EM>> То же самое, внезапно, произойдет, когда файл подкачки достигнет
EM>> максимально возможного размера. Разница лишь в вероятности.

MS> Если это произойдет, то не так внезапно, как без файла подкачки.

Степень внезапности будет зависеть исключительно от общего объема виртуальной памяти, предоставляемого системой, и никак не будет зависеть от наличия или отсутствия в этой системе файла подкачки.

MS> Рассуждать о практическом без примеров странно, для ясности нужна
MS> конкретная ситуация.

Чеслав уже обрисовал тебе конкретную ситуацию, из которой явно следует, что физической памяти, при его потребностях, его [b]личная_ система имеет в избытке. Но ты уперся, и стал рассказывать про абстрактных _корпоративных[/b] пользователей, которые пользуются не тем, что нужно лично им, а тем, что им дали по работе, и которым систему настраивают корпоративные же админы.

MS> Вот допустим, Чеслав запускает некую программу, и случайно у него
MS> залипает клавиша Ввод

С какой частотой в среднем залипает клавиша "ввод"? У меня она за сорок с лишним лет, на десятках клавиатур, не залипала ни разу. Пару раз за все это время залипали пробелы - из-за нещадного по ним колочения. По-твоему, мне следует что-то перестроить в своих системах, дабы подготовиться к третьему возможному залипанию, буде таковое случится?

MS> Понятно, что ситуация редкая, но это хороший и наглядный пример.

Именно потому, что [b]понятно[/b], что ситуация редкая, это будет не хорошим наглядным примером, а убогим примером, изо всех сил высосанным из пальца исключительно для того, чтобы хоть как-то подпереть свою позицию, которую чем-то более солидным подпереть не выходит.

MS> Чеслав вызвает Диспечер задач и пытается завершить плодящиеся
MS> процессы. В каком из двух вариантов - (1) или (2) - у него больше
MS> шансов успеть "прибить" программу?

В любом. Если тебя это удивляет, то это еще один намек на то, что ты ввязался в спор не на своем образовательном уровне.

MS> Если ПО регулярно не хватает памяти, ее нужно расширять, и файл
MS> подкачки в таком случае не решение.

А если регулярно хватает физической памяти, то удаление файла подкачки - вполне разумное решение для мало-мальски грамотного пользователя (полных нубов в расчет не берем, да они об этом и не думают).

MS> успеет ли администратор исправить ситуацию или нет.

Кого ты называешь "администратором" в конкретном обсуждаемом случае?

MS> С файлом подкачки время на реакцию есть.

Время на реакцию не зависит от наличия/отсутствия файла подкачки. Ты можешь в этом убедиться сам, если не поленишься.

MS> повышается устойчивость и надежность системы в целом, т.к. памяти
MS> больше.

Сомнительное утверждение. Большее количество памяти с тем же успехом может отсрочить возникновение проблем до момента, когда за пультом никого не будет - ночью или во время отлучки.

MS> после голубых экранов смерти остаются необходимые для последующего
MS> разбирательства отладочные данные.

Поэтому я и говорил, что достаточно такого объема файла подкачки, который вмещает желательный тип аварийного дампа. Для минидампа это 16 Мб.

MS> Успеет ли Чеслав среагировать?

Чтобы ответить на этот вопрос, необходимо для начала понять, какой цели должна достичь его реакция.

MS>>> Ядро не может выполнять 32-битный код.

MS> Ее я привел, чтобы показать, что происходит что-то вроде эмуляции

Ничего похожего на эмуляцию в отношении кода ядра не происходит. Происходит непонимание тобой вещей, о которых ты взялся уверенно говорить.

MS> Захотелось тебе похвалиться перед фидошниками, какой ты умный и
MS> опытный.

Мне хвалиться без нужды. Я б тебе вообще не отвечал, будь это личная переписка, никому более не видимая. Но ты с уверенным видом делаешь ложные утверждения, которые многие, не имеющие должной образованности, сочтут за истину. Вот и приходится писать ответы, чтобы это хоть как-то уравновесить.

MS> Я - MCSE

Тем хуже для репутации этого сертификата.

Всего доброго!
Евгений Музыченко
fi-do@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20180707

Файл подкачки и фидо-софт
 

Cheslav Osanadze написал(а) к Eugene Muzychenko в Apr 25 12:53:45 по местному времени:

Привет Eugene!

25 Апр 25 10:35, Eugene Muzychenko -> Maxim Sokolsky:

MS>> Рассуждать о практическом без примеров странно, для ясности нужна
MS>> конкретная ситуация.

EM> Чеслав уже обрисовал тебе конкретную ситуацию, из которой явно
EM> следует, что физической памяти, при его потребностях, его [b]личная[/b]
EM> система имеет в избытке.

Вот так оно работает.

[url]http://pics.rsh.ru/img/[b]2025-04-25_125324411[/b]g35d9xc9.png[/url]

...

MS>> после голубых экранов смерти остаются необходимые для
MS>> последующего разбирательства отладочные данные.

EM> Поэтому я и говорил, что достаточно такого объема файла подкачки,
EM> который вмещает желательный тип аварийного дампа. Для минидампа это 16
EM> Мб.

При настройки файла "в ноль", система об этом явно предупреждает.



Cheslav.


... Между ними были трения на сексуальной почве.
---

Файл подкачки и фидо-софт
 

Eugene Muzychenko написал(а) к Cheslav Osanadze в Apr 25 15:33:16 по местному времени:

Привет!

25 Apr 25 12:53, you wrote to me:

CO> Вот так оно работает.

Беда в том, что все эти счетчики показывают только объем, занятый в файле подкачки, и не показывают фактический дисковый обмен, который происходит внутри самого файла (то есть, какие страницы туда пишутся, и читаются оттуда, кому они принадлежат и т.п.). Эти операции идут напрямую драйверам дисков, минуя драйверы файловых систем, поэтому мониторы вроде Process Monitor их не показывают, а чтобы выделить их на фоне всего дискового обмена, нужно знать, в каких логических блоках размещен файл подкачки. Утилит, которые это показывают в удобном виде, я никогда не видел, а заниматься вручную было лень.

Всего доброго!
Евгений Музыченко
fi-do@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20180707

Файл подкачки и фидо-софт
 

Cheslav Osanadze написал(а) к Eugene Muzychenko в Apr 25 16:02:01 по местному времени:

Привет Eugene!

25 Апр 25 15:33, Eugene Muzychenko -> Cheslav Osanadze:

CO>> Вот так оно работает.

EM> Беда в том, что все эти счетчики показывают только объем, занятый в
EM> файле подкачки, и не показывают фактический дисковый обмен,

Не-не-не! Тут файл подкачки отключён! Т.е. совсем. Как видим, нагрузка на память минимальная, не смотря на запуск браузера и тоссера. Вся нагрузка падает на процессор.




Cheslav.


... Какой быстрый ездок не любит "Рyсской"!
---

Re: Файл подкачки и фидо-софт
 

Maxim Sokolsky написал(а) к Cheslav Osanadze в Apr 25 20:46:52 по местному времени:

Здpавствуй, Cheslav!

CO>>> Нашёл битые базы, только не понял - почему такой странный вывод
CO>>> ошибки на экран и без вывода ошибки в лог. Может, как то хитро
CO>>> база сломалась, что тоссер не придумал - что ещё написать про
CO>>> это.:)

MS>> Тебе нужно разобраться, из-за чего базы побились.

CO> Разумеется.

MS>> Если это произошло в процессе их переноса/копирования, тоссер здесь
MS>> не причем.

CO> Вполне возможно, что я допустил это своими ручками и программы вообще
CO> никакие не при чём.:) Меня сам вывод на экран - сбил с толку.

Он говорит о нескольких возможных причинах ошибки, и отключение файла подкачки - только одна из них. Список ошибки "Память не может быть read" см. здесь:

[url]https://remontka.pro/memory-cannot-be-read/[/url]

и он неполон, но самые распространенные причины в нем указаны.

С уважением - Maxim
--- -Да, да!.. Я вижу, вы поняли мой замысел.