Pull to refresh

Comments 139

>У нас недостаточно данных, чтобы объяснить такую необычно высокую скорость BlackBerry Q10 для не-Apple устройств, но есть правдоподобная догадка, что это объясняется наличием физических кнопок — для них легче реализовать быстрый отклик, чем для тачскрина и виртуальной клавиатуры

А может правдоподобнее то, что в основе BlackBerry OS лежит QNX, которая RTOS, и на время отклика не влияют никакие внешние причины?
> А может правдоподобнее то, что в основе BlackBerry OS лежит QNX, которая RTOS, и на время отклика не влияют никакие внешние причины?

Так в Эпла же не RTOS и время отклика ниже, а в Пикселя на 10 больше, что не значительно выше, но и Андроид не RTOS. Так что, думаю, вы нашли закономерность там, где ее нет.

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

Почему-то у всех RTOS ассоциируется со скоростью, что в корне не верно. Единственная задача RTOS — обеспечить гарантированное время реакции на событие. При чем время реакции не обязано быть маленьким. Оно может составлять секунды.
Для каждой задачи (процесса, потока) указывается максимальное время реакции на событие. Задача шедуллера RTOS — удовлетворить все эти ограничения. И все.
Более, того, существует теорема, которая говорит что для того что-бы Rate-monotonic scheduler смог удовлетворить все заявки, средняя нагрузка процессора должна быть не более чем 69.32% (при количестве задач, стремящимся к бесконечности). Т.е. процессор будет простаивать 30% процентов времени. Для алгоритмов с динамическим изменением приоритетов нет столь жутких ограничений, но все равно, 100% загрузки процессора можно будет достичь только в идеальном случае.

Конечно, возможно разработчики BlackBerry оттюнили приоритеты задач таким образом, чтобы реакция на нажатия кнопки была быстрой, но по опыту могу сказать что обычно всему что связанно с UI отдается один из самых низких приоритетов. <sarcasm>Все равно пользователь ничего не заметит</sarcasm>
но по опыту могу сказать что обычно всему что связанно с UI отдается один из самых низких приоритетов. Все равно пользователь ничего не заметит
Странно. В iOS и Android UI-поток имеет наивысший приоритет.

Система не встаёт колом ни при каких самых кривых программах, впрочем, потому что наивысший приоритет имеет один поток — а ядер в современных телефонах и планшетах гораздо больше одного…
Ну да, винда тоже повышает приоритет тому процессу, у которого окно находится в фокусе.

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

Все верно, только Вы забыли следующие моменты:


  • классический RMS/RMA рассчитан на uniprocessor, SMP расширения имеют другой теоретический предел;
  • более современные практики ориентируются на response time analysis (RTA); справедливости ради, смысл у этого термина иной, нежели у автора статьи;
  • в промышленных ОСРВ нет динамического планирования ни в одной из трактовок этого термина;
  • в QNX планировщик не оперирует dedaline-ами задач.

Разве я где-то упомянул скорость? Я только указал на независимость скорости UI от внешних причин.


но по опыту могу сказать что обычно всему что связанно с UI отдается один из самых низких приоритетов

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

Очень странный подход. Вы выносите итоговые результаты в таблицу под названием «время отклика устройств», а потом сами же и пишете в статье, что замеряете на самом деле время отклика самого устройства (железа) + время отклика эмулятора терминала (или простигосподи браузера), и сами же демонстрируете, что:

— второе значительно больше первого — железо откликается за время порядка <=10 мс, а софт от 30 до 100+ мс;
— браузер и эмулятор терминала, работающий напрямую с фреймбуфером, отличаются по скорости в разы (сюрприз).

Зачем тогда вообще сравнивать тёплое с мягким?
Так сравнивается же пользовательская характеристика: время отклика настольного компьютера. А что у него под капотом — дело десятое.
Сравнивать её разными приложениями — некорректно. Более честно было бы, например, брать на каждом устройстве отклик самого быстрой виртуальной консоли из известных (/dev/tty думаю хорошо так обгонит lxterm), и то её быстродействие зависит от конфига ядра.
По-моему как раз наиболее корректно сравнивать с тем, чем человек пользуется в повседневной работе. Лично я не сижу в /dev/tty и поэтому сравнение с ним для меня ничего не будет значить :) (Хотя, конечно, увидеть измерения /dev/tty в табличке всё равно будет любопытно)
Тогда надо было выводить одинаковый объем информации, а не символ. В данном случае раз проверка велась в консоли, то и логичнее было бы современные системы грузить с чистой консолью без всей лабуды (мы ведь сравниваем навороченность железа и время отклика?) А если речь о выводе пользовательской информации, то старые системы проигрывают хотя бы при выводе картинки. Учитываем что старые системы в связке железо — пользователь имели минимальное расстояние, а сейчас? фреймворк на фреймоворке, виртуальные машины в виртуальных машинах, там до железа… Так что все эти сравнения — полная чепуха.
(мы ведь сравниваем навороченность железа и время отклика?)

Нет, мы сравниваем задержку, которую видит обычный пользователь на обычном (или почти обычном) компьютере в обычном для рассматриваемого компьютера окружении. Сравнивать голое железо нет никакого практического смысла, потому что голым железом никто (или почти никто) не пользуется. Вы же сами пишете этот комментарий через виртуальную машину в песочнице в фреймворке в нескольких абстракциях от железа, не так ли? :)


Насчёт одного символа — я как-то слабо представляю, как сравнивать не один символ, если обычные клавиатуры позволяют вводить текст только посимвольно

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

И пишу тут комментарий, при этом работает проверка синтаксиса, всякие пунтосвитчеры, пишу не в консоли, а в браузере и т.п.
Ещё раз, в «чистоте эксперимента» нет никакого практического смысла, потому что никто не пользуется голым железом. Ещё раз, цель сабжа — измерение задержки, которую видит обычный пользователь в обычном окружении. Когда вы поставите «чистый эксперимент», это будет уже не обычное окружение.

