Раньше общение в сети было чем-то живым, настоящим, где каждый мог выразить свои мысли и чувства. Но сейчас, когда алгоритмы становятся всё более продвинутыми, сложно отличить реального человека от бездушного бота. Я замечаю, что многие сообщения выглядят так, будто их написали не люди, а машины, которые просто генерируют текст по шаблону. Это вызывает у меня чувство тревоги, потому что теряется искренность общения. Мы уже не можем быть уверены, кто стоит за экраном — может, это просто программа, которая пытается имитировать человеческие эмоции. Это как будто мы живём в мире, где настоящие связи становятся редкостью, а общение сводится к взаимодействию с алгоритмами. Я боюсь, что в итоге мы потеряем способность понимать друг друга, и общение станет пустым и бездушным. Как можно доверять информации, если не знаешь, кто её создал? Это действительно пугает, и я надеюсь, что мы сможем найти способ сохранить человеческое в нашем общении, прежде чем станет слишком поздно.
Всю информацию на плонете создал кот. Вы обезоружены, здавайтесь.
Видел я уже этот пост на Новери.> 1733851590642-2> -2А поди, и не только там он был отправлен. > Это как будто мы живём в мире, где ... общение сводится к взаимодействию с алгоритмами.https://www.youtube.com/watch?v=5PdXIHGvMpk Видео related.
>>1004292 Ха, иронично. Масс-рассылка от бота и впрямь отличается мало. >>1004290>Мы уже не можем быть уверены, кто стоит за экраном — может, это просто программа, которая пытается имитировать человеческие эмоции.Как что-то плохое. Понять полностью человека от рандомных анонимных постов в интернете - то ещё занятие. Вдруг тф с постиронией или копипастой разговариваешь. Вообще, покуда это не чатик, проще писать, ориентируясь на публику, а не оппонента, второго и так фиг переубедишь, лол.>Это как будто мы живём в мире, где настоящие связи становятся редкостью, а общение сводится к взаимодействию с алгоритмамиGo IRL, touch grass.
Автоматическая проверка на крамолу и автоматизированный флуд со стороны (N)(G)O, конечно, угроза и реальность, но тут вот подумалось, что одним из других, то бишь нам полезных, применений нейронок помимо картинкогенерации, озвучки и чата с персонажами, может быть автоматическая проверка софта на свежие уязвимости с апстрима. Было вот в прошлом, кажется, году, что один китайский разработчик попытался забэкдорить openssh. Заметили быстро. А если бы нет? Наверное, много такого ненайденного по огромным кодобазам. Наверное, особенно автоматическая проверка пригодилось бы для разных точно-не-ханюпот форков с улучшенной секурностью-приватностью. С другой стороны, наверное, будет написан и автоматический обфускатор. Или атакующий будет проверять вносимую уязвимость на детектируемость публично доступными средствами. Что вынудит, наверное, что-то проверять вручную, ибо только с большим количеством false positives от детекторов будет какой-то толк.
>>1004495>opensshxz же https://www.openwall.com/lists/oss-security/2024/03/29/4 декодек
>>1004499 Gyatt!!
У вас тревожность, пейте таблетки. Я тоже пью и всем рекомендую.
>>1004495>автоматическая проверка софта на свежие уязвимости с апстримаЗначительная часть бед современных нейронок в такого рода применениях ещё и от неразделяемости условно кода (задания) и данных - так что скармливать ей можно разве что отчёты статических анализаторов, вроде PVS-Studio - да и то после санитации и с осторожностью - но никак не сам код. Потому как в нём могут быть и указания для сети - причём даже в неочевидной для человека форме, но вполне воспринимаемые сетью - и они для сети будет иметь не меньшее значение, чем данное ей задание.
>>1004758 Цитирование не обработалось, странно. Со своего клиента постишь? https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart-form-data Вроде по спецификации в multipart/form-data клиенты должны \r\n отдавать. Или не multipart/form-data было запощено? Переносы строк работают потому, что и у нас, и на Булочке и Чио, на <br>-ы меняется \n только. Приводит к тому, что остаётся \r перед <br>-ами. Помню, что вроде я на это внимание обратил, когда правки делал, но почему-то ничего с этим не сделал. Переносы под \r\n или \n нормализовать? Самое простое, но в таком случае подсчёт количества символов на сервере будет с подвохом. Сделать поддержку и \r\n, и \n? Тогда пользователи альтернативных клиентов смогут отправлять сообщения длиннее, чем пользователи браузеров. При JS posting'е вручную перегонять текст поста в UTF-8 и отправлять как blob? Наверное, в идеале это, но пока хотя бы лишние \r убрать, whether забив на нестандартные переносы или допустив.
multipart/form-data
\r\n
<br>
\n
\r
>>1004759> своего клиента Нет. Тоже впервые такое вижу. До этого всё было нормально - что на 410, что на 014 (включая булочка.орг через замену домена в настройках), что на Ычане а больше я никуда и не хожу.
>>1004763> Тоже впервые такое вижуДавно не постил! Где-то в январе тут было мажорное обновление парсера, где обработка цитат была обобщена в обработку списков. Списки в оригинале обрабатывались по \r\n, цитаты по \n. > До этого всё было нормальноНа Чио списки получится запостить? Судя по всему, не должно. Можешь проверить? https://github.com/AliceCA/Overchan-Android Этот? Или один из форков? Свиду, виноват там httpclient-4.4.1.2.jar. При постинге, Chan410Module вызывает у ExtendedMultipartBuilder'а addString("message", model.comment). ExtendedMultipartBuilder вызывает MultipartEntityBuilder'у метод addPart(key, new StringBody(value, ContentType.create("text/plain", "UTF-8"))). И MultipartEntityBuilder, и StringBody лежат в httpclient. Вроде этот JAR — лишь Android-compatible форк Apache'шного софта. Неужели Apache не прав? https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart-form-data Любопытно, что у> If entry's value is not a File object, then replace every occurrence of U+000D (CR) not followed by U+000A (LF), and every occurrence of U+000A (LF) not preceded by U+000D (CR), in entry's value, by a string consisting of a U+000D (CR) and U+000A (LF).Не стоит ссылка на RFC 2046. https://www.rfc-editor.org/rfc/rfc2046#section-4.1.3 В RFC 2046 ничего про сепаратор линий для текстовых entities напрямую не указано, но для Plain Subtype стоит ссылка на RFC 822.> The simplest and most important subtype of "text" is "plain". This indicates plain text that does not contain any formatting commands or directives. Plain text is intended to be displayed "as-is", that is, no interpretation of embedded formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup should be necessary for proper display. The default media type of "text/plain; charset=us-ascii" for Internet mail describes existing Internet practice. That is, it is the type of body defined by RFC 822.https://www.rfc-editor.org/rfc/rfc822#section-3.1 Где стоит такое> text = <any CHAR, including bare ; => atoms, specials, CR & bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT recognized.Что не согласуется со спецификацией HTML. Меж тем, RFC 822 есть obsoleted by RFC 2822, который obsoleted by RFC 5322, где таки да, CRLF. https://www.rfc-editor.org/rfc/rfc5322#section-2.3> The body of a message is simply lines of US-ASCII characters. The only two limitations on the body are as follows: o CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body.И следом> o Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF.Которое точно при отправке форм до 988 никем не лимитируется. Так что если писать в Apache, то могут ответить что RFCs are not clear on this, RFC's multipart/form-data — это вам не HTML's multipart/form-data, надо HTML spec -compatible — нормализуйте переносы сами. Но было бы интересно уточнить, \n\r — это SHOULD или всё-таки MUST. Но вернёмся к Overchan'у. Если окажется, что списки на Чио и Булочку не запостить, на клиенте это проще всего решить, заменив в src/nya/miku/wishmaster/chans/cirno/Chan410Module.java в методе sendPost, 256-ая строка> addString("subject", model.subject).На> addString("subject", model.subject.replace("\n", "\n\r")).Это же решит Overchan'ову проблему с цитатами тут: возможно, раньше, чем она решится в parsing.class.php. По-хорошему, ещё Chan410Boards отредактировать, там значения для форматов и для бамплимита устаревшие. Ещё, если я таки сделаю https://codeberg.org/FBE410/fbe-410/issues/51, то отвалится отображение сажи, надо будет Chan410Reader редактировать. Короче, cirno директории у Overchan'а нужен maintainer. Можешь, наверное, им стать.
httpclient-4.4.1.2.jar
Chan410Module
ExtendedMultipartBuilder'а addString("message", model.comment)
ExtendedMultipartBuilder
MultipartEntityBuilder
addPart(key, new StringBody(value, ContentType.create("text/plain", "UTF-8")))
StringBody
httpclient
The simplest and most important subtype of "text" is "plain". This indicates plain text that does not contain any formatting commands or directives. Plain text is intended to be displayed "as-is", that is, no interpretation of embedded formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup should be necessary for proper display. The default media type of "text/plain; charset=us-ascii" for Internet mail describes existing Internet practice. That is, it is the type of body defined by RFC 822.
text = <any CHAR, including bare ; => atoms, specials, CR & bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT recognized.
The body of a message is simply lines of US-ASCII characters. The only two limitations on the body are as follows: o CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body.
o Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF.
\n\r
src/nya/miku/wishmaster/chans/cirno/Chan410Module.java
sendPost
addString("subject", model.subject).
addString("subject", model.subject.replace("\n", "\n\r")).
Chan410Boards
Chan410Reader
>>1004767> replace("\n", "\n\r")replace("\n", "\r\n") то бишь. fixed Also, ради каких фич пользуешься именно Overchan'ом, а не браузером?
replace("\n", "\n\r")
replace("\n", "\r\n")
>>1004767>https://codeberg.org/FBE410/fbe-410/issues/51>https://codeberg.org/FBE410/fbe-410/src/branch/public/iconsХа, я напрямую через Инкскейповский диалог символов правил. Потом конечно вычищать лишние элементы, но работало. Но с крашем.
>>1004767Давно, но явно не с января. Возможно давно не было повода цитировать именно на булочке, да (а то, что булочка (и старый IP 014) и сегодняшний 014 - теперь не одно и то же - внезапно огорошило только вчера). Не совсем теперь даже понимаю, куда деваться (каламбур однако получилсят и какой хороший)! Попробую. Навскидку могу сказать, что цитирование на 410 работает точно, как и на ii. А списки могли незаметно отвалиться хоть пять лет назад - не пользуюсь ими.UPD: работает! Вот это. https://github.com/overchan-project/Overchan-Android Мэйнтейнером мне в ближайшее время точно не быть - собирать Android прямо на целевой платформе - да ещё и не что-то изначально написанное с оглядкой на такое - гребля костылями на одноколёсном велосипеде через пожар в борделе. ПК просто нет и в ближайшие полгода не предвидится (если раньше кто не соблазнит в космотаблицы разве что). Да и джава вгоняет в депрессию если честно, так что стараюсь усиленно забыть то немногое, что знаю именно по ней.>>1004768Банально потому, что браузер жрёт батарею куда как суровее, не умеет нормально кэшировать треды, да и с точки зрения юзабилити интерфейса - именно для борд - заметно неудобнее. В условиях, когда зарядка лимитирована (пасмурно - солнечная панель даёт крохи) - а до интернетов - десяток километров пешком - очень существенно. Сейчас с этим получше, но привычка осталась.
