Мож кто подскажет в каком направлении двигаться.
Ставим на миникомпы Octagon DOS 6.22. Cтрельнуло USB использовать. Нашли в инэте драйверок под USB-Flash, вроде работает, но частенько (10мин-1час) перестаёт , диск пропадает.
Вроде как дос уже и не в моде, найти что-то под него проблемно. Подскажите, можно ли сделать Linux с такими требованиями: объём не более 20-50 Мб, текстовый режим - графики обсалютно не требуется, поддержка USB - хотя бы flash.
Спасибо.

можно - и даже скромнее. Но процессор - не хуже 386. Кстати, не только Linux - QNX, Minix то же годятся.

Ещё бы добавил FreeBSD / NetBSD / OpenBSD.

Как собрать свою miniBSD - https://neon1.net/
(где-то в сети и перевод статьи "miniBSD - reducing FreeBSD" часто встречается).
Ещё один хороший ресурс того же автора из Чехии - http://m0n0.ch/wall/

Есть и масса готовых мини-юниксовых-сборок.

Есть даже pico-BSD - на дискете живет.

Вопрос в том, требуется ли система жесткого реального времени? Если нет, то можно смело ставить linux или BSD. Если нужна rtos - то QNX или т.п.

Обсалютно не требуется. Более или менее точный отсчёт каждой секунды,всё остальное время цикл отрисовки и работы с АЦП. Другое дело из программеров в конторе только я. А что есть линукс и с чем его едят обсалютно ничего не знаю.Если не сложно, мож кто знает ссылочку на какую исошку, чтоб не сильно заморачиваться в начале. Хотябы увидеть рузультат ,а дальше уж разобрался бы. У кого знакомых спрашивал скидывают на убунту, рэд хэт и тд. , а проц то 133мгц.

Прежде, чем бросаться на Линукс, следует понять, что получив на халяву поддержку USB, придется писать, как минимум, драйвера того, что "отрисовывает" и АЦП. Вы к такому повороту событий готовы?
Может для Вашего случая проще разобраться с поддержкой USB под DOS?

Если в ОС есть возможность простейшего обращения к зазаданному адресу и вывод строки на экран, этого уже хватит.

А кроме филипсовского USB драйвера под дос ничего толкового не видел. Написано что поддерживает валом USB устройств,но увы не всё так чисто. Думается написать драйвер USB под DOS будет не только одному мне не под силу. Из двух бед.......

Есть там все.

Ставил на модули Kontron с графикой и видеопроигрыватели и т.п. 60МБ на диске заняло все дело.
Здесь http://www.linuxfromscratch.org/ можно взять мануал LFS и почитать, что к чему. Но особо не заморачиваться сборкой софта, особенно предварительного, а просто для понимания вопроса - что вообще надо на целевой системе.

А что за железо?

Есть нюанс - там MOЖНО сделать практически все.

Железо - x86 совместимый комп Octagon 5070 . Требуется очень не много, пару меню из псевдографики,работа с прерываниями,клавой,usb и com. Экран 320*240 ч/б если так можно сказать. Собирает АЦП-шкой данные с датчиков,проверяет и пишет каждую секунду на внешний и внутренний носители. Вроде всё просто ,но повышенные требования к исполнению, -40 по цельсию,влага,тряска - как оборонка.

zltigo +1
Wano, чтобы посмотреть что есть линукс самый простой способ раздобыть livecd, система не требует установки, ставите диск в привод и у вас рабочая ос. Начиналось все по-моему с knoppix, а сейчас таких полно на любой вкус. Для ознакомления самое то.

А вот ознакомиться мне думается лучше на вашей рабочей машине, которая помощнее смысле. Разобраться с работой консоли, посмотреть средства разработки и подумать, а надо ли оно. И если вывод положительный уже ставить это все дело на ваш Octagon.

Как вариант linux + dosemu, почти ничего из уже написанного переделывать не придется. Неужели так грустно обстоят дела с USB во free dos варинтах ?

Я имел в виду, на сколько совместимый?
CPU/RAM/ChipSet/HDD (ну или что там вместо него).



+1

+2
Можно еще Линукс в виртуальную машину поставить.
Некоторые livecd на столько live, что прямо из них можно и программы писать (клоны Knoppix).

Если архитектура процессора более или менее совпадает (PC и Octagon) то для начала можно просто копировать нужные библиотеки и приложения с ПК на Вашу плату.
Ну типа Ваш Октагон 586 и Линукс на ПК тоже 586.

С другос стороны Ваш случай мало чем отличается, например, от Линукс на АРМ. Алгоритм действий тот-же.




http://www.slackware.org/
Поскромнее будет в требованиях.
Или
http://deepstyle.org.ua/
Если критичен язык общения.

нашёл

http://www.damnsmalllinux.org/

поставил,запустил. Начально после загрузки хавает почти всю мою оперативу - 25 метров из 32.
Это всё конечно хорошо. Как я понял компиллер имеется в любой Linux. Может кто подскажет как им воспользоваться для создания exe-шника?

slackware имеет отладчика и компиллера как приложение,но пока этот Linux ещё не качал.

gcc src.c -o src.exe

А вообще в *никсах экзешников нет. Исполняемые файлы там обозначаются соответствующим битом в атрибутах, а расширение может быть любым (чаще всего вообще без расширения).

gcc src.c - o proga
./proga

Ну ещё бы ему не хавать, он новерно intrd (Initial RAM disk) разворачивает в память. Эти livecd как правило жрут больше обычной установки. Если у Вас мало памяти - скачайте старую слаку. Linux следует мэйнстриму, потому ядро 2.4 жрёт больше 2.2, а 2.6 больше 2.4. Или попробуйте Deli.gcc -O2 -Wall -s -pipe -o my_first_program my_first_program.c