Мне глубоко плевать, если мой ноутбук на Core i5 вдруг уделает Apple 2e покажет задержку в десять миллисекунд на каком-нибудь FreeDOS. Какое мне дело до FreeDOS, если я в повседневной жизни использую какой-нибудь gnome-terminal с композитным оконным менеджером, с которыми задержка, к примеру, сотня миллисекунд?

Сравнить «навороченность железа и время отклика» в принципе можно, но, ещё раз, у автора такой цели не было. И я тоже не вижу в этом смысла.
А как насчет уточнить и сравнить скорость отклика у PS/2 и USB клавиатур отдельно?
Ох уж эти сферические кони в вакууме…
Подозревать я стал год назад.
Я это «по-чувс-тво-вал».

Уже месяц я делюсь своими догадками с собеседниками. А вот теперь бесспорные доказательства:

==Современные компы тормозят сильнее старых.==

Особенно в «микротранзакциях».

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

Я купил себе 386-й.
Летает.
А Вы MS DOS поставьте, так чтобы не улетел, будете якорь привязывать…

В статье сравнивается отклик нажатия на клавиатуру через обработку ОС и выводного приложения, которые на каждом аппаратном решении будут разные.

Но это неверно, чтобы отбросить влияние этого «мусора», создайте приложение, которое само управляет I/O и скомпилируйте его на Assembler. Мне кажется, что так были бы более сопоставимые результаты.
Как раз недавно запустил старый 233Мгц с MS-DOS/Win98, был удивлен тем, как тормозит ввод в консоли по сравнению с Core2. Понятно, что железо старое, но это было настолько явно видно, что удивило.
Если посмотреть на современные клавиатуры, то обычно ввод данных сканируется с частотой от 100 Гц до 200 Гц

Понимаю, что это перевод, но чисто для уточнения:
есть много клавиатур, у которых частота опроса 1000Гц. Еще некоторое время назад читал статью, в которой тестировали Apple Magic Keyboard, и оказалось, что у них отклик быстрее чем у большинства разрекламированных механических клавиатур.

Так что справедливости ради, надо бы взять нормальную клавиатуру для теста.
Но… но… но как же? Получается, новые компы более тормозные, чем какой-то Apple 2 на проце 6502?
Время отклика на нажатие клавиши — это лишь часть расплывчатой характеристики «быстродействие». В быстродействие ещё входит скорость обработки данных, скорость передачи данных (RAM, диск итд) и ещё куча всего.

Чудес не бывает, старые машины по производительности значительно слабее современных.

«Медленность» нового железа в статье на поверку оказалась медленностью софта и современных графических оболочек. Если портировать например ChromeOS и LXDE на Apple II, то lxterm там будет демонстрировать ровно такую же «медленность». Обратно, если на современном ПК нажать клавишу в голой консоли (tty), то подозреваю, что время отклика будет ровно такое же, как и в нативной консоли apple 2 — пара десятков мс.
Они не более «тормозные». Они менее юркие. То же самое как с машинами.

Веспа полувековой давности с двигателеми в 100 кубов по параметру «время разворота» легко уделывает БелАЗ-75710 — несмотря на разницу в мощности в 1000 c лишним раз.

То же самое — и с компьютерами…
Я не вижу результатов работы системы ввода/вывода MS-DOS, зато вижу много рекламы надкусанного яблока. Ещё я не вижу FreeBSD. Лет 25 я бы уверенно сказал время отклика, т.к. его можно было посчитать. Средства MS-DOS медленно опрашивали клаву, поэтому для скорости напрямую работали с контроллером клавиатуры, там же таймер и пищалка были.
Средства MS-DOS не опрашивали клаву, в MS-DOS прилетало аппаратное прерывание от клавиатуры INT 09h (IRQ 1) по каждому нажатию и отпусканию клавиши.
Шутки шутками, но пора в дополнение к закону Мура придумывать закон кого-нибудь ещё (только, пожалуйста, не меня) об экспоненциальном возрастании тормозов. Помню как в начале 1997-го года в фирму купили новейшее чудо техники Pentium 133, но котором Word к всеобщему восхищению открывался примерно за секунду. Сейчас на своём Core i7 померил ради интереса — 9 секунд. Только не говорите про возросшую функциональность. Она примерно такая же.
Сейчас на своём Core i7 померил ради интереса — 9 секунд

У меня Word 2016 открывается за секунду. Комп собирал в начале 2011 года.


Только не говорите про возросшую функциональность. Она примерно такая же.

Различия в мелочах. Если перейти на MS Office 97, то окажется, что того нету, это неудобно, здесь от вообще падает и т.д.

Да всё есть и ничего не падает. Впрочем, риббона нет и после Ctrl-V мерзкая плашка "Ctrl" не повисает поверх текста.
То, чего не хватало в 97-м ворде, не хватает и сейчас.

Это мерзкой плашкой я пользуюсь постоянно — очень удобно.
А Office 97 падал значительно чаще.
В какой-то момент надо переставать выдумывать «мерзости» и пробовать пользоваться.
Оно всегда так, привычка и нежелание менять уклад, даже если новое лучше по всем параметрам. Плашка эта очень удобная, т.к. содержит необходимые инструменты прямо рядом с курсором. Выделил текст — у тебя сразу все форматирование основное. Вставку сделал — сразу дается выбор удалить ненужное порой форматирование исходного текста.
UFO just landed and posted this here
Вставку сделал — сразу хочу увидеть текст, который получился в результате. А тут какая-то левая фигня перед глазами болтается, перекрывая обзор.
Да, там есть одна полезная опция удаления ненужного форматирования. Вообще, в некоторых программах для этой цели сделано Ctrl+Shift+V. Дёшево и сердито. Без повисания на экране кусочка дерьма.

