Днесь четвёртое число десятого месяца (4.10), в Японии известное также как «天使の日», что хорошо подходит для очередного чифира нашей авторской передачи «Тестируем мїкрофѡн на Радиё 410». Всё как всегда: буду разговаривать с нитью, реквестов нѣтъ, виабушная музыка. http://radio.410chan.ru:8000/radio Начало где-то после 21:30 по UTC+3. Чифирохранилище: http://coyc.net/radio.php Забашлять денег: http://coyc.net/donation.php
Соус, Макрос 1983 года так и не посмотрел так и не посмотрел?
>>165162 Можно Tomorrow с ычана перенести, если хочется.
Соус, может тогда напишешь в нубтайп-вики статью про старый ычан?
Не печалься, мы тебя любим!
Про интересных ычанек статью напиши.
Если макуросс тебя интересует не с археологической точки зрения, то, мне кажется, лучше посмотреть DYRL. Мувик красивый и суть передал удачно.
>>165165 Ну, >>165162 предлагает заслать пулреквест
>>165169 > DYRL Я предлагаю 36 серий посмотреть.
>>165169 Лучше Крашер Джо тогда посмотреть вместо Макуросса
А Initial D смотрел?
Существует ли статистика частоты использования разных встроенных стилей?
Перевод полнометражки Арии выходил летом. Не смотрел такой-то лучший слайс?
Уже поздно. Спокойной ночи!
В чём твой секрет неугасания интереса к аниме за столько-то лет?
Назови худший сезон аниме в твоей жизни
Можно не заливать, существуют разные DLNA-серверы, можно установить на пекарню и стримить внутри локалки, почти как "СМОТРЕТЬ АНИМЕ ОНЛАЙН БЕСПЛАТНО", только лучше.
А я чувствую поколенческий разрыв с героями аниме.
Нет есть один момент, что например количество фантастических тайтлов резко упало с нуцлевых, а это основная аудитория еще в 90-е и ранние нулевые.
Самая для меня загадка - это личности, которые аниме не смотрят в принципе, но при этом как-то около да вокруг ходят. Например, косплеем увлекаются или смотрят витубиц (клипами, конечно).
>>165182 Надо воскресить нашего хранителя нарративов.
>>165182 В 2021 году аниме существуют не само по себе, а является важной частью Интернет-культуры.
>>165184 Мейнстрим да.
>>165180 Чиочую. Онизуке, на секундочку, было 22, а гинтоки, например - 23. И когда-то я искренне считал их стариками.
>>165185 Ну конечно можно смотреть лютотрешайший трусняк (в ычанском /a/ были треды), но зачем?
>>165186 Время нас не щадит
>нечего стримить Скайрим уже удалил?
>>165189 И Дисгию не установил.
Спасибо!
Хорошая песня.
ｷﾀ━━━(ﾟ∀ﾟ)━━━!!
Shirasawa Rie - Onna no Ko tte Maji Cho Angel (Feat. ave;new Project feat Sakura Saori) (3:12) Itou Shizuka - Zankoku na Tenshi no Thesis (4:07) Angelic Layer - 01 - Be My Angel OP (Atsuko Enomoto) (4:04) Aromageddon - Devil&Angel Reversible Ring (3:47) Tomita Miyu & Oonishi Saori & Oozora Naomi & Hanazawa Kana - Hallelujah Essaim (4:12) Lia - My Soul, Your Beats! (4:35)
>>165187 Да это я в целом, 20 лет назад все это в массовую культуру не очень входило, а сейчас очень даже. Кто бы что не говорил.
Спасибо за зефир! >>165180 Первый раз я это ощутил, когда понял что я уже старше чем Hououin Kyouma, хотя казалось бы.
https://drive.google.com/file/d/1R4kx78HQ7Pha3rjUgTqgIjjbcfpQzpBH/view?usp=sharing
Касательно ротации картинок с персонажами, если делать это по серверному времени и поверх Кусабы, то делается это предельно просто. Были бы картинки. Делаем папку с этими картинками, именуя их по типу Акари0724.png; Линкуем файл картинки, на который ссылается CSS, с корректной на момент картинкой из той папки; Заводим systemd таймер и им каждую полночь запускаемые сервис со скриптом, линкующим указанный в CSS файл картинки персонажа с файлом из той папки, содержащим текущее mmdd в своём имени, если таковой файл существует. Если внутри Кусабы или по времени клиента, то уже несколько муторнее.
>>165204 > Заводим systemd таймер Соус такими категориями не мыслит.
>>165205 Вас systemd не устраивает? На Дебиане вроде всегда есть cron. Можно скрипт им вместо systemd запускать.
Можно вообще на уровне веб сервера рерайт рулов написать: RewriteCond %{TIME} ...
RewriteCond %{TIME} ...
>>165208 Но тогда придётся для каждой картинки в конфиге по строчке делать. Или нет? А с работающим скриптом, потом можно тупо в папку файлы накидывать. Хотя для каждого из них в имени тоже придётся прописать дату, да.
>>165209 Да мне кажется вопрос личных предпочтений, с чем проще справиться.
>>165209 cd /path/to/folder/with/pics ls -1 >> ./../list while read x; do mv $x "$(date +%m.%d.%y-%H.%M.%S).$(echo $x | sed 's/^.*\.//')" done < ./../list
>>165210 У. Хотя на самом деле, пусть это не совсем та ситуация, многа_букав vs обобщающий механизм — это достаточно часто встречаемая необходимость выбора, которую редко видишь серьёзно затрагиваемой. С одной стороны, кучу бойлрплэйта типа write("abcd" + separator + struct.abcd + "\n") писать крайне уныло, и как-то зря на это время тратить, а потом ещё раз тратить, повторяя один и тот же паттрн для всех операндов. С другой, можно заняться метапрограммированием или кодогенерацией, получив коллекции имён и значений для структуры, перебрать их все в цикле. Но если придётся для какого-то из полей определённого типа сделать какие-то дополнительные или другие действия при записи? Либо писать под такой тип отдельный сериализатор, либо грубо пихать костыль в обобщённый механизм сериализации, либо вводить слой индерекции, проверяя, есть ли для поля какого-то типа специальный механизм записи и в случае наличия использовать его. Конкретно в данном примере менять немного, если такое случится. В худшем случае добавляется вызов функции представления для каждого из полей. Но в куда более сложных случаях с максимально обобщённым, сжатым кодом без повторов бывает очень тяжело работать: если вдруг требуется помянять логику для одного из элементов данных или действий, рушится вся конструкция. Более того, иногда объям однотипного бойлрплэйта не сильно-то меньше объёма обобщённого кода — который, в отличие от предыдущего — куда сложнее для написания и понимания и даёт куда больший простор для трудноотлавливаемых багов. При этом, средства для написания обобщёнок часто ограничены. В ООП языках с интерфейсами бывает либо сложновато, либо невозможно автоматически генерировать их реализации. Или проитерироваться по всем полям и типам, создавая/делая нужные действия для каждого из них. Часто похожие ограничения приводят к использованию словарей (map-ов) вместо структур или классов с полями и getter-ами/setter-ами, что в плане производительности хорошо не есть. C Сшкой придётся пользоваться отдельными скриптами, там ведь и generic-ов нет; хотя с другой стороны, там нет и ограничений на низкоуровневую работу с данными и использование указателей/ссылок на функции, которые есть в некоторых языках более высокого уровня, и вокруг которых со временем понастроили костыли для быстрого «обхода» таких ограничений. И чё тут делать, и на чём лучше было бы писать — отбрасывая факторы поддерживаемости и количества библиотек — не понятно.
>>165212 Там же ведь под датами, которые необходимо держать в именах картинок или в конфиге, подразумеваются не текущие даты, а даты дней рождений в формате mmdd. Но да, подобную штуку можно задействовать для генерации бойлрплэйта, только её при любых обновлениях множества тех картинок придётся запускать повторно. И даты, на основании которых такое будет генерироваться всё равно должны быть указываемы или записаны заранее. ЗЫ Эта картинка весит меньше мегабайта, потому что готовые sample-ы обочно не весят много и мало кто заморачивается их кодировать ровно под 5 MiB. Хотя сама картинка весит 7. Потому большемерок не видете.
>>165212 Только заметил, что сминает в один файл. Вот так лучше: #! /bin/bash year=2021 #Works for year 2021 cd /home/cirno/temp/pics/ ls -1 > ./../list day=1 month=1 while read x; do mv $x "$day.$month.$year.$(echo $x | sed 's/^.*\.//')" if (($day==31)) && (($month==12)); then echo -e "Days are gone!" exit elif (($day==31)) && ( (($month==1)) || (($month==3)) || (($month==5)) || (($month==7)) || (($month==8)) || (($month==10)) || (($month==12)) ); then day=1 ((month++)) elif (($day==28)) && (($month==2)); then day=1 ((month++)) elif (($day==30)) && ( (($month==4)) || (($month==6)) || (($month==9)) || (($month==11)) ); then day=1 ((month++)) fi ((day++)) done < ./../list
>>165214 Тогда можно записать даты в отдельный список, а потом пустить мой скрипт, только при именовании файлов использовать case date in $(cat date_list).
>>165214 ЗЗЫ Эх, давно ж я bash-скрипты не писал. Стыдоба-стыдобушка. Но так, обновлялка работает. обновлялка cd /srv/http/fbe-410/css maybe_file=$(find girl_pics_dir -name "×$(date +%m%d)×.png") if ! [ -z "$maybe_file" ] ; then ln -sf "$maybe_file" current_girl.png fi пихнуть в /etc/crontable 0 0 × × × http sh /srv/http/fbe-410/rotate.sh Вместо × пихнуть звёздочку. И вместо пропуска с неразрывным пробелом табуляцию.Чёртова разметка.Почему задча «убрать нечитаемо-уродливый полуторный интервал для кода» до сих пор не критической важности?Постойте-ка, дык её вообще нет.
Постскриптум >>165214 подтверждаю: файл https://danbooru.donmai.us/posts/4167732 весит без малого 7 мегабайтов, примѣненіе сборки https://github.com/XhmikosR/jpegoptim-windows утилиты https://github.com/tjko/jpegoptim/ способно уменьшить эту величину только до 6⅔ мегабайта, а последующее транскодирование в JPEG XL без потерь — только до 5⅔ мегабайта, так что аудіоѳэзисъ Соусова «что-то на сайте с пятимегабайтовым ограничением не было видно ни одной картинки, его превосходящей — навѣрное, оно никому и не надо» (пускай и далеко не так прямо глумливо сформулированный, но куда мягче и деликатнее подразумевающий всё же что-то близко подобное именно этому; точную же цитату, из контекста не выдранную, заботливо прилагаю) выглядит получившим ещё один примѣръ существования противоположной нужды въ размѣрѣ 2894×4093 пикселов ужé в таком себе, знаете ли, upper middle качестве (даже если бы Сакура Орико тратила всего-навсего по 3½ бита на пиксел в среднем, то и тогда изображение этого размѣра превосходило бы 5120000 байтов). Употребляемые дисплеи доросли до 4K (а въ нѣкоторыхъ шлемах VR — даже ужé нѣсколько болѣе этого, как по адресу https://youtu.be/SOdytkabpPE это сообщает нам один кот), так что и потребности изображений потихоньку возрастают вмѣстѣ съ ними. Контраргументы к таким примѣрамъ также давно извѣстны: чѣмъ больше файл и чѣмъ лучше сохраняет он качество первоисточника, тѣмъ дальше бывает он от fair use цитирования и ближе к нарушению авторских прав; картинок таких мало, а видео таких будет много, etc. Лично же мне хотелось бы на 410чане вмѣсто 5000 килобайтов упираться въ предѣлъ 5120 килобайтов (сообщениями >>165138 и >>165143 и >>165144 упоминаемый) по той только причине, что предѣлу популярного сайта публикаций https://telegra.ph/ (братского по отношению к Телеграму и мною для публикации сшивок >>/a/16925 используемого) это бы тогда соѿвѣтствовало в точности. А не то пока что одно из трёх: ① Если файл изготовлен как упирающийся въ предѣлъ Телеграфа, то тогда его никак нельзя утащить на 410чан оттудова, потому что в тутошний-то предѣлъ он оказывается способен не то что упереться, а и прямо превзойти его. Безысходно! ② Если файл изготовлен как упирающийся въ предѣлъ 410чана, то тогда при утаскивании его на Телеграф приходится сознавать всякий раз, что он мог бы на Телеграфе быть ещё больше по объёму и качественнее. Неэффективно! ③ Если заранее изготавливать два файла разного качества (один для 410чана, другой для Телеграфа), то их тогда потóм и хранить два (непремѣнно совмѣстно, как носки́, а не то один нипочём не отыщется рядом с другим), и надо же наперёд не позабыть изготовить их два (а не то, как обычно, файл сперва создаётся для одного только сайта, а пригождается-то и на другом, чего спервоначалу и не предвиделося), и надо больше времени (почти вдвое больше) затратить на изготовление. Накладно! Важно то, что для других сайтов на всё это психологически проще, и даже гораздо проще, «наплевать с высокой колокольни». На Nowere лимит вчетверо больше, а на 014чане даже впятеро? — наплевать. На Ычане лимит меньше на цѣлый мегабайт или два? — печально, но также можно ещё наплевать. Но тут-то меньше 2½% разницы, раздражающе близко. «Видит ꙩко, а зуб неймёт», «близок локоть, а не укусишь», etc. Вот что воспламеняет досадою. Но это лично мне. По отношению же к цифровым живописцам и живописицам мы должны руководиться, напримѣръ, возможностями Твиттера (в котором они публикуют свои цифровыя работы), а эти возможности по отношению к объёмам файлов были по адресу https://twittercommunity.com/t/upcoming-changes-to-png-image-support/118695 указаны ВНЕЗАПНО также ровнёшенько пятимегабайтовыми (а по размѣрамъ — не болѣе 4096×4096 пикселов, а по количеству битов JPEG на один пиксел в среднем — не болѣе восьми). Получается опять же, что предѣлъ объёма файлов на 410чане на сáмую малость меньше твиттеровского как будто нарочно для того, чтобы часть файлов из Твиттера никак нельзя было копировать сюда без потери их качества и без растраты своего времени. Нехорошо, неудобно.
Мысль из послѣдняго абзаца сообщения >>165239 можно выразить и сопоставительно: если Соусов на ѿмѣткѣ времени 01:50:55 говорит «я, может быть бы, поддержал бы, если бы на Ычане бы до пяти мегов бы везде подняли бы это самое, но там чё-то не хотят это дѣлать, поэтому я не знаю» (аудиоцитату въ болѣе широком контексте прилагаю), то тогда, очень даже может быть, наперёд слѣдовало бы обратить внимание в том же смысле на предѣлъ объёма файлов в Твиттере. Twitter-то в качестве законодателя мод, влияющих на контент при его создании (в том числе на контент околоанимешный и оттого приносимый на имиджборды), повлиятельнее Ычана окажется при трезвом рассмотрении — и оттого практически он болѣе цѣненъ как примѣръ.
Соус, нарисуй опен соус.
На чифире сказал, что «Puraore» — проект «Bushiroad», хотя на самом деле это «CyberAgent». Стыдновато.
