Гм... Либо я чего-то не понимаю, либо правильно, что не использовал 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, нагрузил числом активных процессов раза в два побольше ядер, чем выдал — жрёт столько, сколько указано ядре, а не сколько процессов.
На нетбуке с 4ГБ памяти разменивал процессор на память при помощи zramswap. Отдал половину памяти под это дело. Работало нормально и точно будет работать, в отличие от вероятности запустить vramfs сейчас.
С телефона — не критично. А вот с двух компов — не помешало бы. Пока обхожусь 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.
Не встречал таких. Обязательно насыплют всякого, не имеющего отношения к основной функции.
Как глюки проявлялись? И на каком объёме числа файлов/гигабайтов?
А то непонятно, мне готовиться к переезду или пока время терпит...
Если есть сайт или вдс — у хостинг-провайдера сайта. Те же нетангелы дают десяток ГБ почты.
На нетбуке с 4ГБ памяти разменивал процессор на память при помощи zramswap. Отдал половину памяти под это дело. Работало нормально и точно будет работать, в отличие от вероятности запустить vramfs сейчас.