Кроме ухудшений и бессмыслицы, за прошедшие 20 лет, конечно, добавился некоторый набор мелких улучшайзингов. Глупо спорить. Но имейте в виду, что размер дистрибутива вырос более чем в 10 раз (прописью: десять грёбаных раз). Те улучшения, которые мы с трудом можем вспомнить, точно не стоят этого.
UFO just landed and posted this here
Бесконечные обновления всего и вся по большей части уже давно перестали быть добровольным делом.
UFO just landed and posted this here
Пишите, что сидите на Windows Server 2003.
UFO just landed and posted this here
Нет, просто Windows XP 64 bit имеет с Windows XP столько же общего, сколько, скажем, Windows 7 — с Windows Vista.
UFO just landed and posted this here

Интересная идея, тут нужно было поставить vs 2017 на комп на котором нет интернета, оказывается имея поставку в 20+Гб это невозможно сделать без сети, да в теории это сделать можно для этого нужно сделать несколько нетривиальных действий (конечно не в gui) на компе с инетом, потом перенести данный архив на нужное место и уже потом запустить специальным образом. Это я к тому что даже в enterprise версиях всё сделано так чтобы было крайне неудобно обновляться.

Почему «в теории»? У меня была поставка на 34Gb и она отлично ставилась без сети.
В порядке предположений: возросла длина цепочки обратной совместимости, добавился отвечающий за работоспособность на разных платформах код, появилась проверка/отсылка чего-то в интернет при запуске…

У нас, человеков, лучше всего получается придумывать объяснения и оправдания. Да, если весь софт по мере взросления становится тормозным и глючным, то Ворд, надо признать, ещё неплохо держится.

Для меня каноничным примером является программа для записи образов дисков Etcher. Она написана на Javascript (Electron) и мало того, что ее размер 60 МБ, она отправляет метрику об использовании.
Десктопная программа для записи дисков. И отправляет метрику об использовании (телеметрию). И, конечно же, проверяет обновления при каждом запуске, как же без этого.
github.com/resin-io/etcher/issues/1878
github.com/resin-io/etcher/issues/1772

Из-за того, что используется достаточно сильное, но не быстрое сжатие LZMA для портативной Linux-версии (appimage), программа стартует достаточно длительное время, примерно 4 секунды на моем компьютере, и использует 88 МБ RAM сразу после запуска.

