В те времена религия утверждала, что планеты движутся по идеальным окружностям, Солнце вращается вокруг Земли, а другие объекты вращаются вокруг Солнца.
Можно подробнее? Не встречал такого. Зашел по ссылке, там написано
Like many philosophers of his era, Kepler had a mystical belief that the circle was the Universe’s perfect shape, and that as a manifestation of Divine order, the planets’ orbits must be circular.
Мне кажется, что под приватностью понимается отсутствие механизмов внутри поисковой системы привязать запросы к пользователю. Грубо говоря, открываем репозиторий и убеждаемся, что в логах пользователь и запрос не упоминаются одновременно.
Другое дело, что те, кто размещают систему у себя, могут быть нечистыми на руку. От банального «глупые людишки думают, что на наших серверах исполняется тот же код, что в репозитории», до любого middleware. Вопрос о техническом обеспечении анонимности доступа к ресурсу, конечно, интересен, но он лежит вне задач поисковой системы.
У меня, скажем, есть вопрос: возможно ли развернуть собственный узел этой поисковой системы и как будет этот узел взаимодействовать с другими? Если есть возможность развернуть и синхронизировать индекс, то ок, децентрализованная поисковая система нам нужна. Если можно развернуть свой узел и разово скачать чужой индекс, то это хуже, но тоже ок. В противном случае это ничем не отличается от DDG, кроме открытых исходников.
И наоборот, если с детства есть строгое разграничение между языками, употребление «иноязычных» слов будет самим ребенком расцениваться как «жульничество», к которому можно прибегать в исключительных случаях.
Видел заметку, кажется, педагога о том, что в его практике двуязычные дети, с которыми родители разговаривают строго на разных языках, не смешивают слова в речи и чётко различают «языковой режим» общения. Ссылку не дам, инфа не достоверная.
P.S. вопрос тем, кто в теме: билингвизм включает в себя суржик? То есть в ситуации, когда человек владеет языком (языковой системой), который отличает и от первого рассматриваемого языка, и от второго, можем ли мы его назвать билингвом?
Так, я начал примерно понимать, о чём Вы говорите по ответу про вершины графа.
Краткий пересказ линала про линейные оболочки
Допустим, у нас есть множество X, для простоты конечное. Мы не накладываем никаких ограничений на вид его элементов, а значит, элементами могут быть люди, города, вершины некоторого графа и пр.
Есть некоторое линейное пр-во L. Мы каким-то образом сопоставляем каждому элементу X какой-то вектор L. Если размерность L равна числу элементов X, а каждый элемент сопоставлен базисному вектору, то L является линейной оболочкой X и любой вектор L может быть представлен в виде линейной комбинации (образов) элементов X
.
Если же мы рассмотрим другое линейное пр-во L' меньшей размерности и так же сопоставим элементы X векторам L', элементы (точнее, образы элементов) станут линейно-зависимыми. Тогда некоторые элементы X будут линейной комбинацией других элементов, базисных в L'.
При этом из линейной оболочки L в произвольное линейное пр-во L' существует ровно одно линейное отображение, которое сохраняет сопоставления X в L и L'. Вы его называете проекцией.
Что ж, тогда остаётся открытым вопрос, насколько мы вправе называть линейную оболочку множества людей «линейным пр-вом людей», если не каждый вектор этого пр-ва может быть проинтерпретирован как человек, а только базисные.
P.S. Я не уверен, что понял первую часть Вашего ответа. По-видимому, её тоже надо понимать как определение линейного отображение линейной оболочки городов в малоразмерное линейное пространство, где Нижний Новгород (=его образ) линейно зависит от Москвы и Ижевска.
В любом случае, в моей речи «нескалярный» = «не являющийся скаляром и не обязательно являющийся вектором», а «многомерный» = «вектор, имеющий большую размерность»
Если Вася = (Петя + Сережа)/2, то можно оценивать характеристики Васи, если таковые известны для Пети и Сережи. Обычное аффинное пространство.
Это как раз понятно и я сразу отметил, что скалярные характеристики мы можем рассматривать как аффинные/векторные/… пространства. Но человек не есть его конкретная скалярная характеристика.
Во-первых, существуют нескалярные, например, если Петя пятипалый, а Серёжа шестипалый, то сколько пальцев у Васи? А если Вася = cos 30* Петя + sin 30* Серёжа?
Во-вторых, не хотелось бы сводить человека к набору его внутренних характеристик. У него есть и внешние характеристики, вроде социальных связей, отношение к книгам, писателям, любимые фильмы. Как в этом случае быть?
Графы задают не только линейное пространство, но и его метрические характеристики.
О метрике на графе я знаю, а о линейной структуре не слышал. Судя по всему, Вы таки рассматриваете сам конкретный граф как линейное пространство, а не семейство всех графов в целом. То есть Вы для произвольного графа как-то определяете 0 как выделенную вершину графа и линейную комбинацию вершин как вершину. Как Вы это делаете?
Я потому и потратил время на статью, чтобы изменить восприятие внешнего произведения как обобщения векторного.
Конкретно это получилось сделать плохо. Я дошел до антикоммутативности и подумал «о, разве у нас определено отрицание?», сразу после этого «откуда у нас взялся ноль?!», а на линейных комбинациях подумал «видимо, мы работаем в некотором линейном пространстве, значит, внешнее произведение — это что-то типа векторного».
Если это так, то как понимать умножение людей, если люди (именно люди, а не какие-то их числовые и векторные характеристики) не образуют линейное пространство (по крайней мере, которое бы имело сколь-угодно осмысленную бытовую интерпретацию)? Вот Вы графы упомянули, но они тоже не образуют линейное пространство и сами линейным пр-вом не являются. Как проинтерпретировать a+2b?
Если Вы сравниваете внешнее произведение со списком объектов, а алгебру с реляционной алгеброй, можно ли погрузить списковое программирование в эту теорию? То есть, если concat — это умножение, то как выглядят операторы filer, zip, inner join, transpose?
И ещё один вопрос-уточнение: следующие линейные комбинации существуют?
a + [ab] + [abc]
a + /a
Увы, не разумеется. По крайней мере мне исходный комментарий показался инфантильным и безответственным. Но раз Вы прояснили, что считаете бóльшей проблемой отсутствие вменяемой конкуренции среди наиболее важного для людей ПО, остаётся согласиться и прикладывать силы, чтобы её решить.
Если мы все начнем сейчас кликать «не принимаю», то корпорации вдруг одумаются.
А куда они денутся? Им прибыль нужна, то есть пользователи, что кликнули «принимаю».
Да, проблема, но она лежит в другой плоскости. Замечу, хоть это совсем не относится к делу, что много софта кроссплатформленного.
В данном случае ЛС играет примерно ту же роль, что стоимость или технические требования. Если ПО будет стоить дорого, Вы подумаете перед покупкой. Если ПО будет требовать вложений в технику и обслуживание, Вы подумаете перед покупкой. Ожидается, что если ЛС будет кабальной, Вы тоже подумаете перед покупкой. Конечно, если нет альтернатив, то Вы решите приобрести ПО, потратившись, вложившись и приняв ЛС, перед этим подумав.
Собственно, я исходно оспаривал тезис о том, что читать ЛС и думать совсем не надо. И предложил рассмотреть переход от одностороннего диктата продавца к лояльному ЛС как конкурентному преимуществу.
Пожалуй, можно было продолжить, потому что при правильном мышлении сначала читается ЛС и только затем принимается решение о том, ставить или не ставить ОС. В случае отказа, очевидно, потребуется искать альтернативу.
Если хотя бы большинство пользователей поступало так, лояльное ЛС стало бы дополнительным преимуществом продаваемого программного продукта и производители ПО стали бы конкурировать не только в области количества фич / размера комъюнити / качества инфраструктуры, но и лояльностью ЛС. Со временем, глядишь, и культура развилась бы, в которой иметь дело с собирающими персонифицированную информацию западло не комильфо.
Насколько я знаю, в большинстве логик ex falso quodlibet либо выступает, либо может выступать в качестве определения отрицания. Проще говоря, если для некоторой синтаксической конструкции -F имеет место правило вывода
посылка: F / заключение: -F → G
или аналогичная метатеорема, то этого достаточно, чтобы -F называть отрицанием F.
Мне вот, скажем, интересно, есть ли логики, в которых импликация (точнее, стрелочка) понималась бы как наличие причинно-следственной связи.
В ваших лентах уже собралось сотни(а то и тысячи) постов со спамом. И среди них затерялись полезные посты, которые скорее всего вы уже не прочитаете. Другое дело, RSS. Даже если несколько дней не подходить к компьютеру, RSS сервис соберет все в одном месте.
Можно по-подробнее объяснить, как RSS решает указанную проблему. Я как-то пробовал пользоваться RSS (кстати, начинал с liferea) и столкнулся с тем, что количество постов растёт невообразимо быстро, превращаясь в большую свалку. Решил, что мне проще поочерёдно зайти на каждый ресурс и просмотреть локальными средствами.
Как решаете эту проблему? методология, инструменты?
По-хорошему, проблема организации, управления и работы с вкладками (и такая же проблема с закладками) внешняя по отношению к функциям браузера. То есть она встаёт применимо к многим программам: просмотрщики pdf, изображений, текстовые редакторы, IDE и т.п.
Хотелось бы иметь единый инструмент, решающий эту общую задачу, причём универсально по UI/UX.
Причём потребность в этом давно чувствуется:
— браузеры уже и pdf научились в отдельной вкладке открывать (хотя казалось бы, просмотр pdf имеет такое же отношение к браузерам, как просмотр любого другого не-веб формата, например, dot, mp4, psd)
— панель вкладок сравнивается с панелью задач, хотя по сути они решают одну и ту же задачу (о чём свидетельствуют успешные попытки использовать несколько окон браузера), но на разных уровнях
Допустим, мы решим проблему вкладок в браузере. Как быть с той же проблемой в IDE? Каждой. Как быть с той же проблемой файловом менеджере?
Децентрализованный поиск так или иначе должен решать проблему доверия.
Перекладывать задачу индексации на поставщика контента неприемлемо, потому что поставщик — лицо, заинтересованное в привлечении посетителей больше, чем в достоверности индекса.
Кроме этого, необходимы механизмы исключения из распределённого индекса, по которому ведётся поиск конкретным узлом, узлов, которые могут индекс фальсифицировать. Однако эти механизмы, очевидно, не должны быть централизованными.
Также необходимы (не централизованные) механизмы обратной связи с фактическим пользователем, чтобы менять в поисковой выдачи позиции сайтов, написанный в худшем SEO-духе, корчевателей и прочие нерелевантные ссылки.
Говоря о YaCy, которым я недавно заинтересовался, он имеет проблемы с ранжированием поисковой выдачи. Даже если отбросить то, что общий индекс маленький и содержит преимущественно немецкий сегмент Интернета, YaCy имеет принципиальные ограничения в качестве выдачи, что делает её бесполезной для практического использования как универсального поисковика. Впрочем, для первого проекта это хороший результат.
Очень жаль, что в колонке «Поисковые системы» только один представитель. По моему мнению, в текущем состоянии развития Интернет-технологий и массовой вовлечённости людей, в т.ч. корыстных и прагматичных, отсутствие децентрализованного «окна в Интернет» свидетельствует о потрясающем человеческом пофигизме.
Я, прочитав о RON по ссылке, понял так, что это некоторая платформа, язык для использования CRDT, то есть он предоставляет, кроме прочего, некоторые средства обеспечения бесконфликтности. Прошу прощения за вопрос, кажется, мне следует больше почитать о нём.
В отличие от git, CRDT структуры данных всегда можно помержить автоматически. В остальном же, git — очень хороший пример для объяснения свойств CRDT хранилищ
Насколько я понял, CRDT — это тип-полурешетка. Если рассматривать предмет версионирования, рабочую директорию, то она относительно мержа не является полурешеткой из-за конфликтов слияния. Можно ли рассматривать сам репозиторий (только не git, а какой-нибудь патчевой СКВ, где конфликтное состояние является возможным состоянием) как CRDT относительно операции pull/push?
Что можно почитать насчёт того, как избегается проблема конфликтов в RON?
всё-таки вариант ничего не делать имхо хуже.
Впрочем, прошу уточнить, какие есть варианты действий отдельного не слишком богатого пользователя, чтобы продукт не умер?
Мне очень нравится идея использовать пароль, функционально зависящий от открытых статичных параметров сервиса (домен, например) и скрытых параметров. Функция составляется и запоминается единожды и не меняется во времени. О скрытых параметрах скажу ниже. Сам таким пользуюсь в половине случаев.
Из преимуществ:
— легко «вспомнить» пароль к сервису, о существовании которого ты давно забыл
— независимость от сторонних сервисов, программ, баз данных
При этом можно функцию выбрать достаточно нетривиальную, чтоб визуально не была видна шаблонность паролей (как в предложенной в статье схеме), даже если злоумышленник узнает несколько паролей от нескольких сервисов, но при этом достаточно лёгкую в практическом использовании.
Из недостатков:
— разные сервисы выставляют разные ограничения на вид пароля, иногда эти ограничения взаимно исключают друг друга. Например, один сервис требует, чтобы в пароле была хотя бы одна цифра и непечатный небуквенный знак, другой требует, чтобы пароль состоял только из букв латинского алфавита, третий — только из цифр, четвёртый — максимум 8 символов, пятый — минимум 6. Поэтому предложенная в статье схема не универсальна. Единственное решение — скрытые параметры. Например, добавляем некоторое число внутрь пароля, когда условия на пароль допускают наличие цифр, и не добавляем в противном случае. Очевидная проблема — нужно запоминать скрытые параметры. Скрытые параметры — зло, потому что их легко забыть и трудно подобрать, если это что-то сложнее одного-двух булевых флага.
— иногда сервисы или соображения безопасности требуют поменять пароль. Тогда номер пароля или дата смены выступает в качестве скрытого параметра, что тоже очень неудобно. Впрочем, из соображений безопасности лучше использовать специализированное ПО.
— иногда сервисы меняют название, домен или другие параметры, которые считались статичными при создании пароля. Тогда надо вспомнить старые значения этих параметров и, по возможности, поменять пароль. Неудобно.
Нет, yaml разрабатывался как надмножество json, то есть любой корректный json является корректным yaml. но не наоборот.
YAML can therefore be viewed as a natural superset of JSON, offering improved human readability and a more complete information model. This is also the case in practice; every JSON file is also a valid YAML file. This makes it easy to migrate from JSON to YAML if/when the additional features are required.
Хотя, в документации к yaml написано, что это не совсем так. Например,
JSON's RFC4627 requires that mappings keys merely “SHOULD” be unique, while YAML insists they “MUST” be. Technically, YAML therefore complies with the JSON spec, choosing to treat duplicates as an error.
Поэтому исходный вопрос не лишен смысла. Для ответа на него нужно посмотреть, как отреагирует docker-compose, если ему подсунуть
который корректный как JSON и некорректный как YAML.
Спойлер
Запустит node:11-alpine. Даже если переименовать docker-compose.json в docker-compose.yaml.
Видимо, авторам было не лень проверять, что отступы блоковых элементов должны обязательно быть пробелами, а не табуляцией, а на уникальность ключей, которая точно так же требуется форматом, все забили.
добавлю. Это не так. Только если Вы не сохраните целевой докер-образ в репозитории и будете его хранить 2 года. Спустя 2 года собрать докер образ из исходного Dockerfile по вполне понятным причинам будет невозможно
Вы совершенно правы. Это важный момент, который следует упомянуть в разделе «цена». Иначе воспроизводимость превратиться в тыкву.
Или под религией в тексте понимается философия?
Другое дело, что те, кто размещают систему у себя, могут быть нечистыми на руку. От банального «глупые людишки думают, что на наших серверах исполняется тот же код, что в репозитории», до любого middleware. Вопрос о техническом обеспечении анонимности доступа к ресурсу, конечно, интересен, но он лежит вне задач поисковой системы.
У меня, скажем, есть вопрос: возможно ли развернуть собственный узел этой поисковой системы и как будет этот узел взаимодействовать с другими? Если есть возможность развернуть и синхронизировать индекс, то ок, децентрализованная поисковая система нам нужна. Если можно развернуть свой узел и разово скачать чужой индекс, то это хуже, но тоже ок. В противном случае это ничем не отличается от DDG, кроме открытых исходников.
P.S. вопрос тем, кто в теме: билингвизм включает в себя суржик? То есть в ситуации, когда человек владеет языком (языковой системой), который отличает и от первого рассматриваемого языка, и от второго, можем ли мы его назвать билингвом?
Есть некоторое линейное пр-во L. Мы каким-то образом сопоставляем каждому элементу X какой-то вектор L. Если размерность L равна числу элементов X, а каждый элемент сопоставлен базисному вектору, то L является линейной оболочкой X и любой вектор L может быть представлен в виде линейной комбинации (образов) элементов X
.
Если же мы рассмотрим другое линейное пр-во L' меньшей размерности и так же сопоставим элементы X векторам L', элементы (точнее, образы элементов) станут линейно-зависимыми. Тогда некоторые элементы X будут линейной комбинацией других элементов, базисных в L'.
При этом из линейной оболочки L в произвольное линейное пр-во L' существует ровно одно линейное отображение, которое сохраняет сопоставления X в L и L'. Вы его называете проекцией.
Что ж, тогда остаётся открытым вопрос, насколько мы вправе называть линейную оболочку множества людей «линейным пр-вом людей», если не каждый вектор этого пр-ва может быть проинтерпретирован как человек, а только базисные.
P.S. Я не уверен, что понял первую часть Вашего ответа. По-видимому, её тоже надо понимать как определение линейного отображение линейной оболочки городов в малоразмерное линейное пространство, где Нижний Новгород (=его образ) линейно зависит от Москвы и Ижевска.
В любом случае, в моей речи «нескалярный» = «не являющийся скаляром и не обязательно являющийся вектором», а «многомерный» = «вектор, имеющий большую размерность»
Во-первых, существуют нескалярные, например, если Петя пятипалый, а Серёжа шестипалый, то сколько пальцев у Васи? А если Вася = cos 30* Петя + sin 30* Серёжа?
Во-вторых, не хотелось бы сводить человека к набору его внутренних характеристик. У него есть и внешние характеристики, вроде социальных связей, отношение к книгам, писателям, любимые фильмы. Как в этом случае быть?
О метрике на графе я знаю, а о линейной структуре не слышал. Судя по всему, Вы таки рассматриваете сам конкретный граф как линейное пространство, а не семейство всех графов в целом. То есть Вы для произвольного графа как-то определяете 0 как выделенную вершину графа и линейную комбинацию вершин как вершину. Как Вы это делаете?
Если это так, то как понимать умножение людей, если люди (именно люди, а не какие-то их числовые и векторные характеристики) не образуют линейное пространство (по крайней мере, которое бы имело сколь-угодно осмысленную бытовую интерпретацию)? Вот Вы графы упомянули, но они тоже не образуют линейное пространство и сами линейным пр-вом не являются. Как проинтерпретировать a+2b?
Если Вы сравниваете внешнее произведение со списком объектов, а алгебру с реляционной алгеброй, можно ли погрузить списковое программирование в эту теорию? То есть, если concat — это умножение, то как выглядят операторы filer, zip, inner join, transpose?
И ещё один вопрос-уточнение: следующие линейные комбинации существуют?
a + [ab] + [abc]
a + /a
А куда они денутся? Им прибыль нужна, то есть пользователи, что кликнули «принимаю».
В данном случае ЛС играет примерно ту же роль, что стоимость или технические требования. Если ПО будет стоить дорого, Вы подумаете перед покупкой. Если ПО будет требовать вложений в технику и обслуживание, Вы подумаете перед покупкой. Ожидается, что если ЛС будет кабальной, Вы тоже подумаете перед покупкой. Конечно, если нет альтернатив, то Вы решите приобрести ПО, потратившись, вложившись и приняв ЛС, перед этим подумав.
Собственно, я исходно оспаривал тезис о том, что читать ЛС и думать совсем не надо. И предложил рассмотреть переход от одностороннего диктата продавца к лояльному ЛС как конкурентному преимуществу.
Если хотя бы большинство пользователей поступало так, лояльное ЛС стало бы дополнительным преимуществом продаваемого программного продукта и производители ПО стали бы конкурировать не только в области количества фич / размера комъюнити / качества инфраструктуры, но и лояльностью ЛС. Со временем, глядишь, и культура развилась бы, в которой иметь дело с собирающими персонифицированную информацию
западлоне комильфо.посылка: F / заключение: -F → G
или аналогичная метатеорема, то этого достаточно, чтобы -F называть отрицанием F.
Мне вот, скажем, интересно, есть ли логики, в которых импликация (точнее, стрелочка) понималась бы как наличие причинно-следственной связи.
Как решаете эту проблему? методология, инструменты?
Хотелось бы иметь единый инструмент, решающий эту общую задачу, причём универсально по UI/UX.
Причём потребность в этом давно чувствуется:
— браузеры уже и pdf научились в отдельной вкладке открывать (хотя казалось бы, просмотр pdf имеет такое же отношение к браузерам, как просмотр любого другого не-веб формата, например, dot, mp4, psd)
— панель вкладок сравнивается с панелью задач, хотя по сути они решают одну и ту же задачу (о чём свидетельствуют успешные попытки использовать несколько окон браузера), но на разных уровнях
Допустим, мы решим проблему вкладок в браузере. Как быть с той же проблемой в IDE? Каждой. Как быть с той же проблемой файловом менеджере?
Перекладывать задачу индексации на поставщика контента неприемлемо, потому что поставщик — лицо, заинтересованное в привлечении посетителей больше, чем в достоверности индекса.
Кроме этого, необходимы механизмы исключения из распределённого индекса, по которому ведётся поиск конкретным узлом, узлов, которые могут индекс фальсифицировать. Однако эти механизмы, очевидно, не должны быть централизованными.
Также необходимы (не централизованные) механизмы обратной связи с фактическим пользователем, чтобы менять в поисковой выдачи позиции сайтов, написанный в худшем SEO-духе, корчевателей и прочие нерелевантные ссылки.
Говоря о YaCy, которым я недавно заинтересовался, он имеет проблемы с ранжированием поисковой выдачи. Даже если отбросить то, что общий индекс маленький и содержит преимущественно немецкий сегмент Интернета, YaCy имеет принципиальные ограничения в качестве выдачи, что делает её бесполезной для практического использования как универсального поисковика. Впрочем, для первого проекта это хороший результат.
Очень жаль, что в колонке «Поисковые системы» только один представитель. По моему мнению, в текущем состоянии развития Интернет-технологий и массовой вовлечённости людей, в т.ч. корыстных и прагматичных, отсутствие децентрализованного «окна в Интернет» свидетельствует о потрясающем человеческом пофигизме.
Спасибо, логично.
Что можно почитать насчёт того, как избегается проблема конфликтов в RON?
Впрочем, прошу уточнить, какие есть варианты действий отдельного не слишком богатого пользователя, чтобы продукт не умер?
Из преимуществ:
— легко «вспомнить» пароль к сервису, о существовании которого ты давно забыл
— независимость от сторонних сервисов, программ, баз данных
При этом можно функцию выбрать достаточно нетривиальную, чтоб визуально не была видна шаблонность паролей (как в предложенной в статье схеме), даже если злоумышленник узнает несколько паролей от нескольких сервисов, но при этом достаточно лёгкую в практическом использовании.
Из недостатков:
— разные сервисы выставляют разные ограничения на вид пароля, иногда эти ограничения взаимно исключают друг друга. Например, один сервис требует, чтобы в пароле была хотя бы одна цифра и
непечатныйнебуквенный знак, другой требует, чтобы пароль состоял только из букв латинского алфавита, третий — только из цифр, четвёртый — максимум 8 символов, пятый — минимум 6. Поэтому предложенная в статье схема не универсальна. Единственное решение — скрытые параметры. Например, добавляем некоторое число внутрь пароля, когда условия на пароль допускают наличие цифр, и не добавляем в противном случае. Очевидная проблема — нужно запоминать скрытые параметры. Скрытые параметры — зло, потому что их легко забыть и трудно подобрать, если это что-то сложнее одного-двух булевых флага.— иногда сервисы или соображения безопасности требуют поменять пароль. Тогда номер пароля или дата смены выступает в качестве скрытого параметра, что тоже очень неудобно. Впрочем, из соображений безопасности лучше использовать специализированное ПО.
— иногда сервисы меняют название, домен или другие параметры, которые считались статичными при создании пароля. Тогда надо вспомнить старые значения этих параметров и, по возможности, поменять пароль. Неудобно.
Хотя, в документации к yaml написано, что это не совсем так. Например,
Поэтому исходный вопрос не лишен смысла. Для ответа на него нужно посмотреть, как отреагирует docker-compose, если ему подсунуть
который корректный как JSON и некорректный как YAML.
Видимо, авторам было не лень проверять, что отступы блоковых элементов должны обязательно быть пробелами, а не табуляцией, а на уникальность ключей, которая точно так же требуется форматом, все забили.