Читаешь и сначала думаешь, но ведь такое элементарно и обычно и все должны понимать, что всегда есть такой путь. Но оказывается многие и не задумываются о такой возможности и продолжают мучаться через gui. В моих задачах с iar нет необходимости в таком количестве вариантов сборки и все равно я еще лет 15 назад такие возможности изучил, удивив коллег. Так что статья очень полезна и кому-то откроет глаза.
Самое конечно веселое было с ПЛК icp-das. Под них до сих пор ПО пишется на borland c 3.1. Для автоматизации сборки пришлось написать скрипт на python, который запускает dosbox, в нем borland с необходимыми ключами и в итоге получается необходимый exe.
Именно. Путем автора вполне прошел, правда не дойдя до упаковки в корпус:
Для поиграться купил когда-то спонтанно cubieboard 2. Изначально задумывал embedded применение, но не пошло. В отличие от автора у cubieboard сразу было sata и преобразователь питания на плате, так что с ноутбучным винчестером вполне себе это работало сразу. Но очень быстро у меня вырос аппетит, захотелось не только файлопомойку, а ещё и на много дисков, свое облако и тп. В итоге пришлось идти по пути x86 железа. Что-то покупал новое, что-то б/у, за годы было несколько итераций смены платформы. Сейчас в итоге конфигурация такая:
Xeon 1240l-v3 (25 watt tdp)
Asus h97m-e (microatx lga1150)
32 gb ram (хватало для всего и 16, но оказалось ollama память любит)
4 hdd
2 sata ssd
1 nvme ssd
5060 ti 16 gb
Gh
На всем этом крутится свое облако nextcloud, home assistant, git, svn, transmission, samba, локальный ИИ в виде lm studio и ollama. Ну и всякая мелочевка.
Я ни разу автора не критикую. Как поиграться и что-то освоить почему бы и нет. Но очень быстро приходит осознание того, что решение крайне ограничено и надо что-то менять. К примеру свое облако на таком железе будет просто шевелиться, не бегать, а о возможности использовать nextcloud office/Collabora придется только мечтать.
Чисто по личному опыту (неделю вожусь с локальными llm, на личном сервере xeon 1240lv3, 16g ram, 5060 ti 16 gb): - lm studio на linux сервере значительно быстрее чем ollama (начинал с нее), а главное не жрет так память - перепробовал много моделей, пока для общего применения оптимальна openai/gpt-oss-20b - влезла в 12.2 gb VRAM с контекстом 65536 - отлично интегрировалась с open webui (через openai) - при желании ставится вообще без gui - при некоторых танцах с бубном заработала с home assistant
А ведь могли бы проконсультироваться со специалистами и просто привести закон к каким-то более реальным цифрам. Например так:
1) Хранить весь трафик за последние 3...7 дней (тоже не мало, но скорее всего подъемно). Возможно с какими-то фильтрами (ну нафига, например хранить трансляции с того же ivi.ru) бесполезного
2) Хранить трафик определенных абонентов по запросу спецслужб в течении месяца (потом повторный запрос, если необходимо)
3) Хранить трафик определенных абонентов по решению суда до полугода
4) Хранить историю звонков и, возможно, смс (последние малополезны конечно) в течение полугода-года.
Я все это конечно очень условно. Но что-то подобное потребовало бы уже куда меньших ресурсов и было бы подъемно для последующего анализа
Читаешь и сначала думаешь, но ведь такое элементарно и обычно и все должны понимать, что всегда есть такой путь. Но оказывается многие и не задумываются о такой возможности и продолжают мучаться через gui. В моих задачах с iar нет необходимости в таком количестве вариантов сборки и все равно я еще лет 15 назад такие возможности изучил, удивив коллег. Так что статья очень полезна и кому-то откроет глаза.
Самое конечно веселое было с ПЛК icp-das. Под них до сих пор ПО пишется на borland c 3.1. Для автоматизации сборки пришлось написать скрипт на python, который запускает dosbox, в нем borland с необходимыми ключами и в итоге получается необходимый exe.
Именно. Путем автора вполне прошел, правда не дойдя до упаковки в корпус:
Для поиграться купил когда-то спонтанно cubieboard 2. Изначально задумывал embedded применение, но не пошло. В отличие от автора у cubieboard сразу было sata и преобразователь питания на плате, так что с ноутбучным винчестером вполне себе это работало сразу. Но очень быстро у меня вырос аппетит, захотелось не только файлопомойку, а ещё и на много дисков, свое облако и тп. В итоге пришлось идти по пути x86 железа. Что-то покупал новое, что-то б/у, за годы было несколько итераций смены платформы. Сейчас в итоге конфигурация такая:
Xeon 1240l-v3 (25 watt tdp)
Asus h97m-e (microatx lga1150)
32 gb ram (хватало для всего и 16, но оказалось ollama память любит)
4 hdd
2 sata ssd
1 nvme ssd
5060 ti 16 gb
Gh
На всем этом крутится свое облако nextcloud, home assistant, git, svn, transmission, samba, локальный ИИ в виде lm studio и ollama. Ну и всякая мелочевка.
Я ни разу автора не критикую. Как поиграться и что-то освоить почему бы и нет. Но очень быстро приходит осознание того, что решение крайне ограничено и надо что-то менять. К примеру свое облако на таком железе будет просто шевелиться, не бегать, а о возможности использовать nextcloud office/Collabora придется только мечтать.
Чуть по подробнее про железо не напишите?
Чисто по личному опыту (неделю вожусь с локальными llm, на личном сервере xeon 1240lv3, 16g ram, 5060 ti 16 gb):
- lm studio на linux сервере значительно быстрее чем ollama (начинал с нее), а главное не жрет так память
- перепробовал много моделей, пока для общего применения оптимальна openai/gpt-oss-20b - влезла в 12.2 gb VRAM с контекстом 65536
- отлично интегрировалась с open webui (через openai)
- при желании ставится вообще без gui
- при некоторых танцах с бубном заработала с home assistant
1) Хранить весь трафик за последние 3...7 дней (тоже не мало, но скорее всего подъемно). Возможно с какими-то фильтрами (ну нафига, например хранить трансляции с того же ivi.ru) бесполезного
2) Хранить трафик определенных абонентов по запросу спецслужб в течении месяца (потом повторный запрос, если необходимо)
3) Хранить трафик определенных абонентов по решению суда до полугода
4) Хранить историю звонков и, возможно, смс (последние малополезны конечно) в течение полугода-года.
Я все это конечно очень условно. Но что-то подобное потребовало бы уже куда меньших ресурсов и было бы подъемно для последующего анализа