Вот и получается, что у нас быстрые компьютеры, но реальные задачи выполняются очень не быстро, из-за неподходящих инструментов разработки (Javascript и Electron с chromium и ffmpeg — неподходящий инструмент разработки программ для компьютера!) и накладных расходов.
И, стоит заметить, я понимаю, почему разработчики выбирают Electron — у нас просто нет нормальных средств разработки кроссплатформенных графических программ для компьютера.
Программа будет либо выглядеть некрасиво или вовсе уродско (Java с JavaFx), либо придется писать GUI с учетом конкретных фреймворков в каждой системе (Mono c Windows Forms, GTK# и MonoMac соответственно), либо писать на интерпретируемых или небезопасных языках, со своими сложностями обработки графических событий (Qt и байндинги к нему).
UFO just landed and posted this here
UFO just landed and posted this here
Эта программа для записи образов HDD на флешки или HDD. Что-то вроде dd с gui, и возможностью записи сжатых образов без предварительной распаковки.

Не было программы, которая бы просто и хорошо работала в любой ОС.


Here at resin.io we have thousands of users working through our getting started process and until recently we were embarassed about the steps that involved burning an SD card. There was a separate track for each Mac/Windows/Linux and several manual and error-prone steps along the way.

To our surprise there was nothing out there that fitted our needs. So we built Etcher, a SD card burner app that is simple for end users, extensible for developers, and works on any platform.

Особенно впечатляет etcher-cli, у которого даже GUI нет, но она всё равно весит 68 МБ (Windows AMD64) или даже все 78 МБ (Linux AMD64).


Клон dd — в 2400 раз больше оригинала! И во много раз тормознее, скорее всего

Кстати я тоже заметил такое. В колледже, в 2004 у нас стояли машины с 256Мб памяти и Office то ли XP то ли 2000. Word открывался субъективно за секунду. Сейчас померил скорость открытия Word 2013 (Core i3, Windows 10, SSD) — открылся за 5-6 секунд.
Тогда ворд запускал «preloader» как стандарт. Сейчас он этого не делает. И правильно.
У вас чтото не то.
x230, i7-3520M, на минимальной частоте 2.9, word 2013,samsung 850 evo — меньше секунды. засекать не получается.
то же самое в режиме energy saver(отключение ssd, все шины на миниуме, от батареи) — от 1.5 до 3.5 секунд

x220 i5 2520M, samsung 850 evo, 1.5-2.5 секунды.

вот вам кстати, разница в кеше которая «не важна».

Шутки шутками, но пора в дополнение к закону Мура придумывать закон кого-нибудь ещё (только, пожалуйста, не меня) об экспоненциальном возрастании тормозов.
Закон Вирта?
Сейчас на своём Core i7 померил ради интереса — 9 секунд

У меня ворд 2013 открывается за секунду на i5 4670. Таки SSD поставить стоит. Ворд не столько кода выполняет много, сколько обращений к диску.

Только не говорите про возросшую функциональность. Она примерно такая же.

Т.е. номер версии просто так менялся все эти десятилетия? Функционала там вагоны нового. Для вас оно примерно так же, потому что вы используете его скорее всего как Wordpad какой-нить. Конечно с тех времен ничего не удаляли, а только прибавляли.
Таки SSD поставить стоит.

Да, I/O значит очень много.
Действительно, во времена 97 офиса на 98 винде Word открывался быстрее, чем на моем Core2 сейчас (5-15 с в зависимости от размера документа). В моем случае все «потуги» вызваны глючными драйверами Lenovo, которые неправильно отрабатывают Hibernate. Хотя жить от этого знания не легче.
Проверил запуск на MacBook
MS Word — 1.83s
Pages — 0.75s

Данные усреднены по 3-м попыткам.
Время засекалось кустарно, секундомером на iPhone. Стоп нажимал после того как увидел открывшееся приложение.

К сравнению, самое быстрое двойное нажатие, которое я смог сделать на секундомере это 0.08 секунд. 0,10 получилось сделать раза два, остально 0,12 +

Уж не знаю, где там Word открывается 9 секунд.

А вот то, что меня расстроило, так это то, что новая вкладка в терминале с ZSH открывается 1.15 секунды. Открывал новую вкладку как только видел строку ввода, 20 раз, получил 23 секунды. Закрыл 40 штук за 11 секунд, или 0,28 на вкладку. Значит думает комп как минимум 0,87c. Над новой вкладкой. Карл!

За это время мое приложение успевает сбегать 2 раза в базу, выгрузить 2000 сущностей, посчитать рейтинг, и все это 145 раз! (6ms на итерацию). Хммммммммм… интересно
Тоже самое замечал со вкладками и тоже ZSH. Не засекал, но ощущалось это очень долго и точно счет на секунды идет. Скорее всего надо смотреть, чего там напихано в .zshrc. У меня установлен oh my zsh, и он периодически лезет проверять обновления на github
Наверное стоит учитывать и время реакции, с момента когда увидели строку ввода до нажатия на Cmd+T, порядка 0.2 * 20 = 4 с.
Помниться я по молодости скорость бега тоже секундомером замерял.Но это плохой способ, слишком большая погрешность.Лучший через инжектор или дебагер замерять, так хоть точность приемлемая будет.
Только не говорите про возросшую функциональность. Она примерно такая же.

Конечно. И у Visual Studio 2017 функциональность примерно такая же как у Visual Studio 6.
Но вообще-то нет.
Пользователь как правило не видит что что-то изменилось в лучшую сторону. Это воспринимается как само собой разумеющееся. Зато точно видит, что «раньше не тормозило».
Зато точно видит, что «раньше не тормозило».

Справедливости ради, в повседневной деятельности «чтобы не тормозило» может быть намного важнее нового функционала. Какой толк с нового функционала, например, если при «жизни по-новому» автодополнение в коде думает секунд 10? (Реальный случай).
Word 2016 на Core i5 2.4 GHz, SSD — меньше секунды на открытие пустого документа.
У меня на ноуте хоть и i7, но HDD весьма тормозной. В этом и причина.
давайте вордами меряться, у меня rizen 1600 + ssd, ворд запустился за секунду
Может быть, это объясняется тем, что HDD особенно не ускорились 80-100 Мб/сек, при этом нагрузка на дисковую систему со стороны ОС и другого ПО сильно возросла и объемы загружаемого ПО тоже выше. А так, на хорошем SSD (особенно PCI-e) всё за секунду открывается, даже Photoshop.
Да, именно этим и объясняется. Но в сухом остатке мы имеем то, что сумасшедший прогресс не отменяет существенное ухудшение пользовательских характеристик.
Core i5 второго поколения word 2010 на SSD винте открывается 25 сек до окна и еще 5 сек до полной функциональности.
Простите, накипело
Прогресс на лицо *sarcasm enabled*

Из нового ПО, которое использую на компе (ос windows): VM Ware, IDE (php, go). — все, за 10 лет нового не добавилось… фотошоп, ворд, и т.п. чем пользовался ранее…

Но если раньше, мой первый комп с 16+32 мб ОЗУ, веником 1.2Гб, цпу пень 166ммх — справлялся с своей работой — то сейчас просто пипец…

На компе 8гб озу — достаточно хром два дня не закрывать — жрет 3-4гб, куда — не ясно, несколько вкладок, даже ютуба нет… другие программы — тоже прожорливые… пока не купил ssd — лагов было больше чем хотелось…

На ноуте 16гб озу — тоже часто под завязку память забита…

купил топовый дорогущий ноут, 32гб озу, i7 последний, крутая видяха и большой sdd — скорость работы приложений если и изменилась — то не существенно, так как запуская теже IDE что на компе 5ти летней давности, что на ноуте топовом 2017г выпуска — ни визуально ни по ощущениям не изменилась…

Раньше память была дорогая, сейчас доступно много и дешево, если считать дешевой цену за планку в 8гб от 100у.е…

Похоже мало кто беспокоится о производительности, лично видел и **уевал, когда чел запилил обработку данных: вытащить все-все из БД в массив, и NxN раз проходил по огромному массиву что-бы там чтото выудить… вместо написания алгоритма, который в 1 проход сделает нужно задачу + sql-запрос соответствующий.

Оно конечно круто, камень over 4Ghz, для ДОМАШНИХ пк, по цене over $1k, но, простите, для каких таких домашних задач нужен проц за 1к у.е.?

Иногда кажется, а может и не кажется, но нас маркетологи где-то на*бывают.


Так а вы зачем тогда, простите, новыми версиями софта пользуетесь? Работайте с тем, с чем справлялся ваш первый комп, и будет счастье. Раз, как вы говорите, не меняется ничего.
В старых версиях браузеров, например, новые сайты не работают. Office 97, например, не открывает xlsx. От нового монструозного, тормозного и глючного софта никуда не деться. Мы вынуждены его использовать.
Одна радость души моей — 5-й WinAmp 2007-го года выпуска…
Для 2000 офиса, который от 97 недалеко ушел, есть Compatibility Pack для поддержки новых форматов, но, полагаю, не горите вы желанием им пользоваться.

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

А потому немножко некорректно говорить, что софт становится тормознее без каких-то функциональных изменений.
есть Compatibility Pack для поддержки новых форматов, но, полагаю, не горите вы желанием им пользоваться
Я не знаком ни с кем, кто горел бы желанием пользоваться этим самым Compatibility Pack. Но что-то подсказывает мне, что это не потому, что все влюбились в риббон.

куча всяких свистелок в веб-стандартах
Там вообще адъ
Так если вы говорите, что в старых офисах все было хорошо, чего не пользоваться-то? Или все-таки будем честны и скажем, что работает в них не всё, и не так, как того хочется? И, полагаю, проблема не в том, что на фоне идеального 2000-го офиса Compatibility Pack (и только Compatibility Pack) оказался кривой поделкой?

(Риббоны в офисе — это вообще офигенная штука, и как раз из-за них в свое время переходил на новую версию. Ну и из-за смарт-артов ещё.)

В вебе адищще, соглашусь. Но проблема тут не в браузерах как таковых, а в JS-ных поделиях по большей части, из-за чего браузерам пришлось как-то выкручиваться, чтобы всю эту хрень корректно и не очень медленно отображать. Полагаю, что если в новых браузерах открывать странички производства девяностых-двухтысячных годов, то и на старом железе тормозов не будет.
Так если вы говорите, что в старых офисах все было хорошо, чего не пользоваться-то?
В старых офисах всё хорошо, за исключением одной проблемы: совместимости с новыми. И поскольку люди этими новыми фичами реально пользуются, то деваться некуда — приходится «жрать кактус».

Вот с текстовыми редакторами подобной проблемы не случается — и там таки да, вполне можно пользоваться VIM'ом и Emacs'ом хоть 30-летней давности… впрочем современные версии ничуть не тормознее, так что смысла выискивать старые версии нет…

И, полагаю, проблема не в том, что на фоне идеального 2000-го офиса Compatibility Pack (и только Compatibility Pack) оказался кривой поделкой?
Не знаю кто или что там кривое, но в 2000м офисе .xlsx-документы очень часто неправильно отображаются. Может быть проблемой Compatibility Pack'а, MS Office 2016 (который автоматически использует какие-то фичи, отсутствующие в MS Office 2000 без ведома авторов), но это точно не проблема MS Office 2000 — он сам про .xlsx ничего не знает.

А так — до выхода и широкого распространения MS Office 2013/MS Office 2016 я только MS Office 2000 и пользовался…
Риббоны в офисе — недоведённая до ума офигенная штука. Если раньше что-то было в один клик доступно, то сейчас в 3-4 — офигеть удобство. Если раньше был нормальный пункт меню, то сейчас поле 15x15 пикселей — ты сможешь! я в тебя верю!
Маркетологи, конечно, тоже руку приложили, но зло не только в них. Проблема, мать её, сложности. Технологии таковы, что с ростом функциональности сложность растёт сильно нелинейно. Каждая софтина дорастает до состояния, когда каждая новая фичечка реализуется только через чудовищно неприемлемое усложнение.

Для меня эталоном сложностного тупика в своё время стала айбиэмовская вебсфера. Задача, которую она решает, проста и примитивна. Менеджер очередей сообщений. По сути, система почтовых ящиков. Неплохая тема для дипломного проекта в каком-нибудь ВУЗе средней руки. Как-то в цейтноте и безвыходняке я нечто подобное в наколеночном варианте набросал за вечер. Но… размер дистрибутива под 500МБ, и ресурсы жрёт так, будто исходит из предположения, что комп, на который оно установлено, больше ни для чего, кроме решения этой мелкой сугубо технической задачи, использоваться не будет. Когда-то оно наверняка тоже было маленьким и шустрым, а потом кабанело, кабанело и окончательно закабанело.
Может быть это глупый ночной вопрос, но что такое «Пакет вокруг света» в первой таблице? (статью прочитал по диагонали может быть не нашел).
А в остальном спасибо, очень любопытное исследование!
Из статьи:
Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон.
А вообще статьи пишут, чтобы их читали… Но видимо так — уже не модно.

Так где оно приведено? В статье нет этой информации

Во-первых, несмотря на то, что статья любопытная, она все же не входит напрямую в сферу моих личных или профессиональных интересов, поэтому, как было сказано выше, я прочитал ее «по диагонали». Если вы привыкли всё что попадает в поле вашего зрения читать «от корки до корки» это ваше право я на него не претендую.

Во-вторых, спасибо за приведенную выше цитату, я её действительно не разглядел. Думаю, если бы автор изложил ее в следующем виде:
Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон. (п. табл. «Пакет вокруг света»)

то у меня бы вообще вопросов не возникло.

P.S. У людей может быть разное восприятие мира. Например, у меня в голове в час ночи фраза: «Пакет вокруг света» выглядит следующим образом.

События поступают в ядро через прошивку

Немного аккуратнее надо переводить :) Понятно, что кратко этот процесс описать нельзя, но…
Можно оригинал статьи посмотреть? Линк только на homepage сайта
Помоему очень важная тема затронута в статье: сейчас выходит все именно так, что у нас есть все возможности и технологии делать быстрые интерфейсы, но в общем то индустрия занимается ерундой, а потребителям оно вообще не надо.

