Вспомнилась старая книжка "Этюды для программистов". Там в том числе описывалось моделирование гравитационного взаимодействия большого числа звёзд на слабых компах. Чем-то сиё напомнило.
Гм... Либо я чего-то не понимаю, либо правильно, что не использовал openclaw, а сразу пошел на picoclaw (у меня не настолько много ресурсов на домашнем хранилище, а это запускается на ОЧЕНЬ слабых железках, где только может быть запущен linux), но только что проверил в чате — отлично ищет торренты и качает видео с видеохостингов, автомагически перед этим скачав yt-dlp. Скачивание торрентов не пробовал, но препятствий нет. Правда, у меня модель попроще — qwen3.6-27b, ибо к ней есть доступ. Заморачиваться с другими моделями было лень, может быть там и было бы чего.
А в остальном — отличная статья.
P.S. Сисадмин, но вот накой я это запустил — пока хз.
Таки я в курсе про cgroups, им и делали в своё время.
Тут, скорее, надо более-менее автоматически понижать приоритет жрущих и возвращать обратно, когда перестают, а не тупо ограничивать проц. Ибо если никто на процессор не претендует — пусть кушают, сколько получится. Ну это если нет возможности организационно разделить редких крупных потребителей, которым можно отдать ядра без соседей и мелочь, где и десяток виртуальных ядер на одно реальное норма.
Из текста далеко не ясно, что речь про оверселлинг по процессору. Лично я понял это как "отдаём внутрь вм все ядра, ограничиваем только снаружи, потому что по-другому не умеем" и никак иначе.
Ну и, кстати, борьба с легитимной нагрузкой на вм путём уменьшения реально отданного процессорного времени с точки зрения клиента выглядит странно (из заметного, кроме уменьшения быстродействия от ожидаемого — рост steal). Проходили лет 10-15 назад...
Control plane отправляет запрос на 2 vCPU и 4 ГБ RAM, но когда ВМ начинает активно нагружаться, шедулер Linux отдаёт ей всё свободное время.
Как вы сумели такого добиться? Вот тупо взял qemu без libvirt, указал нужное количество памяти через -m и число ядер через -smp, нагрузил числом активных процессов раза в два побольше ядер, чем выдал — жрёт столько, сколько указано ядре, а не сколько процессов.
Нашел-таки. Книга называется "Жемчужины программирования".
https://publ.lib.ru/ARCHIVES/B/‘‘Biblioteka_programmista’’_(seriya)/%c1%e5%ed%f2%eb%e8%20%c4%e6._%20%c6%e5%ec%f7%f3%e6%e8%ed%fb%20%ef%f0%ee%e3%f0%e0%ec%ec%e8%f0%ee%e2%e0%ed%e8%ff.(2002).pdf
Судя по всему, читал ещё первое издание.
https://publ.lib.ru/ARCHIVES/U/UEZERELL_Charl’z/_Uezerell_Ch..html — я, похоже, ошибся в названии. Эта книга тоже хороша и я её читал, но я не нахожу там задачи про гравитацию.
Да. Она старая, проблемы местами уже решены (всё-таки в компах уже не десятки кб памяти, к примеру), но читать было интересно.
Вспомнилась старая книжка "Этюды для программистов". Там в том числе описывалось моделирование гравитационного взаимодействия большого числа звёзд на слабых компах. Чем-то сиё напомнило.
С телефона — не критично. А вот с двух компов — не помешало бы. Пока обхожусь syncthing и .md
В заметках — никогда. И даже просто в редакторе — раз в пару месяцев. Просмотрщика обычно хватает.
Не особо готов. Впрочем, если дойдёт до такого — для более-менее текстовых задач в принципе хоть как-то работает ministral-3 на CPU.
Это уже следующий этап, вне бейсика.
Ага. И usr(0), где 0 — чисто на экране, а на самом деле там переход сильно в другое место... Причём, так делалось по двум разным причинам:
прикрыть реальный адрес перехода от просмотра (любопытствующие не откажутся хотя бы от LIST)
сэкономить память, требуемую загрузчиком на бейсике (чтобы можно было сдвинуть RAMTOP как можно ниже и загрузить в верхнюю часть уже код для z80)
По второй причине когда-то сам делал, но это было давно и мои извращения далеко не разошлись.
Они не шутят, они рекламируют.
Я проверил — 90% от оригинала является сильным преувеличением.
Гм... Либо я чего-то не понимаю, либо правильно, что не использовал openclaw, а сразу пошел на picoclaw (у меня не настолько много ресурсов на домашнем хранилище, а это запускается на ОЧЕНЬ слабых железках, где только может быть запущен linux), но только что проверил в чате — отлично ищет торренты и качает видео с видеохостингов, автомагически перед этим скачав yt-dlp. Скачивание торрентов не пробовал, но препятствий нет.
Правда, у меня модель попроще — qwen3.6-27b, ибо к ней есть доступ. Заморачиваться с другими моделями было лень, может быть там и было бы чего.
А в остальном — отличная статья.
P.S. Сисадмин, но вот накой я это запустил — пока хз.
Если правильно помню, 2ГБ — это для флешки в FAT32. Не ядерное ограничение всё ж. Ядерное было 4ГБ и это было 20+ лет назад.
Самой оси хватало и 8. Апгрейдился из-за офиса когда-то. Вот с ним на 8 уже не жизнь.
Ну не летала она на 4МБ, не летала. Вот на 8 — было очень даже неплохо. Потом, правда, приложения стали кушать.
Кстати, альт всё ж неплох, если достаточно того, что есть в дистрибутиве.
Только в госучреждениях и приравненных к таковым... У остальных выбор пошире будет. У нас, к примеру, чистый дебиан обычно.
А тут два основных варианта — либо нечто RHEL-подобное, либо нечто с deb-пакетами и apt. Остальное слишком мелкое по занимаемой доле ;-)
P.S. Даёшь холивар! :-)
Таки я в курсе про cgroups, им и делали в своё время.
Тут, скорее, надо более-менее автоматически понижать приоритет жрущих и возвращать обратно, когда перестают, а не тупо ограничивать проц. Ибо если никто на процессор не претендует — пусть кушают, сколько получится. Ну это если нет возможности организационно разделить редких крупных потребителей, которым можно отдать ядра без соседей и мелочь, где и десяток виртуальных ядер на одно реальное норма.
Из текста далеко не ясно, что речь про оверселлинг по процессору. Лично я понял это как "отдаём внутрь вм все ядра, ограничиваем только снаружи, потому что по-другому не умеем" и никак иначе.
Ну и, кстати, борьба с легитимной нагрузкой на вм путём уменьшения реально отданного процессорного времени с точки зрения клиента выглядит странно (из заметного, кроме уменьшения быстродействия от ожидаемого — рост steal). Проходили лет 10-15 назад...
Как вы сумели такого добиться? Вот тупо взял qemu без libvirt, указал нужное количество памяти через -m и число ядер через -smp, нагрузил числом активных процессов раза в два побольше ядер, чем выдал — жрёт столько, сколько указано ядре, а не сколько процессов.
В чём глюки были? А то у меня пока только одновременное редактирование одного файла в оффлайне было и это скорее мой косяк, а не syncthing.