[WT] [Архив]  [Поиск] Главная Управление
[Совместно с Ычаном]
[Назад] [Вся нить] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 20450)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, OGG, PDF, PNG, PSD, RAR, SVG, SWF, TXT, XCF, ZIP размером до 5000 кБ.
  • Ныне 3113 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
153385789892.png-(34.48KB, 500×500, 410.png)
20450
No. 20450 watch    
После публикации исходников мы можем обсуждать доработку не только ранее общедоступных частей интерфейса, но и движка в целом.

Репозиторий: https://bitbucket.org/Therapont/fbe-410
1. Для ваших предложений предназначена ветка public.
2. Только администрация 410чана решает, что в этом движке надо, а что не надо. Соответственно, не стоит излишне пропихивать всякие там революционные идеи. Одобренные потенциальные изменения перечислены на багтрекере (записи, созданные владельцами репозитория).
3. Тестирование предложенных изменений и развёртывание принятых ведётся при наличии у администрации свободного времени на это. Обычно это делается по выходным.
4. Код выложен как есть. Никаких неопубликованных скрытых функций и частей не существует.

Предыдущая нить: >>17371
44 сообщений пропущено. Показаны 50 последних сообщений Развернуть все изображения
No. 20564    
153547104279.gif-(4.88MB, 1639×922, Suzumiya Haruhi no Yuuutsu - three years ago.gif)
20564
К >>20561 следует прибавить ещё два соображения, и прибавлю.

Во-первых, https://secure.php.net/manual/en/function.mime-content-type.php полагается на содержимое «magic.mime», а я не знаю, сколько ему лѣтъ. Может нечто вроде >>20551 быть, несколько лѣтъ без обновлений, и порождать подобные https://nowere.net/d/res/3573.html#4691 и https://nowere.net/d/res/3573.html#4695 ошибки распознавания WebM, напримѣръ, потому что этот формат новѣе.