В пользу этой версии говорят чуть ли нее все автомобильные интерфейсы ( а там это еще и безопасность) и вообще весь рынок смартфонов на Andoroid. (я лично протестировав кучу флагманов за последние три года так и не смог найти хотя бы одного с отзывчивостью хотя бы iPhone 4)

Мне это не очень понятно, но похоже что для людями нравятся эти тупняки, или они их не замечают.
iPhone 4? Он давно перестал быть отзывчивым, 2 или 3 версии iOS назад как. А отзывчивый андроид легко найти — любой современный топовый девайс можно взять.
А что такого случилось 2 или 3 версии назад, что 4ка перестала быть отзывчивой?
Вышла iOS 8 — эпичный тормоз, да и 10 с 11 скоростью не радуют, 9 ещё куда ни шло, но тоже сильно отставала от 7-й по отзывчивости. Это из личного опыта на 5s, а так владельцы 4s жаловались на тормоза при смене 6 iOS на 7.
Говоря про отзывчивость я имею ввиду отклик на простейшие действия (нажатия, свайпы) Разница в этих действиях между версиями iOS даже на старых девайсах минимальна.
А вот со скоростью загрузки приложений тут да, ничего не попишешь.
Речь то была все таки про отклик, и про то что большинству оно в общем то и не нужно, либо не замечают. А при попытке продемонстрировать это, пользователи медленных девайсов включают защитную реакцию. Вон посмотрите на минусованый комментарий ниже.