Если нужно минимальное использование ресурсов - то проще все-таки использовать FreeBSD. Там процедура пересборки ядра под конкретные требования хорошо прописана. А без пересборки ядра минимизировать использование ресурсов не получится.

А не могли бы Вы подробнее о преимуществах FreeBSD? По сравнению с Linux. В части памяти, в последнее время меня эта тема весьма интересует.

DSL использует для корневой файловой системы squashfs+unionfs и не грузит ее полностью в память (если не задать спец. ключ при запуске, что то вроде copy2ram). А память "улетает" так потому, что линукс все, к чему обращается, пытается закешировать; при малейшей потребности в физической памяти кеш уменьшается. Поэтому загрузка RAM ~90% - это штатная ситуация

Пересобрать ядро не так уж и сложно, сложнее rootfs сделать. Копать начинать нужно либо отсюда http://www.linuxfromscratch.org/ либо отсюда http://buildroot.uclibc.org/ Хотя buildroot - это просто набор скриптов для автоматизации сборки (причем, глючный ).

В общем, консольная отладочная версия с 2.6.21 ядром и uclibc занимает примерно 7мб на диске и 15мб в памяти (rootfs полностью грузится в память). И это включая многие ненужные в боевых условиях приложения, вроде mc. Да и не debug-версия ядра тоже будет меньше.

Как-то не совсем понятно - нужна ли rootfs в памяти. Вроде же там есть IDE-диск (CompactFlash), его и смонтировать в корневище.

Вопрос риторический

Нужны достаточно веские причины, чтобы было необходимо ее там размещать в боевых условиях, ведь за это придется платить физической памятью. К тому же, механизм кеширования довольно эффективен, что еще сильнее уменьшает выигрыш (все равно бОльшая часть rootfs окажется в кеше). В "обычных" многотиражных изделиях (вроде тех же adsl модемов) выгоднее сэкономить на памяти и уменьшить себестоимость изделия.

С другой стороны, вся ОС может быть представлена в виде двух файлов, нет зависимости от вида "несущей" файловой системы и т.п., что значительно облегчает отладку. Есть и другие неявные плюсы (которые не всегда требуются). Те числа, что я привел (просто для оценки порядка требуемых ресурсов), относятся имненно для "внутренней", дебажной версии ОС на которой идет первоначальная отладка. А окончательная структура уже зависит от конкретной задачи.
Так что однозначного ответа нет.

Может мы о разных DSL? А то я скачал dsl-4.2.2.iso и не обнаружил squashfs, это оказывается клон knoppix-а, там compressed loop. Зато есть /ramdisk 21400k, при 32M памяти.С этим никто не спорит - я полагаю, что livecd не показательны с точки зрения потребления памяти - часть файловой системы всё равно в RAM.Какие-то не очень существенные преимущества. У автора темы замеры хранятся на "внутреннем носителе". ИМХО roofs в памяти совсем не нужна.

Подскажите такой нюанс. Программа сохраняет на USB данные,если в DOS никакого кэширования я не видел,то dsl достаточно долго соображала(секунд 5-10) и только после этого начала записывать на диск,хотя в файловом менеджере файл уже появился. Тоесть если бахнет питание внезапно, последние данные можно потерять? Не сказать что это очень критично, но всё же.

Фик его знает, хотя скорее всего потеряються.
Можете указать при монтировании параметр sync, примерно так:
mount /dev/<что> /mnt/<куда> -o sync,umask=0000,iocharset=cp1251

Только есть нюанс (как известно, ничего даром не дается :-)! Цитирую:
"Предупреждение: ...опция sync в параметрах mount убьет Вашу флешку с гарантией за 6 месяцев использования."
Так что, DOS, похоже, медленно убивает вашу флешку...

Ну а более подробно:
HOWTO Udev и автомонтирование носителей


С версии 2.6 ядра подддерживают не только initrd, но и initramfs. Удобная штучка, помимо всего прочего позволяет образ rootfs слинковать с ядром при компиляции. Таким образом грузить надо один файл (ядро), а не 2, как в случае с initrd. Но эт все лирика.
Нетак давно экспериментировал с этим. buildroot, как раз позволяет (среди прочего) собрать образ initramfs. Вобщем, ядро с поддержкой сети (но без поддержки каких бы то нибыло ФС), у меня получилось минимально -- 1101728 байт. Это уже с прилинкованой initramfs, содержащей стартовые скрипты и busybox... Вполне рабочая системка. Вовсяком случае, просит логин, после логона, попадаешь в шелл. Вроде, даже сеть заводит, но не уверен, не помню.
Теперь о потреблении памяти.
Все эксперименты проводил в qemu. Минимально, на скольки мне удалось завести данное ядро -- 7 метров:
qemu -m 7 -kernel bzImage -hda hda.img -net nic -net tap,ifname=tap0
Причем, видно, что подтормаживает. На 10 метрах ядро грузиться секунды за 4-5.
Поскольку непонял, как приаттачить здесь файл, могу куда-нить выложить само ядро, конфиг и образ initramfs, для экспериментов.

Так что, buildroot мне понравился. ;-)

Не раз проверено - ядро 2.4, gpm, mc, без свопа: нормально грузится на 8 мегабайтах + примерно 2 мегабайта остается для программ (malloc). С сетью и nfs уже 1. Копировать удалять и т.п. можно, но bz2 уже не распакуеш (gz можно). В общем впритык, но работает.