Linux для x86, Можно ли получить аналогичное на Linux Опции

[Harbour]

gcc src.c -o src.exe

[forever failure]

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

gcc src.c - o proga
./proga

[733259]

нашёл

http://www.damnsmalllinux.org/

поставил,запустил. Начально после загрузки хавает почти всю мою оперативу - 25 метров из 32.

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

gcc src.c - o proga

gcc -O2 -Wall -s -pipe -o my_first_program my_first_program.c

[vvs157]

нашёл

http://www.damnsmalllinux.org/

поставил,запустил. Начально после загрузки хавает почти всю мою оперативу - 25 метров из 32.

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

[733259]

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

[vshemm]

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-версия ядра тоже будет меньше.

[733259]

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

[vshemm]

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

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

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

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

[733259]

DSL использует для корневой файловой системы squashfs+unionfs и не грузит ее полностью в память (если не задать спец. ключ при запуске, что то вроде copy2ram).

Может мы о разных DSL? А то я скачал dsl-4.2.2.iso и не обнаружил squashfs, это оказывается клон knoppix-а, там compressed loop. Зато есть /ramdisk 21400k, при 32M памяти.

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

С этим никто не спорит - я полагаю, что livecd не показательны с точки зрения потребления памяти - часть файловой системы всё равно в RAM.

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

Какие-то не очень существенные преимущества. У автора темы замеры хранятся на "внутреннем носителе". ИМХО roofs в памяти совсем не нужна.

[Wano]

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

[Damon]

Подскажите такой нюанс.
...
Тоесть если бахнет питание внезапно, последние данные можно потерять? Не сказать что это очень критично, но всё же.

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

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

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

Хотя buildroot - это просто набор скриптов для автоматизации сборки (причем, глючный ).

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

С версии 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 мне понравился. ;-)

Сообщение отредактировал Damon - Jan 5 2008, 12:06

[733259]

Все эксперименты проводил в qemu. Минимально, на скольки мне удалось завести данное ядро -- 7 метров:
qemu -m 7 -kernel bzImage -hda hda.img -net nic -net tap,ifname=tap0
Причем, видно, что подтормаживает. На 10 метрах ядро грузиться секунды за 4-5.
Поскольку непонял, как приаттачить здесь файл, могу куда-нить выложить само ядро, конфиг и образ initramfs, для экспериментов.

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