Мне это не очень понятно, но похоже что для людями нравятся эти тупняки, или они их не замечают.
Замечают. Но тот 1% пользователей, кто на это обращает внимание до покупки, а не после — давно сидят на iPhone'ах, а учитывая их количество — воевать за них бессмысленно.
UFO just landed and posted this here
Джон Кармак в своём твиттере спрашивает:
«Отправить IP-пакет до Европы можно быстрее, чем вывести пиксель на экран. Какого х*ра?».

И, собственно, объясняет: superuser.com/a/419167
UFO just landed and posted this here

В smart TV от LG все так и есть

Банкомат — это очень тупая железка, он почти полностью управляется хостом. Для тех операций, которые делаются локально, я тормозов не замечал. А когда уходит запрос в процессинговый центр, так оно там не только делает свои запросы, но еще и может перенаправить запрос в МПС, если карта чужая.

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

Возможно, но есть нюанс. Возможно, это на стороне тех, кто прогружал в банкомат ресурсы (экраны). Рассказывали, что бывают такие случаи… Если это так, и банкомат всё время показывает одноцветный экран, таки можно снять деньги, пронажимав кнопки вслепую «по памяти» — на нужной последовательности будет сформирован запрос на хост, которому пофиг что рисуется, он реагирует на заполненный буфер нажатий.

Больше всего выбешивает переключение языка ввода, если быстро переключить язык и сразу начать набирать, то сюрприз, язык не переключится… Раньше такого не было.
p.s. Windows 7

UFO just landed and posted this here
У меня два кнопочных (условно говоря) смартфона: Blackberry Q10 (2013 год) и HTC Herald (2006 год). На Blackberry часто бывает так, что инпут лаг клавиатуры составляет секунды, особенно в Android-программах, особенно при переключении раскладки. Переключение раскладки сделано, вроде бы, нормально, но оно, по какой-то причине, настолько тормозное, что если нажать комбинацию переключения, некоторое время используется старая раскладка, хотя анимация переключения давно закончилась. Это невероятно бесит, и просто не позволяет набирать текст на нескольких языках быстро, постоянно приходится проверять, исправлять.

На HTC Herald, под управлением Windows Mobile 6.5, все наоборот: программы запускаются довольно медленно, сам коммуникатор не был быстрым даже в свое время (200 мГц процессор и 64 МБ оперативной памяти), зато любой ввод обрабатывается молниеносно. Переключения языка выполняется отдельной кнопкой, и никогда не сбоит. Буквы на экране появляются сразу после нажатия кнопки. Писать на нем тексты — сплошное удовольствие.

После alt-tab-а может вообще не сработать.
А всякие rdp это просто "сказка"

Ставьте что-нибудь типо ReCaps и вешайте переключение на CapsLock — проблемы с переключением языка сразу куда-то уходят. Зато если садишься за чужой компьютер — сразу встают в полный рост.
Скопировали с OSX не иначе. Раньше такого не замечал в винде, на макоси есть такой грешок
Кстати еще заметно… MacMini 2012 c 2,3 GHz Intel Core i7 и 16 Gb RAM / Fusion Drive.
Периодически хром впадает в ступор (например при открытии окна с другим профилем), да — у меня достаточно много вкладок и главный процесс хрома 2.85 Gb жрет.
Но вот только когда он впадает в ступор — иногда замирает вся система, музыка в iTunes (играемая с локальной медиатеки а не стримингом Apple Music) рывками идет и это слышно.

А с другой стороны как программист — планирую следующий мобильный проект и он видимо будет на JavaScript полностью или частично (правда на ReactNative а не Web-стеке). Потому что критически нужные библиотеки — только так подключить (все альтернативы не подходят либо по лицензии либо по функционалу, а бонусом рассчитываю что ReactNative даст возможность еще и UWP и macOS Desktop приложения сделать очень малой ценой).
В 80-е годы была проблема интерфейсов: пользователи долго и упорно с клавиатуры вводили исходные данные, нажимали на кнопку Ввод и компьютер моментально печатал на экране ответ и OK — ожидание следующего ввода. Пользователей такая мгновенная реакция компьютера раздражала, выдвигались предложения затормозить интерфейс для большего комфорта пользователей.
Я сам из того поколения, которое привыкло получать мгновенный отклик. Сейчас же, когда я кликаю мышкой в тормозном интерфейсе очередной мега-IDE (как пример) и до её реакции успеваю произнести про себя слово «блин», а то и не раз, то меня это жутко раздражает.
Сейчас же, когда я кликаю мышкой в тормозном интерфейсе очередной мега-IDE (как пример) и до её реакции успеваю произнести про себя слово «блин», а то и не раз, то меня это жутко раздражает.
Меня больше всего раздражают неподгрузившееся картинки в вебе. Нажимаешь на какую-нибудь кнопку, начинает показываться анимация, и на момент вы видите иконку незагрузившейся картинки, а потом она уже появляется.

Web весёлая штука, мобильная страница инстаграма с телефона после сброса к заводским настройкам через хром(т.е. это стартовая страница с предложением регистрации/логина) несколько секунд при этом мобильная версия интерфакса почти мгновенно.

Говоря об эмпирическом опыте. Коллекционирую старые ПК и их комплектующие более 10 лет и являюсь счастливым обладателем практически всей линейки IBM-совместимых ПК от 8086 до PIII.

И вот что я заметил: если собрать ПК на базе PentiumMMX 200MHz с 32Mb RAM и IDE-Flash вместо традиционного HDD, накатить на него Windows 98 и MS Office95, то такая сборка будет работать заметно быстрее и плавнее, чем мой рабочий ПК с i3-4130, 4Gb RAM и SSD-диском в MS Office365 под управлением Win7. Что реально доставляет, так это то, что основная задача офисного пакета с 1995 года не изменилась никак, базовый набор предлагаемых им плюшек тоже не претерпел видимых изменений, как и набор тех инструментов, которым пользуется рядовой офисный пользователь. Как печатали текстики, так и печатают. Как форматировали, так и форматируют. Но памяти свежезапущенный Word365 жрет больше в 70 раз, а еще умудряется и тормозить, и зависать в работе. Да, у 365 добавилось облако. Но при сравнении функционал, с ним связанный, не использовался.