Во-вторых, внутри функции «createThumbnail» поздновато заниматься анализом контента на соответствие расширению. Такой проверке мѣсто в методе «HandleUpload» у класса «Upload» в файле inc/classes/upload.class.php, и она там есть, хотя и несколько рудиментарная (ограничивающаяся вызовом функции «getimagesize»). Тѣмъ, кому сія рудиментарность не по нраву, придётся сочинить собственный патчъ для ея исправленія. К тому времени, когда «createThumbnail» вызывается, можно считать содержимое файла провѣреннымъ, и соответствие его расширению установленным достовѣрно, и на расширение ориентироваться. (По точно таким же соображениям коммит https://bitbucket.org/Therapont/fbe-410/commits/3355e9e1bb4bc267b6c21d3a6962cbfd993790ef пополняет метод «HandleUpload» проверкой видео через запуск «ffprobe» и последующим анализом результатов, производимым, так сказать, «с пристрастием» — после чего внутри функции «createThumbnail» запускает уж «ffprobe» без всякой проверки, съ полнымъ довѣриемъ к результатам.)
No. 20565    
Файл
удалён
>>20561
Ох, горюшко ты горе... Этот ЯП, похоже, проклят. Ладно, могу ещё понять, что со времён 5.3.0 до 2016 года семь лет был тупой баг в документации, когда при переносе модуля из пекла эту функцию пометили как deprecated (хотя мартыхи документацию обычно не читают, а всё, что реально deprecated, бросает E_DEPRECATED, если раньше не сегфолтится), и подобный вопрос, вброшенный в стадо, неизбежно порождал там срач.

Во-первых, ни один вменяемый разработчик полагаться на честность юзера и ловить сегфолты с RCE не будет. Ты никогда не задумывался, зачем в первых нескольких байтах пишут %PNG, яШяа, MZ, e.t.c.?
Во-вторых, со времён KDE 3.x файлы не обязаны иметь расширений чтобы корректно определяться KDE-шным проводником, поскольку mime.magic — часть NIX-подобных ОС, т.е. юзер в принципе не обязан именовать свои картинки по чужим правилам на прыщавом десктопе. In contrast, Винды, по крайней мере XP и ниже, полагаются на имена файлов, делегируя ответственность ассоциированному с расширением ПО.
В-третьих, есть такая штука, как валидация данных, особенно присланных непойми кем из интернета, особенно если предполагается последующая обработка этих данных на сервере. Хотя бы ради того, чтобы сервер в случае чего не упал.
In the fourth, the browser usually doesn't care about mime-types of transmitting files.
No. 20566    
153548259045.gif-(4.82MB, 391×220, Strike the Blood - that's all you wanted to a.gif)
20566
>>20565

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

А у нас такие особые юзеры, нечестность которых ограничивается постановкой некорректных расширений и не простирается на постановку некорректных байтов в начале файла, так что «mime_content_type() из Fileinfo» внезапно всех спасёт?

И ещё у нас есть пример того, как достигнуть сегфолт+RCE, скормив некорректный файл в GD в PHP, причём либо сразу в «getimagesize» такой сегфолт, либо «getimagesize» даже выдаст не FALSE и позволит сегфолт чуть позже устроить? Причём этот пример можно предотвратить именно благодаря некорректности байтов в начале файла?

> Ты никогда не задумывался, зачем в первых нескольких байтах пишут %PNG, яШяа, MZ, e.t.c.?

Да куда уж мне задумываться над такими высокими материями. Я и адрес https://secure.php.net/manual/en/function.mime-content-type.php в реплике >>20564 привёл без единой мысли: этот адрес просто выделился из организма на чистых инстинктах, всё равно что слюна у собаки Павлова или использование каменных орудий калифорнийскими каланами.

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

Есть такая штука, как повторение ранее изложенной мысли второй раз заново, только другими словами: вместо «ни один вменяемый разработчик полагаться на честность юзера не будет» пишешь «валидация данных, особенно присланных непойми кем из интернета», а вместо «ловить сегфолты с RCE» пишешь «сервер упал». И вот уж новый пункт готов, который «в-третьих», но который от «во-первых» ничем по сути не отличается, только слова другие. Это делает честь тезаурусу.

> In the fourth, the browser usually doesn't care about mime-types of transmitting files.

But when it does, that's https://en.wikipedia.org/wiki/Content_sniffing
No. 20567    
153551720647.gif-(4.86MB, 1212×682, Aldnoah_Zero - starfall and children.gif)
20567
По адресу https://gitgud.io/devarped/instant-0chan/commit/71aca5a666ef7bd069e8b4a59aba825f0c760988 с интересом наблюдал, как в instant-0chan прибавили (ещё 25 апреля) возможность вызова OptiPNG¹ для уменьшения объёма файлов PNG — однако же почему-то только для файлов, содержащих миниатюры, причём созданные не из GD.

Между тем хорошо извѣстно (или должно быть извѣстно), что нѣкоторые видеопроигрыватели (в частности, Media Player Classic Home Cinema) сохраняют кадры аниме в файлах PNG не очень эффективно, так что применение OptiPNG к такому файлу (а не к одной только миниатюре его) в момент загрузки файла на 410чан могло бы способствовать экономии мѣста на сёрверѣ.

Есть ли OptiPNG на сёрверѣ у 410чана? Если есть, то какой версии? Если нѣтъ, то нельзя ли поставить?

Какого мнѣнія держится администрация 410чана насчёт возможности употреблять OptiPNG, будет ли в список желаемых изменений (по адресу https://bitbucket.org/Therapont/fbe-410/issues?status=new&status=open расположенный) прибавлять эту возможность?

А как насчёт возможности загрузки нѣскольких файлов?

А как насчёт возможности указать вмѣсто файла нѣкій URL, ведущий на крупнофайловый хостинг (YouTube, Vimeo, Coub, IPFS, Dropbox, Mega, Google Drive, Яндекс.Диск, etc.)?

А как насчёт тэгов meta для Twitter Cards?²

А как насчёт предупреждающего надписывания видеозаписей, содержащих звук, но зато одновременного включения этого звука вместе с видеозаписью в момент первого же жмяка мышóю по миниатюре видеофайла?

____________

¹ http://optipng.sourceforge.net/

² Например, https://developer.twitter.com/en/docs/tweets/optimize-with-cards/overview/summary-card-with-large-image
No. 20568    
153552117213.jpg-(713.43KB, 1680×1050, 8b36967c7f437900635ee6adbdcf388b.jpg)
20568
>>20567
По всем позициям: не нужно.

А конкретно «Ютуб» в виде видосов тут всегда был и есть, просто мы его не используем.
No. 20573    
153581366957.gif-(17.22KB, 150×150, bg-transparent.gif)
20573
Посмотрел на создание превьюшек через ffmpeg — теряется прозрачность в gif.
No. 20574    
153582032946.gif-(4.84MB, 350×197, Strike the Blood - that's all you wanted to a.gif)
20574
По-видимому, наблюденіе >>20573 совершенно справѣдливо, и багъ https://trac.ffmpeg.org/ticket/6813 (или другой подобный) является первопричиною его.

У меня нѣтъ словъ, господа, для того, чтобы передать вамъ глубину моего разочарованія. До этого дня я имѣлъ основанія надѣяться на то, что ужасное качество миниатюръ гифовъ намъ удастся преодолѣть хотя бы уходомъ на «ФФмпэгъ», но это стремленіе оказалось цѣликомъ безплоднымъ.

Видъ ошибки, въ репликѣ >>19790 упомянутой, какъ бы говорилъ мнѣ, что нельзя и «ФФмпэгъ» считать совершенно свободнымъ отъ оплошностей, но могъ ли я предвидѣть такую-то глубочайшую хѣрню, доходящую по глубинѣ до вещей элементарнѣйшихъ, такихъ какъ обработка прозрачности? — никоимъ образомъ не могъ!

О, етить.
No. 20575    
153582342281.gif-(3.35MB, 1920×1080, не время сдаваться (FullHD FS).gif)
20575
Остаётся ли какой-нибудь разумный третий путь создания нормальных человеческих миниатюр GIFов?

Прежде всего: установлено ли на сёрвере у 410чана программное обеспéчение ImageMagick или GraphicsMagick? — и если да, то какой версии? — а если нѣтъ, то нельзя ли установить его?
No. 20576    
>>20575 Оба есть, 6.9.7.4, 3.25 (из стабильного дебиана)
No. 20577    
153585412211.gif-(1.82MB, 1920×1080, не время сдаваться (FullHD Bayer).gif)
20577
>>20576

Могу ли я считать, что порядок версий «6.9.7.4, 3.25» соответствует порядку упоминания ImageMagick и GraphicsMagick в моей предыдущей реплике?

Но тогда что такое «3.25», если по адресу http://www.graphicsmagick.org/ последней названа версия 1.3.30?

Может быть, GraphicsMagick 1.3.25?
No. 20578    
>>20577 Да, ошибка при копи-пасте. Версия GM 1.3.25.
No. 20579    
153587043787.7z-(29.20KB, example.7z)
20579
>>20578

Я проверил GraphicsMagick версии 1.3.25 у себя на Windows и убедился, что эта программа не умеет нормально генерировать анимированные миниатюры анимированных GIFов: они то подлагивают, то подёргиваются. Сочинять её поддержку я не стану.

Что же касается ImageMagick, то по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/22 поддержку этой программы я напилил.

Напоследок я должен сознаться, господа, что меня разочаровал расхваливаемый по адресу https://www.imagemagick.org/Usage/quantize/#dither_how алгоритм перераспределения ошибок вдоль кривой Гильберта, потому что на примере GIF-анимации, к реплике >>20577 приложенной, я убедился в склонности этого алгоритма к неспровоцированным однопиксельным выплескам цвета (по сравнению с результатами старого доброго алгоритма, предложенного Флойдом и Штейнбергом в 1976 году).

И сознаюсь.

К этому разочарованию я пришёл, когда подал вот какие двѣ команды:

convert "не время сдаваться (FullHD Bayer).gif"[0] -resize 200x200^> example.gif

convert "не время сдаваться (FullHD Bayer).gif"[0] -resize 200x200^> -dither FloydSteinberg exampleFS.gif

(Если будете повторять их не под Windows, то не позабудьте переменить «^>» на «\>».)

С результатами вы можете ознакомиться в прилагаемом архиве 7-Zip. В файле example.gif (по сравнению с контрольным exampleFS.gif по Флойду и Штейнбергу) на небе видны две дополнительные тёмно-синие точки, а несколько ниже — какие-то турбулентные завихрения на границе между небом и зарёю.

В итоге по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/22 я вызываю именно алгоритм Флойда и Штейнберга.
No. 20581    
153592255675.gif-(4.83MB, 334×188, locomotion.gif)
20581
Наступил понедельник 3 сентября 2018 года, первый понедельник нынешней осени. Настала пора огласить, с какими изменениями к лучшему 410чан встречает новую неделю, и оглашу.

Во-первых, создание миниатюр изображений возлагается теперь на программу ImageMagick, а не на библиотеку GD языка PHP. Это изменение должно принести нам рост качества результатов миниатюризации, особенно заметный в случае анимированных GIF, содержащих узоры Байера, для которых предшествующий алгоритм создавал довольно досадные низкокачественные миниатюры с резкими изменениями цвета, происходившими в шахматном порядке. Пример прилагаю.

Во-вторых, выявлена и обойдена та проблема, ввиду которой во браузере Mozilla Firefox ещё сохранялся упомянутый в финале реплики http://410chan.org/dev/arch/res/17371.html#20260 недостаток, свойственный первому поколению развёртывателей миниатюр, то есть сохранялась задержка между жмяком мышóю по миниатюре и началом полноразмерного отображения — задержка, равная промежутку времени между отправкою запроса на сёрвер и началом поступления первых пикселов с сайта. (Для устранения этой задержки теперь миниатюра делается не фоном полноразмерной иллюстрации, а второю иллюстрациею, растянутою до того же размера да подложенною под неё, как на Архиваче.

Исключением по-прежнему являются файлы GIF, для которых такого подкладывания не происходит по причинам, изложенным в реплике http://410chan.org/dev/arch/res/17371.html#20261 под конец её.)
No. 20583    
15359489873.gif-(4.79MB, 1920×1080, Carnival Phantasm OP - baffled Rin.gif)
20583
Можетъ ли кто-нибудь понятно объяснить мнѣ, какимъ образомъ получилось такъ, что даже измѣненія https://bitbucket.org/Therapont/fbe-410/commits/0f1aa5969812263c8645707004c7cfa31086bac7 въ кодѣ на сёрверѣ не привели къ устраненію ошибки, по адресу http://410chan.org/dev/arch/res/17371.html#18031 обнаруженной?
No. 20585    
153597896294.png-(30.01KB, 300×340, KO.png)
20585
Если администрации нужна какая-нибудь помощь по допиливанию исходного кода видеообработчика, то давайте, по крайней мѣрѣ, поговорим об этом поподробнее.
No. 20586    
>>20585
Пока не тестировали этот код, так что и говорить нечего.
No. 20588    
>>20586 Код пока на локалхосте тестируется.
No. 20591    
153602439576.png-(99.56KB, 788×849, Patreon.png)
20591
>>20503

> Самое удобное в патреоне для чанеров, что делать пожертвования можно анонимно.

Разве анонимно? Если на странице https://www.patreon.com/saucenao я нажимаю кнопку «BECOME A PATRON», то оказываюсь переброшенным на страницу https://www.patreon.com/bePatron?c=130578 с приглашением ввести желаемый размер пожертвования, но затем (после нажатия на кнопку «CONTINUE») — на страницу https://www.patreon.com/join/saucenao/signup с приглашением либо регистрироваться, либо через Facebook заходить. Сие не анонимно.
No. 20593    
>>20591
Регистрироваться действительно необходимо, тем не менее само пожертвование можно сделать анонимно.

https://patreon.zendesk.com/hc/en-us/articles/203913579-Can-I-be-anonymous-

>We want you to be whoever you want to be, as long as you provide your real payment info.

Стоит заметить, что патреон также позволяет использовать для пожертвования пейволл, типа того же paypal.

Чтобы пожертвования не было видно:

https://patreon.zendesk.com/hc/en-us/articles/204694855-What-does-it-mean-if-my-account-is-private-

Впрочем, если это всё муторно, можно просто сделать в банке обезличенную карту, и потом пожертвовать с этой карты через интерфейс яндекс денег.
No. 20618    
По работе видосов замечаний пока нет, но на данный момент требуется синхронизировать ветку public-webm с изменениями, принятыми в public.
No. 20619    
153651633761.jpg-(455.83KB, 1386×1969, C64IhZ9VAAEpVuF.jpg)
20619
>>20618
> замечаний пока нет
А, нет, есть. При попытке запостить ogv выдает "Filetype tampering detected"

И да, не помню точно, сделано ли, нужно отсекать видео с двумя и более видеотреками. А то напостят.
No. 20622    
153654610513.jpg-(2.66MB, 1240×1754, Our Lady of Perpetual Help (danbooru 2992019).jpg)
20622
>>20618

Запрос на синхронизацию по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/24 отправлен.

>>20619

Прошу выложить пример OGV, которым это достигнуто, так как собственными примерами OGV не располагаю.

P. S.   А у нас точно есть намерение поддерживать заливку видео OGV, а не одних только WebM и MP4?
No. 20624    
>>20622
>OGV и WEBM как минимум, а также MP4
https://bitbucket.org/Therapont/fbe-410/issues/15/
No. 20625    
そですか。
No. 20626    
153681203436.jpg-(205.85KB, 811×1140, Жив Господь!.jpg)
20626
>>20619

По адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/24 прибавил два коммита, которые должны устранить ошибочное появление сообщения «Filetype tampering detected» и исключить возможность загрузки таких видеофайлов, в которых число видеодорожек отличается от единицы.

Проверяйте.
No. 20628    
153690822183.gif-(1.95MB, 450×450, yellow vortex.gif)
20628
Кстати, если есть какие-нибудь другие интересные пожелания, порождённые опасением «а не то напостят», то не стесняйтеся как можно ранее высказать и их — например, чтобы и их можно было сразу реализовать на нынешней неделе, если удастся.

Нужно ли проверять, какая https://ru.wikipedia.org/wiki/Цветовая_субдискретизация используется в видеозаписи, и запрещать видеоролики, в которых она не соответствует схеме 4:2:0? Если не запрещать их, то напостят пренепременнейше.

Нужно ли запрещать видео, у которого количество звуковых каналов в звуковой дорожке равно не 1 (моно) и не 2 (стерео), а больше (квадрозвук, или surround sound, или что-то другое в этом же роде)? Если не запрещать, то можно быть совершенно уверенными, что напостят, да ещё в дополнительных звуковых дорожках будут ругаться по матери и по Путину, а модератор не услышит, модератор пропустит.

Нужно ли ограничивать размер кадра снизу (чтобы не напостили слишком небольших) или сверху (чтобы не напостили слишком больших)? А не то беспременно напостят ведь!

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

А как насчёт частоты дискретизации звука: 48000 раз в секунду — это ещё ok, или надо не более 44100? Любители тёплого звука напостят, это они умеют.

Нужно ли проверять в случае MP4, какой из аудиопрофилей https://en.wikipedia.org/wiki/MPEG-4_Part_3#Audio_Profiles используется, и запрещать те видеоролики, в которых он сложнее AAC LC? А не то их напостят, а у кого-то тупой мобильник декодировать не потянет!

Нужно ли проверять https://en.wikipedia.org/wiki/Pixel_aspect_ratio и запрещать видеозаписи с неквадратными пикселами? А не то найдутся и таковские, которые их напостят, чтобы у добрых людей видео перекосило!

Нужно ли принимать видеоролики только с восьмибитными пикселами, а с десятибитными запрещать? Если не запретить, то закономерно напостят десятибитных — хотя бы оттого, что станут десятибитное аниме конвертировать без умаления глубины цветности.

Нужно ли проверять, используется ли https://ru.wikipedia.org/wiki/Прогрессивная_развёртка в видеоролике, и запрещать те, в которых развёртка чересстрочная? А не то ретроанимешники напостят, да и как им тогда было бы не напостить.

Если всѣ эти идеи станут постепенно возникать въ умѣ и высказываться по одной в неделю, и если после каждой идеи страшная догадка «а не то напостят» (впрочем, вполне закономерная, потому что действительно же напостят ведь, это и к гадалке не ходи) начнёт тягостно волновать душу и тормозить внедрение видеовозможностей на 410чане, то тогда можно по календарю догадываться, что видеофайлов на 410чане мы и до второй половины ноября не увидим (и это ещё в лучшем случае!), так что предлагаю администрации сразу высказаться о каждой из них.
No. 20629    
>>20628
Не знаю, видел ли ты это, но Якуй не осилил: https://files.catbox.moe/7o4xyh.mp4 https://files.catbox.moe/a96733.mp4 https://files.catbox.moe/j8n6qg.mp4
No. 20631    
153693472828.gif-(4.85MB, 658×370, Isekai Maou to Shoukan Shoujo no Dorei Majutsu - l.gif)
20631
>>20629

Разумеется, всѣ эти файлы я видел: реплики http://410chan.org/dev/res/17371.html#18841 и http://410chan.org/dev/res/17371.html#18855 и http://410chan.org/dev/res/17371.html#18857 об этих файлах, оставленные зимою нынешнего года, принадлежат мнѣ.

Не увѣренъ, что значит «Якуй не осилил», но нынешний код FBE (из ветки public-webm) запрещает публикацию файла https://files.catbox.moe/7o4xyh.mp4 (так как файл настолько битый, что FFmpeg отказывается сделать из него миниатюру), а два других принимает.

Так как по адресу http://410chan.org/dev/res/17371.html#18857 я упоминал способность браузера Mozilla Firefox невозбранно (и безглючно) открывать эти два другие файла, то я пока не вижу никакой особенной проблемы в их публикации. По адресу http://410chan.org/dev/res/17371.html#18855 я сообщал уж, что считаю делом браузера готовность открыть видеофайл (или готовность с ошибкою отказаться открывать его), как это и с неподвижными картинками случается.
No. 20636    
15370964794.png-(2.92MB, 1920×1080, Inu to Hasami wa Tsukaiyou - maid, broom.png)
20636
Около десяти минут тому назад исходный код из ветви public-webm был слит в ветвь public.

Это явный знак, позволяющий с изрядною уверенностью утверждать, что администрация 410чана начинает окончательное (предстартовое) тестирование видеохостингового исходного кода.

Возрадуйтеся!
No. 20638    
Опечатка: посты с webm (и т.п.) без превью в rss. Посты с картинками показывает нормально.
No. 20639    
Прошу применить поправку https://bitbucket.org/Therapont/fbe-410/pull-requests/25/ для коррекции стилей медиапроигрывателей.
No. 20640    
>>20638

Там не опечатка, а логическая ошибка автора движка, допущенная в файле inc/classes/rss.class.php на строке 50.

Нельзя просто приписать букву «s» в конце имени файла (перед точкой и расширением) и переменить название его папки «src» на «thumb» и надеяться, что получится адрес миниатюры. Это и раньше работало только с картинками, а с некартиночными файлами не работало и работать не могло, так я это понимаю.
No. 20641    
>>20639 ok.
No. 20642    
153714175641.gif-(292.22KB, 800×733, 1162238297671.gif)
20642
>>20638>>20640
Но это не значит, что это не может быть починено. Сделал PR.
И прошу прощения за продолжительное отсутствие.
No. 20643    
>>20638
У меня с какого-то обновления вообще всё без превью. Учитывая что читалка ревностно относится к стандартам, проблема таки на автобусе.
No. 20645    
153725474896.png-(119.12KB, 742×754, Cloudflare IPFS 150+ data centers.png)
20645
Cloudflare по адресу https://blog.cloudflare.com/distributed-web-gateway/ объявляет о начале поддержки IPFS и о запуске расположенного по адресу https://cloudflare-ipfs.com/ собственного гейта.

По адресу https://www.cloudflare.com/distributed-web-gateway/ сообщается, что кэширование контента IPFS происходит более чем на полутора сотнях дэйтацентров Cloudflare. (Скриншот прилагаю.)

С учётом вновь открывшихся обстоятельств не пожелает ли администрация 410чана пересмотреть ранее данный отрицательный ответ >>20568 на вопрос >>20567 о возможности указать вмѣсто файла такой URL, который вёл бы в IPFS?
No. 20646    
>>20645
Вы и так можете указывать любой URL, который не внесён в спамфильтр.
Умерьте пыл. Тут имиджборд, а не файлообменник.
No. 20647    
>>20646
Так понял, Мицгол предлагает использовать как файлообменник как раз не Автобус, а Флару, на Автобусе же контент только подгружать с неё.
No. 20649    
153727062496.jpg-(1.25MB, 3914×3250, Dream with your eyes open.jpg)
20649
>>20647

Закономерные события рано или поздно происходят. Со временем так или иначе Соусов поймёт, что двух небольших команд, поданных в консоли, вполне достаточно, чтобы архив его стрима сохранялся не только пару недель на «Твиче», но и неограниченно долго в IPFS (и открывался в уютном видеопроигрывателе рядом с репликою на имиджборде, если в имиджборде заложена поддержка IPFS, а результат этих команд запостили); если интересно, то вот пример таких двух команд для архива №310805212:

youtube-dl https://www.twitch.tv/videos/310805212

ipfs add -w "Унылый фанарт-v310805212.mp4"

No. 20650    
>>20649
Вот, что думаю: а нельзя ли полностью всю статику в ИПФС перенести, поставив демона на сервере? Это же огромная экономия места получится.
No. 20654    
153728455986.png-(675.15KB, 1114×1600, Kanojo wa Rokurokubi screenshot 1.png)
20654
>>20650

Если поставить демона на сервере и перетащить на сервере всѣ статические файлы из обычной файловой системы в P2P-распределённую систему IPFS, то экономии места не получится (файлы придётся и дальше в IPFS держать, чтобы был хоть один надёжный источник их для P2P). Зато получится экономия траффика и притом ещё достижение ≈100% аптайма, но для того и для другого непременно потребуется, чтобы для WWW хостом файлов указан был не 410чан, а IPFS-гейт Cloudflare.

Если в довершение к этому всё-таки нужна и экономия места на сервере, то её можно достигнуть, например, если статические файлы сохранять (для раздачи их в IPFS) не на сервере у 410чана, а под кроватью у админа на отдельном сервере, который дешевле в обслуживании и от которого не потребуется 100% аптайма. Или, например, если хранить статические файлы всё-таки на сервере в IPFS, но зато после отправки обсуждения в архив стирать всѣ статические файлы, обсуждением употребляемые, тем самым полагаясь на то, что за время жизни обсуждения эти файлы осели в нескольких копиях у читателей (на их собственных, читательских, демонах IPFS; конечно, для того наперёд надо пропагандировать и среди читателей готовность установить IPFS в их системы и притом ещё пропагандировать готовность дополнительно установить также и расширение https://github.com/ipfs-shipyard/ipfs-companion во браузеры, способствующее локальному кэшированию P2P-распределённого контента для последующей раздачи в IPFS) — тогда размер необходимого места на сервере стабилизируется в объёме активных обсуждений, а не будет неуклонно возрастать со временем по мере архивации прежних обсуждений. Это также экономия.

(Можно и комбинировать эти приёмы — например, архив отправлять на выделенный IPFS-сервер к админу под кровать, не полагаясь на одних читателей.)
No. 20655    
>>20654
Идея скорее в недобросовестном использовании предоставляемых Клаудфларой возможностей. А именно того, что они на своих серверах будут кешировать контент, слитый на их гейт. Опять же если я не Мугичкой поперёк прочитал.
То есть можно заливать статику на сервер, скидывать через ИПФС в гейт Флары, держать до какого-то момента, пока контент не закешируется на их серверах, после чего удалять со своего. Вопрос остаётся в доверии Фляре и её надёжности.
В конце концов, поднятие зеркала борды посредством проксирования её через Фляру тоже не очень честно по отношению к последней. Хотя такая практика имела место быть, пока кое-где не появилось хттпс с сертификатом LE.
No. 20656    
>>20655
Ты слишком lawful человек, если задумываешься о честности по отношению к этому крышевателю, подминающему под себя Всемирную паутину.
No. 20657    
>>20656
Если бы был lawful, то вообще не возникло бы идеи. Так я только за эксплуатацию корпораций.
No. 20663    
153734160124.png-(2.28MB, 1920×1040, Mononoke Hime.png)
20663
>>20655

> Идея скорее в недобросовестном использовании предоставляемых Клаудфларой возможностей. А именно того, что они на своих серверах будут кешировать контент, слитый на их гейт. Опять же если я не Мугичкой поперёк прочитал.

> То есть можно заливать статику на сервер, скидывать через ИПФС в гейт Флары, держать до какого-то момента, пока контент не закешируется на их серверах, после чего удалять со своего. Вопрос остаётся в доверии Фляре и её надёжности.

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

Другое дело, что и Cloudflare не обещает держать контент на их 150+ серверах неограниченно долго. Да они, небось, и не смогли бы, так как вряд ли их кэш способен целиком вместить всё содержимое файловой системы IPFS (летом прошлого года в файле https://cloudflare-ipfs.com/ipfs/QmWimYyZHzChb35EYojGduWHBdhf9SD5NHqf8MjZ4n3Qrr/Filecoin-Primer.7-25.pdf на тринадцатой странице было сказано, что число файлов в IPFS ещё тогда превысило пять миллиардов). Это не вопрос доверия к Cloudflare, а вопрос арифметики: каков средний размер файла в IPFS? — какой объём получится, если сперва помножить на пять миллиардов, а затем на вероятность попытки скачать файл именно через гейт Cloudflare (вероятность, возрастающую вместе с популярностью гейта по мере распространения свѣдѣній о нёмъ)?

Вот почему в предшествующих репликах я не рассматривал вопрос о стирании файла сразу после гейтования его на Cloudflare, а рассматривал только две альтернативы: «у админа под кроватью» (дешёвое централизованное хранение с необязательным аптаймом) и «у читателей» (ещё менее надёжное, зато децентрализованное, хранение, но полагающееся на распространённость употребления читателями на их компáх и самогó софта IPFS, и расширения IPFS Companion).

Если обе эти альтернативы представляются малопривлекательными, то можно ещё у Cloudflare по адресу https://developers.cloudflare.com/distributed-web/ipfs-gateway/connecting-website/ прочесть о третьем варианте: есть серверы, предлагающие хранение файлов в IPFS в качестве платной услуги. Среди них там упомянуты два: http://ipfsstore.it (который, по-видимому, от упоминания на Cloudflare сразу и лёг) и https://www.eternum.io (который не лёг и предлагает хранение в IPFS по цене 30 центов за гигабайт в месяц, что по нынешним временам означает рублей двадцать с копейками).

Я допускаю, впрочем, что этот последний вариант покажется ещё менее привлекательным (и даже грабительским), так как с калькулятором в руках кто угодно может сосчитать (а некоторые и без калькулятора, то есть устным счётом или вообще въ умѣ), что 30 центов за гигабайт означает 12 баксов за 40 гигабайтов, тогда как по адресу https://www.leaseweb.com/cloud/virtual-server можно арендовать сорокагигабайтовый VPS за пять евро (а это явно дешевле), после чего останется только самостоятельно поставить на него демон IPFS и запустить. Я привожу Leaseweb просто в качестве наиболее наглядного примера, так как для IP-адреса 410chan.org (95.211.122.44) https://ru.wikipedia.org/wiki/Обратный_просмотр_DNS выдаёт имя «hosted-by.leaseweb.com».
No. 20664    
153734175396.png-(7.12KB, 200×200, 410chan-spoiler.png)
20664
Если изложенное в реплике >>20663 покажется слишком сложным или порождающим невыносимые мýки выбора, то вдобавок я сейчас ещё раз напомню, что суть моего-то собственного предложения состояла не в том, чтобы сервер и администрация 410чана задумались над собственным идеалом сохранения статических файлов в IPFS, а в том только, чтобы наряду с публикацией файла на имиджборде существовала и возможность приложить к реплике IPFS-адрес от файла, заранее кем-то ужé опубликованного в IPFS.

Откуда такой адрес возьмётся? — нетрудно предположить (и предполагаю), что большинство таких публикаторов в качестве необходимого для P2P источника файла употребят, вероятно, либо установку IPFS на один из собственных многотерабайтных дисков (так как у типичного любителя аниме всегда есть ведь пара-тройка-другая многотерабайтников, не всѣ из которых забиты до конца, причём совокупная ёмкость таких отщипленных за ненадобностью остатков всегда будет больше того объёма, который администрация сайта сумеет централизованно арендовать), либо воспользуются подобными http://ipfs.stadja.net/upload/ интерфейсами для выкладывания файлов в IPFS, совершенно бесплатными, но зато нисколько не гарантирующими срок (и даже факт) хранения — а затем станут полагаться на то, что среди читателей 410чана отыщется достаточно пользователей IPFS Companion для того, чтобы файл сохранялся и у читателей столь же долго, сколь долго он остаётся реально нужным 410чановской публике.

Конечно, для таких файлов сайт 410чана, в общем случае, не станет создавать миниатюру, а оттого принуждён будет указать какую-нибудь общую на всех заглушку с надписью «IPFS». Сейчас такое кажется непривычным, но такое впечатление не будет существовать вечно; напротив, можно догадываться, что после устранения проблемы, по адресу https://bitbucket.org/Therapont/fbe-410/issues/8 обозначенной, на 410чане появятся заглушки спойлеров (пример прилагаю), после чего общественное сознание скоро привыкнет, что миниатюра может и не соответствовать содержанию файла.

Не могу совершенно исключать даже и того, что в дальнейшем можно будет напилить и некий цикл «скачать ➡️ миниатюризировать ➡️ стереть скачанное, начать использовать миниатюру» для тех из хранимых в IPFS файлов, которые не превосходят некоторого доступного на сервере объёма, необходимого для краткого сохранения их после скачивания из IPFS через гейт.
No. 20665    
>>20663
Жаль, что нет точных сроков или алгоритма выбора удаляемых из кеша ИПФС Флары, но если предположить самый вероятный из, то, скорее всего, большие файлы будут храниться совсем недолго, а вот небольшие — достаточно. Насколько помню, те же сайты, которые задудосили со стороны хоста, если Флара закешировала, то с месяц-два могла одна версия висеть. Не знаю, как сейчас, но можно выявить экспериментным путём сей алгоритм хранения и удаления, после чего можно написать скрипт, что будет дёргать файлы из кеша в момент протухания на Фляре, ждать, пока снова не закеширует и обратно удалять.
No. 20666    
153734374828.png-(101.51KB, 1459×657, сотона.png)
20666
>>20665

А вот это ужé опасно к https://en.wikipedia.org/wiki/Tragedy_of_the_commons приближается.
No. 20667    
>>20666
Вот потому и говорил, что вовсе не lawful. В конце концов, китайцы убивают много более достойные ресурсы альтруистов, желавших сделать великое добро для человечества, терабайтами трафика, а тут считай корпорация с некислой монетизацией. Это как паразитировать на Гугле — если и заметят маленький зуд с их масштабами, то очень нескоро, как было с хостившими на Драйве порнуху годами.
No. 20671    
15376843362.jpg-(195.69KB, 1500×1125, Dlx-MAsU8AAscWv_jpg:large.jpg)
20671
Одновременно со вчерашними и сегодняшними переделками на сервере, Автобус двинул на PHP7.
Удалить сообщение []
Пароль  
[Mod]