Эх, ностальгия. Помнится, когда-то еще на 286 я написал простенький трехмерный движок, показывающий на CGA-мониторе динамически меняющуюся картинку из точек в узлах деформируемой пространственной сетки. Всё это работало в реальном времени, картинка выглядела вполне натурально, а код влезал в один килобайт.
Помимо прочего требовалось реализовать матрицу поворота. Ну, куда уж тут без тригонометрии. Понадобился косинус.
Для моих целей угол задавался одним байтом, и результат возвращался тоже в одном байте (был нормирован не на 1, а на 127). Для разрешения готовой картинки 320×200 этого было вполне достаточно.
Чтобы успевать обсчитывать несколько сотен точек за время одного кадра, вычисление синуса было реализовано как выборка из таблицы. Ее можно было посчитать заранее, но она получалась слишком большой — счет реально шел даже не на десятки байт, а на байты. Поэтому было принято решение генерировать таблицу в начале работы программы.
Вы будете смеяться, но для этой задачи точности генерации с помощью нехитрого выражения y=1−x² с какой-то нормировкой оказалось достаточно. Визуально вращение было вполне плавным — пиксели размером с кулак вносили превосходящую погрешность.
Когда я писал про timestamp при каждом запросе, имел в виду, конечно, не метку времени запроса, а метку времени последнего изменения запрашиваемого файла.
Например, у меня бэкэнд на РНР. Совсем статических страниц нет, поэтому при каждом запросе страницы nginx все равно лезет в РНР. Тот генерирует код страницы и отдает. Ну а раз уж он все равно это делает, то добавить к адресам скриптов и стилей '?'.filemtime($_SERVER['DOCUMENT_ROOT'].$file) недолго. Понятно, что два лишних запроса к файловой системе, но зато точно ничего не сломается.
Впрочем, я уже нашел, что некоторые CDN коряво кешируют запросы с параметрами, так что лучше использовать встраивание уникальной строки (метки времени или хеша) в имя файла или путь к нему. В целом справедливо, потому что сервер не обязан отдавать одинаковый контент на последовательные запросы даже с одинаковыми параметрами. Но то же самое относится и к любому другому контенту, даже к /, например. Поэтому надо внимательно думать над тем, как это будет работать в каждом конкретном случае. Что не меняет самой идеи: файл должен отдаваться всегда один (с последними изменениями), а URL должен меняться при изменении запрашиваемого ресурса.
А поясните, пожалуйста, подробнее. Похоже, я что-то упускаю. Мне кажется, что получить метку времени файла проще и быстрее, чем хеш или какое-то еще содержимое. При этом метка времени сохраняется на уровне файловой системы автомагически, то есть в такой схеме наименьшее количество точек отказа (способов наплодить баги). Какие преимущества у указанных вами методов?
А что мешает дописывать в URL скриптов и стилей конструкцию вида ?[timestamp] с меткой времени последнего изменения файла, получаемой в момент запроса? При перезагрузке страницы в браузере все изменившиеся ресурсы получают формально новый URL и подтягиваются с сервера. А сервер этот timestamp просто не учитывает.
Эх, чего только не подключали к букашке... У меня на 11М был приделан пресловутый AY-3-8910, и даже чего-то играл. Оценить, насколько хорошо, сейчас уже невозможно, но тогда казалось — очень круто!
Спасибо за сеанс ностальгии.
Ну и, отступая от темы, замечу, что к этим самым букашкам чего только не подключали. У меня исторически первым появился 5-дюймовый дисковод, и это был Прорыв. Все процедуры упростились, как тогда казалось, до предела.
Потом RDC хвастался ковоксом (да, мы даже были как-то мельком знакомы, хотя общество было крайне несвязным) и AY. Конечно, грузить музыку с дискеты — это был отдельный кайф.
А потом появились модемы («А вот юникс на букашке! — А чего такой медленный? — Так это же букашка!») и даже винчестеры (не помню, сколько в моем было мегабайт, но он был MFM, и влезало на него ВСЁ).
А потом как-то незаметно пришли «современные компьютеры».
Да, я просто дополнил картину, пользуясь удобным случаем. А исследование у вас получилось интересное, спасибо.
Относительно же вашего варианта использования могу сказать, что поисковики индексируют картинки не только на специальных «фотохостингах», но и вообще на всех сайтах, до которых могут дотянуться. Поэтому лучший фотохостинг — свой сайт. И совершенно не обязательно как-то специально заморачиваться его созданием, достаточно любого популярного движка на дешевом хостинге (плюс, конечно, регулярного бекапа на свой носитель). Можно и здесь, наверное, подобрать полностью бесплатные варианты, но они, увы, тоже подвержены полураспаду.
Преимуществ у своего сайта несколько: вы сами настраиваете, как хранятся картинки (в каком качестве отдаются посетителям, сохраняется ли оригинал), и можете снабдить их любым количеством метаданных — от простого вывода EXIF до собственноручно написанных заметок любого объема и содержания. А бекап обеспечивает надежность, если хостер сдохнет.
Нужно разделять как минимум три разных сервиса: архив (бекап), файлообменник и фотохостинг. Поскольку титульным был последний, с него и начну.
Фотохостинг нужен только для того, чтобы показать картинку на каком-то сайте, не предоставляющем возможности ее хранения. Таких, кажется, остается все меньше, и тема постепенно умирает, хотя и асимптотически. Можно предположить существование огромного количества малопопулярных проектов, владельцы которых не видят смысла обновлять функциональность. Фотохостинг «имеет право» портить контент пережатием — его задача не в сохранении оригинала, а в более или менее удобном показе в виде, доступном пользователю другого сайта для восприятия. Лично для себя я не вижу необходимости в использовании таких сервисов.
Файлообменник нужен для передачи файла в неизменном виде конкрентому пользователю или множеству пользователей, в ряде случаев неограниченному (по ссылке в публичном доступе). Файлообменники бывают с ограниченным и неограниченным сроком хранения. Поскольку мы все понимаем, что любой чужой сервис может в любой момент сломаться, не следует неограниченный срок хранения воспринимать буквально. Например, я предпочитаю для кидания файлов dropmefiles, который хранит их максимум две недели. Это удобно полным отсутствием неоправданных ожиданий.
Архив должен быть свой. Здесь масса решений, и начинаются они с пары одинаковых внешних дисков, на которых следует поддерживать идентичное содержимое. Как только один из них умирает (а это рано или поздно обязательно случится), покупается еще один, и на нем делается полная копия. Дешево, сердито, неудобно, но этими данными владеете вы. Это минимально допустимый вариант сколько-нибудь долгосрочного хранения.
Сложность организации своего архива может расти в зависимости от объема информации и требуемой функциональности. Например, у меня есть NAS, который виден из интернета, с RAID5 внутри. На нем хранится все, что «хорошо бы не потерять». За ~14 лет работы сдох один диск, который был заменен в течение пары часов, потом массив ребилдился сутки, и все снова работает.
Действительно ценные данные кладутся в отдельную шару на NASе, которая автоматически бекапится в два места — на внешний диск, лежащий рядом и подключенный через USB, и на другой сервер, расположенный физически в другом помещении. Внешний диск нужен для восстановления критически важных данных в случае полного отказа NAS, а другой сервер — на случай кражи, затопления, пожара и прочих стихийных бедствий. Конечно, полной гарантии сохранности данных такая схема не дает, но вероятность полной потери достаточно мала для моих целей.
Постоянно нужные данные хранятся на ноутбуке внутри директории, непрерывно синхронизируемой с NASом. Это дает быстрый доступ, в том числе оффлайн, и дополнительный «бекап», в роли которого выступает ноутбук.
Ценные данные также могут дублироватся в чужое облако, но только с целью упрощения доступа в случае отказа или недоступности своего NAS, а не с целью повышения надежности.
Наверное, излишне говорить, что данные, которые не должны попасть в чужие руки, должны быть зашифрованы, пароли должны быть надежными, а небезопасные протоколы отключены.
В начале нулевых я немного занимался этой темой в Институте кристаллографии РАН. Основной проблемой тогда были вычислительные мощности. Использовался классический «крокодил» в виде уравнения на полторы строки в научной монографии, кажется, даже именной, не помню уже. Вроде бы, преобразование Радона, но не уверен за давностью лет.
Мне удалось построить собственный алгоритм, который работал на два порядка быстрее и при определенных условиях (в частности, с достаточно большим количеством ракурсов) давал визуально вполне чистую картинку без сколько-нибудь заметных артефактов.
Потом тема как-то незаметно свернулась, но идея реализации никуда не делась. Даже интересно, был ли этот подход где-то применен на практике.
Я, например, на всех рабочих компах сотрудников поставил синхронизацию в реальном времени с файл-сервером компании, а на нем еженощный бекап в отдельное место. Доступ к своим данным на сервере имеет каждый сотрудник, к бекапам — только админ. Таким образом, если какие-то данные пережили ночь, они гарантированно осядут в бекапах, которые ротируются не раньше чем через 30 дней.
Если негодяй уволился, а перед тем потер всё своё и всё другое, до чего смог дотянуться (общие файлы), то у админа будет минимум месяц на то, чтобы это заметить и исправить, а потери в самом худшем случае ограничатся одним рабочим днем.
Ответы на типовые контрольные вопросы тем более легко узнать или подобрать. Это в принципе порочная практика, опускающая стойкость к взлому ниже плинтуса.
Это лечение симптомов, а не болезни. Было бы здорово взять и выслать всех спамеров на альтернативную планету, но мечты разбиваются о суровую реальность.
Только проблемы с ним, в том, что потом его никто не помнит.
Хуже то, что ответ гораздо легче подобрать (а то и нагуглить), чем даже не очень надежный пароль. Поэтому «секретные вопросы» — абсолютное, незамутненное зло. Читайте товарища Митника. Если у вас на каких-то сервисах это используется, рекомендую удалить как можно скорее.
По авторскому праву у меня есть личный опыт получения кругленьких сумм с крупнейших российских издательств за кражу моих фотографий. Ну как личный — дал юристу задание, он поработал, через некоторое время попросил проверить банковский счет и выплатить ему гонорар. Я понимаю, что в большинстве случаев так не работает, потому что юристов много, а хороших среди них мало. Но показываю, что так тоже можно.
И у 51%, и у 50%, и у 100%, и у 5% «качества» есть свои ниши. Я как раз не настаиваю на использовании какого-то конкретного значения, а рассказываю, в чем между ними разница. А дальше каждый подбирает оптимальное решение для своей задачи. И да, в статье эти «проценты» (на самом деле попугаи) упоминаются лишь вскользь, потому что за ними стоят более фундаментальные вещи, о которых я и рассказываю.
Эх, ностальгия. Помнится, когда-то еще на 286 я написал простенький трехмерный движок, показывающий на CGA-мониторе динамически меняющуюся картинку из точек в узлах деформируемой пространственной сетки. Всё это работало в реальном времени, картинка выглядела вполне натурально, а код влезал в один килобайт.
Помимо прочего требовалось реализовать матрицу поворота. Ну, куда уж тут без тригонометрии. Понадобился косинус.
Для моих целей угол задавался одним байтом, и результат возвращался тоже в одном байте (был нормирован не на 1, а на 127). Для разрешения готовой картинки 320×200 этого было вполне достаточно.
Чтобы успевать обсчитывать несколько сотен точек за время одного кадра, вычисление синуса было реализовано как выборка из таблицы. Ее можно было посчитать заранее, но она получалась слишком большой — счет реально шел даже не на десятки байт, а на байты. Поэтому было принято решение генерировать таблицу в начале работы программы.
Вы будете смеяться, но для этой задачи точности генерации с помощью нехитрого выражения y=1−x² с какой-то нормировкой оказалось достаточно. Визуально вращение было вполне плавным — пиксели размером с кулак вносили превосходящую погрешность.
Когда я писал про timestamp при каждом запросе, имел в виду, конечно, не метку времени запроса, а метку времени последнего изменения запрашиваемого файла.
Например, у меня бэкэнд на РНР. Совсем статических страниц нет, поэтому при каждом запросе страницы nginx все равно лезет в РНР. Тот генерирует код страницы и отдает. Ну а раз уж он все равно это делает, то добавить к адресам скриптов и стилей
'?'.filemtime($_SERVER['DOCUMENT_ROOT'].$file)недолго. Понятно, что два лишних запроса к файловой системе, но зато точно ничего не сломается.Впрочем, я уже нашел, что некоторые CDN коряво кешируют запросы с параметрами, так что лучше использовать встраивание уникальной строки (метки времени или хеша) в имя файла или путь к нему. В целом справедливо, потому что сервер не обязан отдавать одинаковый контент на последовательные запросы даже с одинаковыми параметрами. Но то же самое относится и к любому другому контенту, даже к /, например. Поэтому надо внимательно думать над тем, как это будет работать в каждом конкретном случае. Что не меняет самой идеи: файл должен отдаваться всегда один (с последними изменениями), а URL должен меняться при изменении запрашиваемого ресурса.
А поясните, пожалуйста, подробнее. Похоже, я что-то упускаю. Мне кажется, что получить метку времени файла проще и быстрее, чем хеш или какое-то еще содержимое. При этом метка времени сохраняется на уровне файловой системы автомагически, то есть в такой схеме наименьшее количество точек отказа (способов наплодить баги). Какие преимущества у указанных вами методов?
А что мешает дописывать в URL скриптов и стилей конструкцию вида ?[timestamp] с меткой времени последнего изменения файла, получаемой в момент запроса? При перезагрузке страницы в браузере все изменившиеся ресурсы получают формально новый URL и подтягиваются с сервера. А сервер этот timestamp просто не учитывает.
Эх, чего только не подключали к букашке... У меня на 11М был приделан пресловутый AY-3-8910, и даже чего-то играл. Оценить, насколько хорошо, сейчас уже невозможно, но тогда казалось — очень круто!
Спасибо за сеанс ностальгии.
Ну и, отступая от темы, замечу, что к этим самым букашкам чего только не подключали. У меня исторически первым появился 5-дюймовый дисковод, и это был Прорыв. Все процедуры упростились, как тогда казалось, до предела.
Потом RDC хвастался ковоксом (да, мы даже были как-то мельком знакомы, хотя общество было крайне несвязным) и AY. Конечно, грузить музыку с дискеты — это был отдельный кайф.
А потом появились модемы («А вот юникс на букашке! — А чего такой медленный? — Так это же букашка!») и даже винчестеры (не помню, сколько в моем было мегабайт, но он был MFM, и влезало на него ВСЁ).
А потом как-то незаметно пришли «современные компьютеры».
Да, я просто дополнил картину, пользуясь удобным случаем. А исследование у вас получилось интересное, спасибо.
Относительно же вашего варианта использования могу сказать, что поисковики индексируют картинки не только на специальных «фотохостингах», но и вообще на всех сайтах, до которых могут дотянуться. Поэтому лучший фотохостинг — свой сайт. И совершенно не обязательно как-то специально заморачиваться его созданием, достаточно любого популярного движка на дешевом хостинге (плюс, конечно, регулярного бекапа на свой носитель). Можно и здесь, наверное, подобрать полностью бесплатные варианты, но они, увы, тоже подвержены полураспаду.
Преимуществ у своего сайта несколько: вы сами настраиваете, как хранятся картинки (в каком качестве отдаются посетителям, сохраняется ли оригинал), и можете снабдить их любым количеством метаданных — от простого вывода EXIF до собственноручно написанных заметок любого объема и содержания. А бекап обеспечивает надежность, если хостер сдохнет.
Нужно разделять как минимум три разных сервиса: архив (бекап), файлообменник и фотохостинг. Поскольку титульным был последний, с него и начну.
Фотохостинг нужен только для того, чтобы показать картинку на каком-то сайте, не предоставляющем возможности ее хранения. Таких, кажется, остается все меньше, и тема постепенно умирает, хотя и асимптотически. Можно предположить существование огромного количества малопопулярных проектов, владельцы которых не видят смысла обновлять функциональность. Фотохостинг «имеет право» портить контент пережатием — его задача не в сохранении оригинала, а в более или менее удобном показе в виде, доступном пользователю другого сайта для восприятия. Лично для себя я не вижу необходимости в использовании таких сервисов.
Файлообменник нужен для передачи файла в неизменном виде конкрентому пользователю или множеству пользователей, в ряде случаев неограниченному (по ссылке в публичном доступе). Файлообменники бывают с ограниченным и неограниченным сроком хранения. Поскольку мы все понимаем, что любой чужой сервис может в любой момент сломаться, не следует неограниченный срок хранения воспринимать буквально. Например, я предпочитаю для кидания файлов dropmefiles, который хранит их максимум две недели. Это удобно полным отсутствием неоправданных ожиданий.
Архив должен быть свой. Здесь масса решений, и начинаются они с пары одинаковых внешних дисков, на которых следует поддерживать идентичное содержимое. Как только один из них умирает (а это рано или поздно обязательно случится), покупается еще один, и на нем делается полная копия. Дешево, сердито, неудобно, но этими данными владеете вы. Это минимально допустимый вариант сколько-нибудь долгосрочного хранения.
Сложность организации своего архива может расти в зависимости от объема информации и требуемой функциональности. Например, у меня есть NAS, который виден из интернета, с RAID5 внутри. На нем хранится все, что «хорошо бы не потерять». За ~14 лет работы сдох один диск, который был заменен в течение пары часов, потом массив ребилдился сутки, и все снова работает.
Действительно ценные данные кладутся в отдельную шару на NASе, которая автоматически бекапится в два места — на внешний диск, лежащий рядом и подключенный через USB, и на другой сервер, расположенный физически в другом помещении. Внешний диск нужен для восстановления критически важных данных в случае полного отказа NAS, а другой сервер — на случай кражи, затопления, пожара и прочих стихийных бедствий. Конечно, полной гарантии сохранности данных такая схема не дает, но вероятность полной потери достаточно мала для моих целей.
Постоянно нужные данные хранятся на ноутбуке внутри директории, непрерывно синхронизируемой с NASом. Это дает быстрый доступ, в том числе оффлайн, и дополнительный «бекап», в роли которого выступает ноутбук.
Ценные данные также могут дублироватся в чужое облако, но только с целью упрощения доступа в случае отказа или недоступности своего NAS, а не с целью повышения надежности.
Наверное, излишне говорить, что данные, которые не должны попасть в чужие руки, должны быть зашифрованы, пароли должны быть надежными, а небезопасные протоколы отключены.
В начале нулевых я немного занимался этой темой в Институте кристаллографии РАН. Основной проблемой тогда были вычислительные мощности. Использовался классический «крокодил» в виде уравнения на полторы строки в научной монографии, кажется, даже именной, не помню уже. Вроде бы, преобразование Радона, но не уверен за давностью лет.
Мне удалось построить собственный алгоритм, который работал на два порядка быстрее и при определенных условиях (в частности, с достаточно большим количеством ракурсов) давал визуально вполне чистую картинку без сколько-нибудь заметных артефактов.
Потом тема как-то незаметно свернулась, но идея реализации никуда не делась. Даже интересно, был ли этот подход где-то применен на практике.
Немного странно приводить caniuse скриншотами — пройдет совсем немного времени, и ситуация изменится. Вряд ли кардинально, но всё же.
В остальном — спасибо за статью. Особенно интересно про datalist.
Я, например, на всех рабочих компах сотрудников поставил синхронизацию в реальном времени с файл-сервером компании, а на нем еженощный бекап в отдельное место. Доступ к своим данным на сервере имеет каждый сотрудник, к бекапам — только админ. Таким образом, если какие-то данные пережили ночь, они гарантированно осядут в бекапах, которые ротируются не раньше чем через 30 дней.
Если негодяй уволился, а перед тем потер всё своё и всё другое, до чего смог дотянуться (общие файлы), то у админа будет минимум месяц на то, чтобы это заметить и исправить, а потери в самом худшем случае ограничатся одним рабочим днем.
Ответы на типовые контрольные вопросы тем более легко узнать или подобрать. Это в принципе порочная практика, опускающая стойкость к взлому ниже плинтуса.
«Офис и рабочие станции» из одного пункта, и тот — платный антивирус. Серьезно?
В других разделах тоже много интересного. Вы правда считаете, что это туториал по безопасности, а не вредные советы?
Это лечение симптомов, а не болезни. Было бы здорово взять и выслать всех спамеров на альтернативную планету, но мечты разбиваются о суровую реальность.
Хуже то, что ответ гораздо легче подобрать (а то и нагуглить), чем даже не очень надежный пароль. Поэтому «секретные вопросы» — абсолютное, незамутненное зло. Читайте товарища Митника. Если у вас на каких-то сервисах это используется, рекомендую удалить как можно скорее.
Самое интересное, что некоторые спираченные в свое время книги у них есть в каталоге, но «нет в продаже».
То есть с нормально замкнутыми контактами? Ну так они залипнуть могут.
По авторскому праву у меня есть личный опыт получения кругленьких сумм с крупнейших российских издательств за кражу моих фотографий. Ну как личный — дал юристу задание, он поработал, через некоторое время попросил проверить банковский счет и выплатить ему гонорар. Я понимаю, что в большинстве случаев так не работает, потому что юристов много, а хороших среди них мало. Но показываю, что так тоже можно.
И у 51%, и у 50%, и у 100%, и у 5% «качества» есть свои ниши. Я как раз не настаиваю на использовании какого-то конкретного значения, а рассказываю, в чем между ними разница. А дальше каждый подбирает оптимальное решение для своей задачи. И да, в статье эти «проценты» (на самом деле попугаи) упоминаются лишь вскользь, потому что за ними стоят более фундаментальные вещи, о которых я и рассказываю.
Кнопка может сдохнуть отдельно от всего остального.
«Для экстренной остановки хераборы разбить пульт».
Оказывается, такое уже сделали.