И вот, что еще интересно. Если мы возьмем 486-й ПК на базе какого-нибудь 486DX4-100 (по сути, не самая топовая 486-я комплектация) с 16Mb RAM, и накинем на него Windows95 + Office95 (опять же, воспользуемся читом в виде IDE-Flash). То эмпирически получим примерно ту же отзывчивость, которую имеем на моем достаточно современном компе с самым современным офисом. По базовому функционалу — ну разве что облака не будет :)

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

У Dan Luu довольно спорный метод измерения latency. «Custom Haswell» или «MacBook» — это очень произвольные обобщения. На современных компьютерах latency очень сильно зависит от software и от режима его работы. Например, для компьютера под управлением windows следует a) Использовать DirectInput (причем устройство устройству, разумеется, рознь — скажем, джойстик на игровом порте будет иметь минимальный лаг). б) Использовать exclusive экранный вывод средствами DirectX — это даст минимальный latency даже под Windows. Разумеется, если загрузить машину даже не под реалтайм-операционкой, а всего-то под старым, добрым DOS, наваяв собственный exe/com — это даст минимальный Latency, но я хочу объяснить почему метод выбранный Dan Luu не очень хорош.
  1. Первое, от чего зависит Latency вывода на экран, это частота кадровой развертки видеосигнала. При частоте кадров 60Hz имеем возможный latency от начала к концу кадра 1/60=16мс. При частоте кадров 120Hz он уменьшается до 8мс.
  2. Внутренний буфер кадра ЖК-монитора запросто может дать еще задержку на кадр, что даст еще 1/60 = 16мс. Поэтому измерять задержку видео-камерой то еще занятие.
  3. В случае windows источником задержки служит дополнительный буфер композиции у менеджера композиции десктопа (dwm.exe). Aero даст большую задержку, нежели чем его отсутствие — весь вывод через Aero принудительно буферизуется во избежание tearing.
  4. DoubleBuffering или Page Flipping видеокарты даст 1/60 = 16мс.

И это только вывод. Если вся система так или иначе буферизует 3 кадра (скажем, 1 кадр монитор, 1 кадр page flipping видеокарты, 1 кадр Desktop Composite Manager), то одно только это уже дает 1/60*3=50мс.
Это далеко не единственный источник задержки в системе. Конечно, существуют переключения контекста операционной системы, прерывания, буферы драйверов, итд, итп — все это отдельный разговор. Моя задача была показать что способ измерения latency посредством съемки на камеру не очень подходящая метода для того чтобы делать далеко идущие выводы о latency обновления экрана современных устройств. Необходимо знать о внутренних буферах, о их необходимости, и о режимах работы в которых задержка минимальна.

А какой смысл во всём этом, если простой пользователь всё равно не будет проводить все эти манипуляции и у него в итоге все эти задержки всё равно будут? Как я уже отмечал выше, измерения в сферических условиях в вакууме не столь интересны. Таких условий всё равно ни у кого нет. Так-то можно на современный комп воткнуть какой-нибудь FreeDOS и получить офигенную скорость отклика, но зачем?


Впрочем, об этом даже в самой статье написано:


… измерения произведены с настройками, максимально близкими к настройкам ОС по умолчанию, поскольку примерно 0% пользователей меняют настройки дисплея для уменьшения буферизации, отключения компоновщика и т.д.
Вы совершенно правы в своем замечании. Вероятно, я не вполне ясно выразился. У автора прослеживается следующая мысль: «современные системы содержат очень много транзисторов, очень быстры, но всё равно имеют большой лаг по сравнению с 8-bit компьютером». Моя мысль: «современные системы быстры, всё это верно. Но в них существует пара-тройка буферов связанных с видео-выводом и задерживающих картинку минимум на 2-3 кадра, что даёт встроенный лаг, который портит впечатление при подобном тестировании этих систем по сравнению с 8-bit машиной». Также я хотел сообщить, что это лишь отчасти недоинжиниринг и разрастание функциональности, эти системы обеспечивают по-умолчанию luxury (прозрачность, отсутствие tearing итд). При соответствующей настройке software и hardware можно получать лаг меньше.
Не понятно, почему даблбуферинг дает еще одну задержку в кадр?
Кадр может быть отрисован в буфер очень быстро, дальше просто перенаправление выборки на новый адрес, в случае синхронизации да даст задержку до кадра, в случае без синхронизации задержки не будет.
Попробовал провести подобный опыт на своем компьютере. Моя камера позволяет записывать только со скоростью 60 кадров в секунду, то есть разрешение выходит примерно 16 миллисекунд.

С Windows 10 время отклика получается в среднем около 100 мс, на Linux Lite — 50.

Вот видео, если кому любопытно (замедлено в четыре раза): youtu.be/u2OBKcLRFxk
Прекрасная работа!
Почему-то после просмотра пришла мысль. Насколько в мире велик рынок сбыта маленьких микро-пылесосиков для программистов и вообще, IT-люда.
Да есть у меня микротряпка для клавы. Вот только лень, к сожалению, не микро.
Не знаю, что я делаю не так, но что дома, что на работе Word 2013 стартует за секунду. Конфигурация 2012 года (Sandy Bridge, 8/16 ГБ памяти, но главное — SSD, хоть и не самый свежий). TeXstudio стартует за 3–4 с. Якобы недостаточная скорость сканирования клавиатурной матрицы в Ergodox ни на что не влияет, задержка мозга и пальцев выше на порядок.
P.S. Меж тем более древняя конфигурация (компьютер отца, 2-ядерный Pentium E5300 под LGA775, 2 ГБ памяти и обычный HDD) с 2009 года постепенно превратился в тыкву. Windows 7 после установки обновлений для использования непригодна, пришлось Lubuntu поставить.
Купите Xeon E5450 или E5440, если мат. плата позволяет, и доставьте оперативной памяти. Моему компьютеру почти 10 лет, и все еще достаточно быстр в типичных задачах.
Intel® Core(TM) i3-7100 CPU @ 3.90GHz + SSD WDC WDS120G1G0A-00SS50 + 8GB RAM время запуска Word 1секунда
Странно, как можно заметить задержку в 2 мс, при наличии буфера в мозгу на 200 мс?
А что комментировать? Там статья по ссылке, где всё написано: и методология, и результаты. Если вам английский не знаком, то поясняю, как я понимаю эту работу:

