Вот и я попался в лапы WYSIWYG редактора на мобиле. Очень неуютно и мелко для манипуляций с сылками. Исправленный ряд (исходный комментарий не поправить - время вышло): 1, 2, 3, 4
9974 файла без бана с одного IP за 6 минут 16 секунд. 7502 из них всякого рода аватарки до 500х500.
Остальные - про школы, власть, СВО, МЧС. Есть пара сюжетов про автозапчасти, объявления ноготков и стрижек. Куча нейрокартинок, что грустно. Есть "открытки из ватсаппа" на разные поводы. 33 ссылки - дубли в исходных данных.
Из чего-то похожего на нюдсы - 4 штуки: 1, 2, 3, 4. Причём, последняя как раз по задумке и сюжету является нюдсом😉
Прикол в том, что спам от банков идёт с обычных сотовых номеров, которые редко "опознаются". Я их записываю под названиями банков, но по статистике где-то 1% только используется повторно. Перемаркировать сотовые номера? Пффф...
Мысль понятна, она коммерческая - главное посеять в головах умов, что можно так, а потом сиди смотри как общество само так сделает. Ну да, продажи токенов будут обеспечены спросом.
Так и вижу, просыпаешься утром, по нейроинтерфейсу даёшь мыслезадачу, и ИИ генерит операционную систему для нейрокомпа, потом генерит нейроWord и нейроПочтовик. Заходишь в нейроПочтовик, читаешь саммари по пришедшим письмам, открываешь нейроWord и диктуешь ответ... И так каждый день 😉
Если корзина не OneDrive или не в облаке - то Active Undelete и подобный софт с отдельного диска/флешки. Не раз помогало если случайно удалил даже мимо корзины. 😉
mail.ru порезал ящик до 8Гб, у кого был диск на 100Гб внезапно стали "переполнены". И не принимали письма новые, пока не расчистить. Более того, "на вынос" лишнего каждому давалось ограниченное время, после чего "файлы могли исчезнуть".
gmail.com сжался до дефолтного объема 15Гб, всё что выше - не влезает и не принимается. Сам видел такой переполненный ящик и письма от Гугла "вы превысили 15Гб, через неделю перестанем сохранять новые письма".
Т.е. нужно самим озаботиться о архиве и бэкапе архива почты, ещё бы с поиском и индексом по всем письмам за все года и доступе удобном с телефона...
Создать простенький сайт с robots.txt, который запрещает все, кроме главной страницы. В этом сайте создать несколько страниц и логировать их посещения, записывая UserAgent.
Нужно ещё откуда-то взять трафик на этот "простенький сайт", а то получится Неуловимый Джо, которого не ловят, так как никому он не нужен.
В статье не хватает куска - начали за здравие "Распределённые блокировки", привели код, а выводы "Это идеально подходит для: приложений такси (поиск ближайших водителей)" и дальше все про поиск ближайших. То есть, кусок с геопримером - пропустили...
Ниже секции "Критический анализ — скрытые риски выбора Go" - очень тяжело читать LLM-like повторение одних и тех же концепций/фактов по несколько раз в разных обёртках.
Из текущей версии статьи:
Действительно, (речь в абзаце про Go) компилируемый язык с эффективным сборщиком мусора демонстрирует лучшие результаты по скорости выполнения, чем интерпретируемый Python. Однако это преимущество проявляется только в специфических сценариях: обработка тысяч одновременных соединений, CPU-интенсивные вычисления, низкоуровневое управление памятью.
и
Go, несмотря на заявленную безопасность, использует сборщик мусора, который создает непредсказуемые паузы и усложняет написание real-time систем.
Тут как в анекдоте - "либо крестик снимите, либо трусы наденьте". LLM/EI забыл внизу текста, что выше назвал преимуществом Go и выдал за недостаток.
Спасибо за статью, она помогает проще смотреть на вещи, показывая суть операционной системы.
По поводу как перекомпилировать ядро, была байка, что в лохматых 2009-х, был обычный комп, на котором поставлен CentOS 5.3 с DVD, но в ядре отсутствовал драйвер сетевой карты. А комп собирали как стенд для веб-сервера - без сетевухи никак! На соседнем виндовом компе были найдены в интернете "заклинания" для компиляции ядра и нужные исходники драйвера сетевухи. На линукс исходники затащили через mount usb-флешки. Дальше долгая компиляция ядра с вкомпиливанием драйверов сетевухи. Цимес ситуации был в том, что любое yum update через несколько недель/месяцев обновляло ядро, в котором не было драйвера и перекомпиляцию надо было повторять заново. Было круто ощущать "я перекомпилил ядро и сетевуха заработала", но такого простого понимания, как в статье, где и что именно "ядро" - ещё не было. С тех пор не люблю yum/dnf update)))
Выше и раньше автор уже ответил, что табличка служит для управления первичной информацией, а сайт после получения данных из таблицы делает upsert() в локальную базу данных на VPS, и дальше работает с ней.
Тут одна из ключевых составляющих проекта - стоимость решения. Да, можно во взрослые CMS, CDN, cloud. Но зачем? Проект стоит "кусок премиального брискета весом в 4 кг." Сможете ли вы поднять все описанное Вами выше "правильное" за указанное вознаграждение и остаться довольным?
Что из этой архитектуры существует, а что ещё нет? Подозреваю, что часть про агентов, самофиксирующих в блокчейне бюджет в цифровых рублях - из области влажных фантазий. Описано неплохо, но где скачать "datasheet и setup.exe"? Или теперь каждая компания, которая так хочет сделать, должна изобрести с нуля самостоятельно весь пайплайн?
Но при этом, в пиковый момент переезда получалось удвоение необходимых мощностей, чтобы держать все MS + все PG инстансы, верно? А процесс перехода на Linux 1C мог идти на высвобождаемых MS 1C серверах.
И ещё вопрос по срокам - только первый этап озвучен в 4 месяца. А у остальных не указаны сроки. Сколько заняли последующие этапы?
Одно из самых крутых впечатлений от IT было в лицее. Как факультатив туда пришел преподаватель ассемблера. Набился целый класс страждущих узнать про регистры и mov ax, bx; Но однажды был выход "за грань" - преподаватель сказал "а теперь com-файлы собираем прямо в hex-кодах, и чтобы работало!" Это была кульминация) Конечно, каждый ещё разрабатывал свою резидентную программу, но это в рамках курса...
Вот и я попался в лапы WYSIWYG редактора на мобиле. Очень неуютно и мелко для манипуляций с сылками.
Исправленный ряд (исходный комментарий не поправить - время вышло): 1, 2, 3, 4
9974 файла без бана с одного IP за 6 минут 16 секунд. 7502 из них всякого рода аватарки до 500х500.
Остальные - про школы, власть, СВО, МЧС. Есть пара сюжетов про автозапчасти, объявления ноготков и стрижек. Куча нейрокартинок, что грустно. Есть "открытки из ватсаппа" на разные поводы. 33 ссылки - дубли в исходных данных.
Из чего-то похожего на нюдсы - 4 штуки: 1, 2, 3, 4. Причём, последняя как раз по задумке и сюжету является нюдсом😉
Ну пока не неглиже, но начало положено, на последней странице 200 из списка:
https://web.archive.org/web/20251231102104/https://i.oneme.ru/i?r=BUFxtygYfQ8hp8NJRyp5v4T3YYNE4rvPZesJ02m1MezyMtsXp2dFzgmowCIsoTAD_X_FHytuSFeq8nVn8TsBai5o&fn=w_1440
Один ИИ-код заменили на другой ИИ-код. Хорошо, что заново сгенерили, а не попросили просто исправить граничные случаи)))
Прикол в том, что спам от банков идёт с обычных сотовых номеров, которые редко "опознаются". Я их записываю под названиями банков, но по статистике где-то 1% только используется повторно. Перемаркировать сотовые номера? Пффф...
Мысль понятна, она коммерческая - главное посеять в головах умов, что можно так, а потом сиди смотри как общество само так сделает. Ну да, продажи токенов будут обеспечены спросом.
Так и вижу, просыпаешься утром, по нейроинтерфейсу даёшь мыслезадачу, и ИИ генерит операционную систему для нейрокомпа, потом генерит нейроWord и нейроПочтовик. Заходишь в нейроПочтовик, читаешь саммари по пришедшим письмам, открываешь нейроWord и диктуешь ответ... И так каждый день 😉
Как раз для таких заголовков есть противопоставление:
Если корзина не OneDrive или не в облаке - то Active Undelete и подобный софт с отдельного диска/флешки. Не раз помогало если случайно удалил даже мимо корзины. 😉
mail.ru порезал ящик до 8Гб, у кого был диск на 100Гб внезапно стали "переполнены". И не принимали письма новые, пока не расчистить. Более того, "на вынос" лишнего каждому давалось ограниченное время, после чего "файлы могли исчезнуть".
gmail.com сжался до дефолтного объема 15Гб, всё что выше - не влезает и не принимается. Сам видел такой переполненный ящик и письма от Гугла "вы превысили 15Гб, через неделю перестанем сохранять новые письма".
Т.е. нужно самим озаботиться о архиве и бэкапе архива почты, ещё бы с поиском и индексом по всем письмам за все года и доступе удобном с телефона...
Ждём статью "Я разрешил Moltbot открывать замки и платить с моей карточки на неделю. Что из этого вышло?"
Ну вон, в соседней теме, в этих OpenClaw и Moltbot нашли гигантские дыры в безопасности. Будет как в анекдоте "ну хоть что-то у нас в безопасности"...
Нужно ещё откуда-то взять трафик на этот "простенький сайт", а то получится Неуловимый Джо, которого не ловят, так как никому он не нужен.
В статье не хватает куска - начали за здравие "Распределённые блокировки", привели код, а выводы "Это идеально подходит для: приложений такси (поиск ближайших водителей)" и дальше все про поиск ближайших. То есть, кусок с геопримером - пропустили...
Ниже секции "Критический анализ — скрытые риски выбора Go" - очень тяжело читать LLM-like повторение одних и тех же концепций/фактов по несколько раз в разных обёртках.
Из текущей версии статьи:
и
Тут как в анекдоте - "либо крестик снимите, либо трусы наденьте". LLM/EI забыл внизу текста, что выше назвал преимуществом Go и выдал за недостаток.
Спасибо за статью, она помогает проще смотреть на вещи, показывая суть операционной системы.
По поводу как перекомпилировать ядро, была байка, что в лохматых 2009-х, был обычный комп, на котором поставлен CentOS 5.3 с DVD, но в ядре отсутствовал драйвер сетевой карты. А комп собирали как стенд для веб-сервера - без сетевухи никак! На соседнем виндовом компе были найдены в интернете "заклинания" для компиляции ядра и нужные исходники драйвера сетевухи. На линукс исходники затащили через mount usb-флешки. Дальше долгая компиляция ядра с вкомпиливанием драйверов сетевухи. Цимес ситуации был в том, что любое yum update через несколько недель/месяцев обновляло ядро, в котором не было драйвера и перекомпиляцию надо было повторять заново. Было круто ощущать "я перекомпилил ядро и сетевуха заработала", но такого простого понимания, как в статье, где и что именно "ядро" - ещё не было. С тех пор не люблю yum/dnf update)))
Выше и раньше автор уже ответил, что табличка служит для управления первичной информацией, а сайт после получения данных из таблицы делает upsert() в локальную базу данных на VPS, и дальше работает с ней.
Тут одна из ключевых составляющих проекта - стоимость решения. Да, можно во взрослые CMS, CDN, cloud. Но зачем? Проект стоит "кусок премиального брискета весом в 4 кг." Сможете ли вы поднять все описанное Вами выше "правильное" за указанное вознаграждение и остаться довольным?
Что из этой архитектуры существует, а что ещё нет? Подозреваю, что часть про агентов, самофиксирующих в блокчейне бюджет в цифровых рублях - из области влажных фантазий. Описано неплохо, но где скачать "datasheet и setup.exe"? Или теперь каждая компания, которая так хочет сделать, должна изобрести с нуля самостоятельно весь пайплайн?
Но при этом, в пиковый момент переезда получалось удвоение необходимых мощностей, чтобы держать все MS + все PG инстансы, верно? А процесс перехода на Linux 1C мог идти на высвобождаемых MS 1C серверах.
И ещё вопрос по срокам - только первый этап озвучен в 4 месяца. А у остальных не указаны сроки. Сколько заняли последующие этапы?
Одно из самых крутых впечатлений от IT было в лицее. Как факультатив туда пришел преподаватель ассемблера. Набился целый класс страждущих узнать про регистры и mov ax, bx; Но однажды был выход "за грань" - преподаватель сказал "а теперь com-файлы собираем прямо в hex-кодах, и чтобы работало!" Это была кульминация) Конечно, каждый ещё разрабатывал свою резидентную программу, но это в рамках курса...