Черный экран в тех местах где игра переключается на 320x240.
Ничего не написал про монитор, но от него у меня «чуть глаза не вытекли», я почти сразу убрал его и поставил старенький квадратный ЖК 17"
Прошу прощения, но какой ЖК 17" поддерживал бы режим 320х240? У меня завалялись несколько старых 15", но они минимум 640х480 обеспечивают, да и то я в этом не уверен.
Были мучения… У меня знакомый купил 386-40, а играть в WC на нем не смог. Но у меня тут как раз рояль в кустах завалялся — я для себя эту утилиту для тех же целей писал. Привез ему, поставил — все захлопали в ладоши.
Кстати, хотел как-то зарубиться в DT через DOSBox. То ли версия неудачно ломанная, то ли она через DOSBox принципиально не идет — вылетает в момент активации оружия, т.е, на первом же повороте.
Учитывая то, что многие игры были к тактовому генератору привязаны, даже на старших 386 они уже летали с такой скоростью, что играть было затруднительно.
А что значит «на старших 386»?
Многие игры были расчитаны на PC XT/AT с частотой процессора 8 МГц. Например, «Digger». При попытке запустить ее на AT-386/25 или AT-386/40 скорость была такая, что даже не успевали среагировать — от края до края экрана копатель проезжал за секунду.
Для игры в Wing Commander я написал на ассемблере специальную резидентную утилиту. По нажатию на определенную горячую комбинацию клавиш она переводила исполнение в режим отладчика, но вместо вывода отладочной информации просто выполняла несколько холостых команд процессора. Количество этих команд тоже можно было подбирать нажатием на определенные клавиши.
Существовала и более «легкая» версия этой утилиты, которая не включала режим отладчика, а внедряла холостые команды в прерывания по таймеру. Но в том же WC она не работала в режиме без звука, т.к. в нем для ускорения аппаратные прерывания таймера были замаскИрованы.
Еще бы отнес сюда «В поле зрения/Подозреваемые». Неплохой НФ сериал на тему применения ИИ для анализа и профилактики преступлений. Смесь детектива, полицейского боевика и чуточку киберпанка. Не затянут. Герои не на одно лицо — каждый индивидуален. Концовка логичная и не сопливая.
В третьем сезоне сюжет чуть провис, но потом выправился.
Так что, рекомендую тем, кто интересуется темами тотального контроля и «презумпции виновности». А так же тем, кто не любит супергероев в трусах поверх лосин, но не прочь посмотреть на (не)простых парней и женщин, способных надрать недругам задницы.
Не рекомендуется тем, кто действительно знает, как оно там обстоит дело.
Речь не идет о точной оценке времени. Но если макет покажет, что глубина рекурсий растет не как ln(n), а как n, то это явно не имеет отношения к языку программирования, а косяк в самом алгоритме.
Ну я не математик, правда, и не программист. Обычный инженер-технарь. Но для решения технических (и не очень) задач приходилось и программировать и алгоритмы изобретать.
Так вот, совершенно не возникало трудностей с такими языками, как Fortran IV, PL/1, C. Даже Forth и ассемблер для Intel 8080/8086 освоил. Много писал на том же Turbo Pascal, Clarion. Немного знаком с C++, PHP (на нем даже что-то полезное сваял, как ни странно).
А вот ни C#, ни Pyton не зашли ни с первой попытки, ни со второй.
Хотя, есть подозрение, что дело в мотивации — по большому счету ни тот, ни другой мне не нужны.
Как то смешалось всё мягкое с теплым, а люди с конями…
Правильно тут многие написали — Pascal (в любой его ипостаси) — язык для новичков.
Нельзя говорить одновременно о профессиональном росте программиста и программировании на Pascal. Ну не стыкуется это от слова «совсем».
Но в то же время, кто сказал, что человек растет профессионально именно как программист? Сопутствующих областей деятельности сейчас — вагон и маленькая тележка в придачу. И это совсем не обязательно то, что называют по старинке программистом, а по жаргонному кодер.
Возьмем такую виртуальную, но тем не менее существующую (как говорят) профессию, как математик-алгоритмист.
Вот дают ему сердешному задание для оптимизации логистической работы:
1. Поставки, срок начала выполнения которых близок к дедлайну (с учетом возможных задержек в пути), должны начаться сегодня.
2. Поставки, дедлайн для которых далек, можно отложить до лучших времен (ну за исключением тех пунктов, куда можно что-то необременительно по весу и габаритам закинуть «по дороге».
3. Остальные поставки оптимизируются с учетом расхода времени, бензина, ограничений законодальства по ОТ и др.
4. И все это для полутора-двух-трех сотен пунктов поставок, сообщение между некоторыми из них только через Северный полюс на сломанных лыжах.
Ну, это я для примера… Просто для того, чтобы почувствовали насколько эта задача «интересная».
И вот наш горемыка после нескольких недель бессонного труда рожает, как ему кажется, приемлемую методу. И вот дальше начинается…
Он — ни разу не программист. У него другая работа. Но сделать работающий макет своего алгоритма ему необходимо. Хотя бы для того, чтобы убедиться, что временная сложность его полиномиальна, а не экспоненциальна. Т.е., он уверен, что результат близкий к оптимальному его алгоритм обеспечит, но за 5 минут или за 5 часов — вот в чем вопрос! Сколько реально (а не умозрительно) потребуется памяти, не будет ли вылетов из-за слишком глубоких рекурсий и т.д.
Ну и на каком языке ему писать этот макет, не привлекая специалистов? Чисто для себя, для проверки?
Вот тут мне и кажется, что и C# и Pyton требуют более высокого порога вхождения, чем тот же самый Pascal. Пусть даже он ABC.Net
Более того, IMHO, для таких целей процедурные языки гораздо более подходящие, чем чистые ООП-языки. Т.е., чем проще, тем лучше. Но не слишком просто, чтобы иметь возможность делать что-то чуть более серьезное, чем сложение и вычитание.
Ну, я склонялся к серии WD Caviar Black. Но, сейчас думаю, что серверный Seagate вполне пойдет. Тем более, что в 2 с лишним раза дешевле и мне по карману.
Смущает, правда, энергопотребление — больше 10 Вт. И не совсем ясно, какой у него размер сектора. Если 4 Кб, то мне не пойдет. Тому как работать ему придется под WinXP (отсюда и ограничение 2 Тб).
А использовать буду его для законопротивного дела — скачивать и раздавать фильмы на торрент-трекерах. Два диска по 1,5 Тб уже забиты под завязку. Приходится чистить периодически. Да и сыпаться один начал уже конкретно.
Если фронтальный вентилятор расположен напротив отсеков с хардами, то реально удавалось снижать их температуру на 5-8° — с 47-50 до 42-43.
Но это палка с двумя концами. Если харды так греются, то проблема может быть в том, что их много и вентиляция плохая. А раз их много, то надо не вентилятор на корпус ставить, а корпус брать посвободнее и кулер ставить на каждый свой.
У меня вот сейчас проблема. Нужен хард недорогой, но и не отстойный. Ровно 2 Тб. Что ни смотрел — ничего не нравится. Вернее, всё что нравится, начинается с 15000 рэ. А это для меня дороговато.
К сожалению, компрессор не очищает пыль с лопастей вентилятора. Очень уж она там въедливая. Приходится салфетками оттирать. И, таки да, для вентиляторов этот способ вреден.
Ну и, кроме того, компрессор не увезешь с собой «на выезд». Но для домашнего компьютера сойдет.
Мы сами, лет 7-8 назад еще, когда не было такого зверь-пылесоса, носили компы в гараж, пользовались местным компрессором.
Неотчищающаяся грязь считается элементом конструкции :)
Конечно, чистить надо несколько чаще, чем раз в 10 лет.
У нас, помню, до того, как ввели обязательную регламентную профилактику, на некоторых объектах АРМы стояли по 3-4 года необслуженные. Термопаста у некоторых превратилась в камень и прикипела намертво. При попытке снять радиатор кулера, он снимался вместе с процессором, т.к. защелка была под ним и освободить ее до снятия радиатора было сложно. При этом часть ножек процессора оставалась в сокете :)
Но это было давно, когда процессоры еще были большими с ножками. С тех пор они стали с контактными точками, а мы перешли с термопасты КПТ-8 на Arctic Cooling. Она вязкая и не высыхает так быстро.
Упоминание про 6-часовую очистку от пыли повергли в ступор.
У нас по регламенту все сервера, АРМы, компьютеры, терминалы и ноуты проходят профилактический осмотр и чистку 1-2 раза в год. Т.е., если по одной штуке в день, то практически бесконечный процесс. Как покраска Бруклинского моста.
Но т.к. ездить несколько дней подряд по удаленным объектам за полтора-два десятка км за черту города как-то навевает тоску, то стараемся за один раз обслужить 6-10 компьютеров или 4-5 промышленных АРМов (с ними возни побольше).
При этом ориентируемся на такие трудозатраты на чистку (для бригады из двух человек):
1. Бездисковые терминалы — 30 минут.
2. Компьютеры в офисных корпусах — от 40 минут до 1 часа (если надо еще заменить хард с переносом образа).
3. Компьютеры и АРМы в промышленных корпусах — от 1,5 до 2 часов.
4. Сервера — 2 часа.
Работа включает в себя:
1. Полная разборка, снятие всех плат, вентиляторов и кулеров, процессоров.
2. Осмотр, фотофиксация проблем.
3. Чистка поверхностей от пыли.
4. Чистка контактов.
5. Промывка подшипников вентиляторов. Смазка.
6. Замена термопасты с удалением старой.
7. Сборка и пробный запуск. Иногда после этого еще подшаманить приходится.
Для этого используются:
1. Влажные салфетки.
2. Кисть.
3. Ластик Koh-i-Noor.
4. Сжатый воздух в баллонах.
5. Пылесос промышленный с выдувом (сдувает все, что не прибито гвоздями).
6. Термопаста Arctic Cooling (не на правах рекламы).
7. Силиконовая смазка жидкая.
8. Спирт изопропиловый.
9. А так же всякие инструменты, синяя изолента и какая-то там мать.
Если машина обещала вернуться только к концу рабочего дня, то можно не спешить особо и за 6 часов сделать 5-6 компьютеров. Но столько времени тратить на один?!!!
Если не закрыть удаление, то скрытие списка не защитит от удаления по маске.
Перенос в недоступное место не является панацеей, но идея интересная. хоть и требует развития.
Прежде всего, остаются 2 проблемы:
1. Между помещением файла в FTP-хранилище и переносом в недоступное место, может пройти некоторое время, достаточное для проведения деструктивных действий.
Далее они будут скопированы в «недоступное» место уже измененные. При этом в «недоступном» месте, возможно, будут удалены предыдущие самые старые версии. После нескольких таких циклов годных копий не останется.
2. Файлы уже могут быть скопированы на FTP в запоротом испорченном виде.
Есть идея, которая полностью не решит эти проблемы, но может снизить риски.
Заключается в использовании файлов-триггеров, содержащих контрольные суммы (КС) переданных файлов. Происходит следующее:
1. По расписанию на стороне FTP-сервера проверяется наличие файла-триггера. Если он есть, то:
2. Закрывается соединение по FTP.
3. Проверяется целостность файла-триггера.
4. Извлекаются из него КС полученных файлов.
5. Если КС совпадают, то освобождается место под них в «недоступном» хранилище и файлы переносятся туда. Триггер стирается.
6. Если все нормально, то FTP-открывается, иначе — алярм!
Но это позволяет контролировать целостность файлов только в промежутке между вычислнием КС и обнаружением триггера на стороне FTP-сервера. Если же архивы были зашифрованы/испорчены раньше, чем вычислены их КС, то это не поможет.
Как вычислять КС резервных файлов методами SQL на этапе создания — не знаю. В файле резервного копирования хранится КС для каждой резервной копии из него, но не всего файла. А еще есть файловые БД (хоть их у нас и немного осталось), которые просто архивируются сторонним архиватором.
Можно, конечно, среди резервных файлов разместить файл-ловушку (honeypot), с известной контрольной суммой. Но тогда надо его каждый раз переписывать свежим (даже если он не изменяется), а то зловред может проигнорить древние файлы. И, да, этот горшочек меда тоже не должен быть слишком маленьким, чтоб не показаться ему не стоящим внимания.
PS. Кстати, в этом случае «недоступное» место можно сделать в облаке. Но копировать в него не несколько раз в сутки, а 1-2 раза в неделю.
Такое «благородное» поведение шифровальщиков, оставляющее шанс на восстановление информации, увы, осталось в прошлом. Тот же самый Not Petya шифровал MFT логических дисков.
А еще вместо этого можно дополнительно шифровать все файлы объемом свыше 100 Mb. Архивы, резервные копии БД, образы дисков обычно весят больше.
Про FTP — идея правильная. Но не совсем. Потому что оригинальный FTP не шифрует аутентификационные данные. Либо использовать FTP over SSH, либо использовать расширения FTPS, которую NAS может и не поддерживать.
И то не уверен, что FTPS шифрует аутентификационные данные.
Таким образом, аутентификационные данные передаются в открытом виде. А, следовательно, могут быть перехвачены, проанализированы и скомпрометированы. После чего на NAS поступит команда стереть или переписать хранящиеся на нем файлы мусором.
Что произойдет с содержимым облачного хранилища, после того, как шифровальщик зашифрует бэкапы в этой папке и их теневые копии за компанию?
В лучшем случае можно будет из облака попытаться достать предыдущие версии этих файлов. Но это в том случае, если хранилище поддерживает версифкацию файлов и места в нем для этого достаточно. В худшем…
Прошу прощения, но какой ЖК 17" поддерживал бы режим 320х240? У меня завалялись несколько старых 15", но они минимум 640х480 обеспечивают, да и то я в этом не уверен.
Кстати, хотел как-то зарубиться в DT через DOSBox. То ли версия неудачно ломанная, то ли она через DOSBox принципиально не идет — вылетает в момент активации оружия, т.е, на первом же повороте.
А что значит «на старших 386»?
Многие игры были расчитаны на PC XT/AT с частотой процессора 8 МГц. Например, «Digger». При попытке запустить ее на AT-386/25 или AT-386/40 скорость была такая, что даже не успевали среагировать — от края до края экрана копатель проезжал за секунду.
Для игры в Wing Commander я написал на ассемблере специальную резидентную утилиту. По нажатию на определенную горячую комбинацию клавиш она переводила исполнение в режим отладчика, но вместо вывода отладочной информации просто выполняла несколько холостых команд процессора. Количество этих команд тоже можно было подбирать нажатием на определенные клавиши.
Существовала и более «легкая» версия этой утилиты, которая не включала режим отладчика, а внедряла холостые команды в прерывания по таймеру. Но в том же WC она не работала в режиме без звука, т.к. в нем для ускорения аппаратные прерывания таймера были замаскИрованы.
А начало — да, несколько неспешное.
В третьем сезоне сюжет чуть провис, но потом выправился.
Так что, рекомендую тем, кто интересуется темами тотального контроля и «презумпции виновности». А так же тем, кто не любит супергероев в трусах поверх лосин, но не прочь посмотреть на (не)простых парней и женщин, способных надрать недругам задницы.
Не рекомендуется тем, кто действительно знает, как оно там обстоит дело.
Так вот, совершенно не возникало трудностей с такими языками, как Fortran IV, PL/1, C. Даже Forth и ассемблер для Intel 8080/8086 освоил. Много писал на том же Turbo Pascal, Clarion. Немного знаком с C++, PHP (на нем даже что-то полезное сваял, как ни странно).
А вот ни C#, ни Pyton не зашли ни с первой попытки, ни со второй.
Хотя, есть подозрение, что дело в мотивации — по большому счету ни тот, ни другой мне не нужны.
Правильно тут многие написали — Pascal (в любой его ипостаси) — язык для новичков.
Нельзя говорить одновременно о профессиональном росте программиста и программировании на Pascal. Ну не стыкуется это от слова «совсем».
Но в то же время, кто сказал, что человек растет профессионально именно как программист? Сопутствующих областей деятельности сейчас — вагон и маленькая тележка в придачу. И это совсем не обязательно то, что называют по старинке программистом, а по жаргонному кодер.
Возьмем такую виртуальную, но тем не менее существующую (как говорят) профессию, как математик-алгоритмист.
Вот дают ему сердешному задание для оптимизации логистической работы:
1. Поставки, срок начала выполнения которых близок к дедлайну (с учетом возможных задержек в пути), должны начаться сегодня.
2. Поставки, дедлайн для которых далек, можно отложить до лучших времен (ну за исключением тех пунктов, куда можно что-то необременительно по весу и габаритам закинуть «по дороге».
3. Остальные поставки оптимизируются с учетом расхода времени, бензина, ограничений законодальства по ОТ и др.
4. И все это для полутора-двух-трех сотен пунктов поставок, сообщение между некоторыми из них только через Северный полюс на сломанных лыжах.
Ну, это я для примера… Просто для того, чтобы почувствовали насколько эта задача «интересная».
И вот наш горемыка после нескольких недель бессонного труда рожает, как ему кажется, приемлемую методу. И вот дальше начинается…
Он — ни разу не программист. У него другая работа. Но сделать работающий макет своего алгоритма ему необходимо. Хотя бы для того, чтобы убедиться, что временная сложность его полиномиальна, а не экспоненциальна. Т.е., он уверен, что результат близкий к оптимальному его алгоритм обеспечит, но за 5 минут или за 5 часов — вот в чем вопрос! Сколько реально (а не умозрительно) потребуется памяти, не будет ли вылетов из-за слишком глубоких рекурсий и т.д.
Ну и на каком языке ему писать этот макет, не привлекая специалистов? Чисто для себя, для проверки?
Вот тут мне и кажется, что и C# и Pyton требуют более высокого порога вхождения, чем тот же самый Pascal. Пусть даже он ABC.Net
Более того, IMHO, для таких целей процедурные языки гораздо более подходящие, чем чистые ООП-языки. Т.е., чем проще, тем лучше. Но не слишком просто, чтобы иметь возможность делать что-то чуть более серьезное, чем сложение и вычитание.
Например, такой: market.yandex.ru/product/6083304
Смущает, правда, энергопотребление — больше 10 Вт. И не совсем ясно, какой у него размер сектора. Если 4 Кб, то мне не пойдет. Тому как работать ему придется под WinXP (отсюда и ограничение 2 Тб).
А использовать буду его для законопротивного дела — скачивать и раздавать фильмы на торрент-трекерах. Два диска по 1,5 Тб уже забиты под завязку. Приходится чистить периодически. Да и сыпаться один начал уже конкретно.
Но это палка с двумя концами. Если харды так греются, то проблема может быть в том, что их много и вентиляция плохая. А раз их много, то надо не вентилятор на корпус ставить, а корпус брать посвободнее и кулер ставить на каждый свой.
Но как полумера может сработать.
У меня вот сейчас проблема. Нужен хард недорогой, но и не отстойный. Ровно 2 Тб. Что ни смотрел — ничего не нравится. Вернее, всё что нравится, начинается с 15000 рэ. А это для меня дороговато.
Ну и, кроме того, компрессор не увезешь с собой «на выезд». Но для домашнего компьютера сойдет.
Мы сами, лет 7-8 назад еще, когда не было такого зверь-пылесоса, носили компы в гараж, пользовались местным компрессором.
К сожалению, метода не работает, если:
1. На балконе холодно, а в комнате еще отопления не включили.
2. Комп должен быть через час «в строю».
Конечно, чистить надо несколько чаще, чем раз в 10 лет.
У нас, помню, до того, как ввели обязательную регламентную профилактику, на некоторых объектах АРМы стояли по 3-4 года необслуженные. Термопаста у некоторых превратилась в камень и прикипела намертво. При попытке снять радиатор кулера, он снимался вместе с процессором, т.к. защелка была под ним и освободить ее до снятия радиатора было сложно. При этом часть ножек процессора оставалась в сокете :)
Но это было давно, когда процессоры еще были
большимис ножками. С тех пор они стали с контактными точками, а мы перешли с термопасты КПТ-8 на Arctic Cooling. Она вязкая и не высыхает так быстро.А, вообще-то, домашний комп не трудно раз в несколько месяцев отпрофилачить. Не так тщательно, конечно, но ему будет легче работать.
У нас по регламенту все сервера, АРМы, компьютеры, терминалы и ноуты проходят профилактический осмотр и чистку 1-2 раза в год. Т.е., если по одной штуке в день, то практически бесконечный процесс. Как покраска Бруклинского моста.
Но т.к. ездить несколько дней подряд по удаленным объектам за полтора-два десятка км за черту города как-то навевает тоску, то стараемся за один раз обслужить 6-10 компьютеров или 4-5 промышленных АРМов (с ними возни побольше).
При этом ориентируемся на такие трудозатраты на чистку (для бригады из двух человек):
1. Бездисковые терминалы — 30 минут.
2. Компьютеры в офисных корпусах — от 40 минут до 1 часа (если надо еще заменить хард с переносом образа).
3. Компьютеры и АРМы в промышленных корпусах — от 1,5 до 2 часов.
4. Сервера — 2 часа.
Работа включает в себя:
1. Полная разборка, снятие всех плат, вентиляторов и кулеров, процессоров.
2. Осмотр, фотофиксация проблем.
3. Чистка поверхностей от пыли.
4. Чистка контактов.
5. Промывка подшипников вентиляторов. Смазка.
6. Замена термопасты с удалением старой.
7. Сборка и пробный запуск. Иногда после этого еще подшаманить приходится.
Для этого используются:
1. Влажные салфетки.
2. Кисть.
3. Ластик Koh-i-Noor.
4. Сжатый воздух в баллонах.
5. Пылесос промышленный с выдувом (сдувает все, что не прибито гвоздями).
6. Термопаста Arctic Cooling (не на правах рекламы).
7. Силиконовая смазка жидкая.
8. Спирт изопропиловый.
9. А так же всякие инструменты, синяя изолента и какая-то там мать.
Если машина обещала вернуться только к концу рабочего дня, то можно не спешить особо и за 6 часов сделать 5-6 компьютеров. Но столько времени тратить на один?!!!
Перенос в недоступное место не является панацеей, но идея интересная. хоть и требует развития.
Прежде всего, остаются 2 проблемы:
1. Между помещением файла в FTP-хранилище и переносом в недоступное место, может пройти некоторое время, достаточное для проведения деструктивных действий.
Далее они будут скопированы в «недоступное» место уже измененные. При этом в «недоступном» месте, возможно, будут удалены предыдущие самые старые версии. После нескольких таких циклов годных копий не останется.
2. Файлы уже могут быть скопированы на FTP в
запоротомиспорченном виде.Есть идея, которая полностью не решит эти проблемы, но может снизить риски.
Заключается в использовании файлов-триггеров, содержащих контрольные суммы (КС) переданных файлов. Происходит следующее:
1. По расписанию на стороне FTP-сервера проверяется наличие файла-триггера. Если он есть, то:
2. Закрывается соединение по FTP.
3. Проверяется целостность файла-триггера.
4. Извлекаются из него КС полученных файлов.
5. Если КС совпадают, то освобождается место под них в «недоступном» хранилище и файлы переносятся туда. Триггер стирается.
6. Если все нормально, то FTP-открывается, иначе — алярм!
Но это позволяет контролировать целостность файлов только в промежутке между вычислнием КС и обнаружением триггера на стороне FTP-сервера. Если же архивы были зашифрованы/испорчены раньше, чем вычислены их КС, то это не поможет.
Как вычислять КС резервных файлов методами SQL на этапе создания — не знаю. В файле резервного копирования хранится КС для каждой резервной копии из него, но не всего файла. А еще есть файловые БД (хоть их у нас и немного осталось), которые просто архивируются сторонним архиватором.
Можно, конечно, среди резервных файлов разместить файл-ловушку (honeypot), с известной контрольной суммой. Но тогда надо его каждый раз переписывать свежим (даже если он не изменяется), а то зловред может проигнорить древние файлы. И, да, этот горшочек меда тоже не должен быть слишком маленьким, чтоб не показаться ему не стоящим внимания.
PS. Кстати, в этом случае «недоступное» место можно сделать в облаке. Но копировать в него не несколько раз в сутки, а 1-2 раза в неделю.
А еще вместо этого можно дополнительно шифровать все файлы объемом свыше 100 Mb. Архивы, резервные копии БД, образы дисков обычно весят больше.
Про FTP — идея правильная. Но не совсем. Потому что оригинальный FTP не шифрует аутентификационные данные. Либо использовать FTP over SSH, либо использовать расширения FTPS, которую NAS может и не поддерживать.
И то не уверен, что FTPS шифрует аутентификационные данные.
Таким образом, аутентификационные данные передаются в открытом виде. А, следовательно, могут быть перехвачены, проанализированы и скомпрометированы. После чего на NAS поступит команда стереть или переписать хранящиеся на нем файлы мусором.
В лучшем случае можно будет из облака попытаться достать предыдущие версии этих файлов. Но это в том случае, если хранилище поддерживает версифкацию файлов и места в нем для этого достаточно. В худшем…