Человек двигает стилусом квадратик на экране (или пишет текст). Дополнительная задержка приводит к тому, что объект смещается чуть позже. В статике эти миллисекунды, понятное дело, не заметны, но в динамике, когда человек следит глазами за движением, это можно увидеть.

Судя по работе, получается, что разница в 5 миллисекунд при быстром движении стилуса оказывается вполне заметной. Если двигать стилус со скоростью 200 уэе* в секунду, то лаг в 5 мс приведёт к отставанию объекта от стилуса на 1 уэе. Если перемещается объект размера 5х5 уэе, то это может быть заметно.
* условная экранная единица

Но работа, конечно, мутновата: как можно заметить разницу между 1 мс и 2 мс, используя 480 fps камеру, мне не понятно.

Мозг синхронизирует (приводит все события к единому timeflow) на самом деле там даже не 0.2 секунды а может быть и более.
Просто "мозг" обрабатывает картинку с экрана и движение пальцев в едином потоке.
А так мозг к примеру быстрее воспринимает боль чем звук а звук чем картинку...

UFO just landed and posted this here
Буфер работает не на задержку, а на синхронизацию. Т.е. он никак не мешает иметь реакцию, короче этого буфера, но зато отлично сливает воедино события одного потока действия разнесенные во времени.

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

Да можно заметить эти самые 2 мс, но только если они на границе, т.е. если есть предположим задержка в 200 мс и мы на нее не реагируем, т.к. она попадает в буфер. Но уже 202 мс, дадут ощущение запаздывания.

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

В общем саму по себе задержку в 2 мс, человек не осознает (фиг знает может есть мутанты без буыера).
Статья, IMHO, в общем-то, о том, что велосипеды быстрее самолётов, поскольку на велосипеде можно добраться куда-нибудь за несколько секунд, а на самолёте — минимум за час
P.S. а что за Linux chroot среди ОС?
UFO just landed and posted this here

Повторю мысль, пришедшую мне в голову месяц назад:


Кажется один из факторов — культурный. В информационном поле почти отсутствует мысль о важности отзывчивости и легковесности. Вот сколько я встречал списков сравнения best N apps for task X — не припомню, чтобы хотя бы в одном из них был замер использованного процессорного времени и памяти на выполнение аналогичных действий, примерно как я искал себе быстрый просмотрщик изображений. Вот в качестве пруфа можно погуглить "image viewers performance comparison" — очень мало ожидаемых результатов, всего ~3 в первой десятке! А для запроса "bittorrent clients performance comparison" в первой десятке только одна релевантная ссылка аж от 2010 года (ну и для справедливости ещё одна работа со сравнением скорости скачивания двух клиентов).


В идеальном мире в сравнительных обзорах были бы сравнения производительности с замерами, что давало бы разработчикам соревновательный стимул к оптимизации. Да, premature optimization — зло, но если ты вообще не прогонял свою программу через профайлер, то ты редиска.

Да, premature optimization — зло, но если ты вообще не прогонял свою программу через профайлер, то ты редиска.
Почему? Если пользователям пофиг?
А разве им пофиг? Как это можно проверить?

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

Но так ведь не бывает — если вы затратите ресурсов на пристальное изучение программы под профайлером, то затраты на неё возрастут, а знать — возрастёт и цена.

И если смотреть на продажи iPhone'ов — то хорошо видно, что, люди вполне готовы терпеть тормоза, чтобы получить не такую и большую экономию в цене (я специально взял для оценки iPhone, которые, как известно считаются фанатами всего самого нового, самого крутого, самого быстрого… думаю среди покупателей других телефоном таких будет ещё меньше).

Почему вы считаете, что ситуация с софтом должна быть иной?

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


Пользователям не "пофиг" в смысле отзывчивость приложений существенно влияет на комфортность их использования, о чём говорят например исследования влияния скорости загрузки сайтов на поведение пользователей и сам Dan Luu приводит в статье некоторые размышления. Но частично важность отзывчивости не осознаётся самими пользователями, что является частью моего исходного тезиса.


Теперь как можно трактовать статистику активаций ифонов. Во-первых, самые популярные модели по этой статистике стоят от трети до половины дешевле топовых. Разве это небольшая экономия в цене? Да пользователю вообще может быть выгоднее купить модель на 300$ дешевле, а потом потратить на 100$ больше на покупку софта под свои задачи, выбирая более дорогие вылизанные программы. Собственно мне кажется, что есть множество классов программ (какие-нибудь приложения аптек например), где на оптимизацию тратят ресурсов примерно 0, если там заложить под оптимизацию хотя бы 5% бюджета, ускорение может быть в разы.

Хотя бы у одного человека есть мозги. Таки да, а если бы мы добавили в этот список микрокомпьютеры Sinclair ZX Spectrum образца 1982 года и Amiga 1000 образца 1985 года, то и Apple 2e стал бы аутсайдером. Задержка в 5-6 мс на PAL-экранах. Спектрумы вдобавок готовы к работе с момента включения в розетку. Считайте что время загрузки <1 мс. И да, на Spectrum 128 сразу доступен калькулятор с точностью до 18 знаков после запятой с поддержкой тригонометрических функций и вводом примера «как есть». Дружно отправляемся на поиски точно такого калькулятора для Windows, Linux или Android с iOS. А то я так и не нашёл)))
Sign up to leave a comment.

Articles