[devel] propagator - diet vs glibc

[devel] propagator - diet vs glibc

[Nick S. Grechukh]

приветствую

предпосылки: хотел поковырять пропагатор на предмет кэширования stage2
в method:cdrom. оказалось, что простой пересборки в хэшере он не
переживает - ловит signal 11 после загрузки. lioka намекнул на танцы
вокруг diet, с которыми я решил не заморачиваться.

в процессе перевода оказалось, что поддержка разных libc там когда-то
была, но сейчас многое прибито гвоздями в Makefile. гвозди вытащил и
прибил свои ;)

результат:

propagator собирается на static glibc с gcc3.4.4/4.1 и (на первый и
второй взгляд) нормально работает.  оверхэд на бинарниках: diet 200к,
glibc - 1.2m. разница full.cz - 2.3m vs 2.7m.

план работ:
- сделать более аккуратный патч для propagator и mar.
- протестировать на method:nfs,method:ftp. с cdrom/disk/http вроде бы работает.

сейчас src.rpm уплывут на paq

Re: [devel] propagator - diet vs glibc

[Konstantin A. Lepikhov]

<цитата от="Nick S. Grechukh">
...
>
> план работ:
> - сделать более аккуратный патч для propagator и mar.
> - протестировать на method:nfs,method:ftp. с cdrom/disk/http вроде бы
> работает.
>
> сейчас src.rpm уплывут на paq
а смысл? nfs/ftp и сейчас работают. mar вообще выкидывать надо, как и все
эти костыли в пропагаторе насчет детекта железа или собственной сетевой
библиотеки.

-- 
WBR et al.

Re: [devel] propagator - diet vs glibc

[Mikhail Yakshin]

Nick S. Grechukh пишет:
> предпосылки: хотел поковырять пропагатор на предмет кэширования stage2
> в method:cdrom. оказалось, что простой пересборки в хэшере он не
> переживает - ловит signal 11 после загрузки. lioka намекнул на танцы
> вокруг diet, с которыми я решил не заморачиваться.
> 
> в процессе перевода оказалось, что поддержка разных libc там когда-то
> была, но сейчас многое прибито гвоздями в Makefile. гвозди вытащил и
> прибил свои ;)
> 
> результат:
> 
> propagator собирается на static glibc с gcc3.4.4/4.1 и (на первый и
> второй взгляд) нормально работает.  оверхэд на бинарниках: diet 200к,
> glibc - 1.2m. разница full.cz - 2.3m vs 2.7m.
> 
> план работ:
> - сделать более аккуратный патч для propagator и mar.
> - протестировать на method:nfs,method:ftp. с cdrom/disk/http вроде бы работает.

А можно тогда первым делом убить этот ужасный mar и заменить его хотя бы 
на какой-нибудь gzip? Всем проще будет %)

-- 
WBR, Mikhail Yakshin

Re: [devel] propagator - diet vs glibc

[Nick S. Grechukh]

2007/2/2, Konstantin A. Lepikhov <lakostis@altlinux.ru>:
> <цитата от="Nick S. Grechukh">
> ...
> >
> > план работ:
> > - сделать более аккуратный патч для propagator и mar.
> > - протестировать на method:nfs,method:ftp. с cdrom/disk/http вроде бы
> а смысл? nfs/ftp и сейчас работают.

смысл в том, что сейчас пропагатор собирается, но не работает. а в чем
смысл возиться с dietlibc (и отдельно собирать под нее пакеты нужные
пропагатору) ради 300 кб?


> mar вообще выкидывать надо, как и все
> эти костыли в пропагаторе насчет детекта железа

зачем? на что менять?

Re: [devel] propagator - diet vs glibc

[Nick S. Grechukh]

> А можно тогда первым делом убить этот ужасный mar и заменить его хотя бы
> на какой-нибудь gzip? Всем проще будет %)

тогда уж cpio, потому что контейнер. да и вообще можно модули открытым
текстом класть в full.cz

Re: [devel] propagator - diet vs glibc

[Konstantin A. Lepikhov]

<цитата от="Nick S. Grechukh">
> 2007/2/2, Konstantin A. Lepikhov <lakostis@altlinux.ru>:
>> <цитата от="Nick S. Grechukh">
>> ...
>> >
>> > план работ:
>> > - сделать более аккуратный патч для propagator и mar.
>> > - протестировать на method:nfs,method:ftp. с cdrom/disk/http вроде бы
>> а смысл? nfs/ftp и сейчас работают.
>
> смысл в том, что сейчас пропагатор собирается, но не работает. а в чем
> смысл возиться с dietlibc (и отдельно собирать под нее пакеты нужные
> пропагатору) ради 300 кб?
у меня собирается. А пакеты можно вычистить. Например, тот же интерфейс на
ncurses вполне можно сделать консольным.

>
>
>> mar вообще выкидывать надо, как и все
>> эти костыли в пропагаторе насчет детекта железа
>
> зачем? на что менять?
не менять, а выкинуть ;) Все это было придумано, когда не было initramfs и
сейчас большей частью неактуально (разве что мозг с выбором типа установки
можно оставить).

-- 
WBR et al.

Re: [devel] propagator - diet vs glibc

[Mikhail Yakshin]

Nick S. Grechukh пишет:
>> А можно тогда первым делом убить этот ужасный mar и заменить его хотя бы
>> на какой-нибудь gzip? Всем проще будет %)
> 
> тогда уж cpio, потому что контейнер. да и вообще можно модули открытым
> текстом класть в full.cz

Ну, это и имеется в виду - cpio или tarball. Класть открытым текстом 
нельзя, так мы угробим лишние 30-40 мегабайт памяти пользователю, если я 
правильно понимаю.

-- 
WBR, Mikhail Yakshin

Re: [devel] propagator - diet vs glibc

[Nick S. Grechukh]

2007/2/2, Konstantin A. Lepikhov <lakostis@altlinux.ru>:
>
> <цитата от="Nick S. Grechukh">
> > 2007/2/2, Konstantin A. Lepikhov <lakostis@altlinux.ru>:
> >> <цитата от="Nick S. Grechukh">
> >> ...
> >> >
> >> > план работ:
> >> > - сделать более аккуратный патч для propagator и mar.
> >> > - протестировать на method:nfs,method:ftp. с cdrom/disk/http вроде бы
> >> а смысл? nfs/ftp и сейчас работают.
> >
> > смысл в том, что сейчас пропагатор собирается, но не работает. а в чем
> > смысл возиться с dietlibc (и отдельно собирать под нее пакеты нужные
> > пропагатору) ради 300 кб?
> у меня собирается.

у меня тоже. беру propagator-20061123-alt1.src.rpm, собираю его в
хэшере, делаю образ в spt, загружаю.

получаю сразу после запуска 11 сигнал  и ругань про это зеленым цветом.

берем ту же версию бинарную из сизифа, собираем образ. работает.

> А пакеты можно вычистить.

к чему там вообще diet ?

> Например, тот же интерфейс на ncurses вполне можно сделать консольным.

курсес красивше :)

Re: [devel] propagator - diet vs glibc

[Nick S. Grechukh]

2007/2/2, Mikhail Yakshin <greycat@altlinux.org>:
> Nick S. Grechukh пишет:
> >> А можно тогда первым делом убить этот ужасный mar и заменить его хотя бы
> >> на какой-нибудь gzip? Всем проще будет %)
> >
> > тогда уж cpio, потому что контейнер. да и вообще можно модули открытым
> > текстом класть в full.cz
>
> Ну, это и имеется в виду - cpio или tarball. Класть открытым текстом
> нельзя, так мы угробим лишние 30-40 мегабайт памяти пользователю, если я
> правильно понимаю.

нет, туда кладутся только из списка profile/modules. разница -
завернуть их в mar или просто положить.

Re: [devel] propagator - diet vs glibc

[Mikhail Yakshin]

Nick S. Grechukh пишет:
> 2007/2/2, Mikhail Yakshin <greycat@altlinux.org>:
>> Nick S. Grechukh пишет:
>>>> А можно тогда первым делом убить этот ужасный mar и заменить его хотя бы
>>>> на какой-нибудь gzip? Всем проще будет %)
>>> тогда уж cpio, потому что контейнер. да и вообще можно модули открытым
>>> текстом класть в full.cz
>> Ну, это и имеется в виду - cpio или tarball. Класть открытым текстом
>> нельзя, так мы угробим лишние 30-40 мегабайт памяти пользователю, если я
>> правильно понимаю.
> 
> нет, туда кладутся только из списка profile/modules.

Я как бы немножко в курсе ;)

 > разница - завернуть их в mar или просто положить.

Этот бутовый рамдиск, с которого мы грузим propagator, насколько я 
понимаю, после pivot и загрузки нормального рута, никуда не девается и 
остается висеть в памяти, правда, недоступный.

-- 
WBR, Mikhail Yakshin

Re: [devel] propagator - diet vs glibc

[Nick S. Grechukh]

2007/2/2, Mikhail Yakshin <greycat@altlinux.org>:
> Nick S. Grechukh пишет:
> > 2007/2/2, Mikhail Yakshin <greycat@altlinux.org>:
> >> Nick S. Grechukh пишет:
> >>>> А можно тогда первым делом убить этот ужасный mar и заменить его хотя бы
> >>>> на какой-нибудь gzip? Всем проще будет %)
> >>> тогда уж cpio, потому что контейнер. да и вообще можно модули открытым
> >>> текстом класть в full.cz
> >> Ну, это и имеется в виду - cpio или tarball. Класть открытым текстом
> >> нельзя, так мы угробим лишние 30-40 мегабайт памяти пользователю, если я
> >> правильно понимаю.
> >
> > нет, туда кладутся только из списка profile/modules.
>
> Я как бы немножко в курсе ;)

так откуда 30-40 мегабайт? ;)

>  > разница - завернуть их в mar или просто положить.
> > Этот бутовый рамдиск, с которого мы грузим propagator, насколько я
> понимаю, после pivot и загрузки нормального рута, никуда не девается и
> остается висеть в памяти, правда, недоступный.

тут я не компетентен. а о чем говорится "disconnecting life support
filesystem" ?

Re: [devel] propagator - diet vs glibc

[Mikhail Yakshin]

Nick S. Grechukh пишет:
> 2007/2/2, Mikhail Yakshin <greycat@altlinux.org>:
>> Nick S. Grechukh пишет:
>>> 2007/2/2, Mikhail Yakshin <greycat@altlinux.org>:
>>>> Nick S. Grechukh пишет:
>>>>>> А можно тогда первым делом убить этот ужасный mar и заменить его хотя бы
>>>>>> на какой-нибудь gzip? Всем проще будет %)
>>>>> тогда уж cpio, потому что контейнер. да и вообще можно модули открытым
>>>>> текстом класть в full.cz
>>>> Ну, это и имеется в виду - cpio или tarball. Класть открытым текстом
>>>> нельзя, так мы угробим лишние 30-40 мегабайт памяти пользователю, если я
>>>> правильно понимаю.
>>> нет, туда кладутся только из списка profile/modules.
>> Я как бы немножко в курсе ;)
> 
> так откуда 30-40 мегабайт? ;)

Ну 30-40 - это если класть все по максимуму.

>>  > разница - завернуть их в mar или просто положить.
>>> Этот бутовый рамдиск, с которого мы грузим propagator, насколько я
>> понимаю, после pivot и загрузки нормального рута, никуда не девается и
>> остается висеть в памяти, правда, недоступный.
> 
> тут я не компетентен. а о чем говорится "disconnecting life support
> filesystem" ?

О том, что закрыт log, куда пишется последнее такое сообщение. Если 
после этой фразы что-то падает на finish-чем-то там, то никаких 
сообщений вообще не будет.

-- 
WBR, GreyCat

Re: [devel] propagator - diet vs glibc

[Nick S. Grechukh]

http://paq.osdn.org.ua/~gns/propagator/

вначале собрать mar, затем сам propagator. в readytogo лежит готовый
инитрамфс для тестирования в qemu.

Re: [devel] propagator - diet vs glibc

[Nick S. Grechukh]

2007/2/2, Mikhail Yakshin <greycat@altlinux.org>:
> Nick S. Grechukh пишет:
> > 2007/2/2, Mikhail Yakshin <greycat@altlinux.org>:
> >> Nick S. Grechukh пишет:
> >>> 2007/2/2, Mikhail Yakshin <greycat@altlinux.org>:
> >>>> Nick S. Grechukh пишет:
> >>>>>> А можно тогда первым делом убить этот ужасный mar и заменить его хотя бы
> >>>>>> на какой-нибудь gzip? Всем проще будет %)
> >>>>> тогда уж cpio, потому что контейнер. да и вообще можно модули открытым
> >>>>> текстом класть в full.cz
> >>>> Ну, это и имеется в виду - cpio или tarball. Класть открытым текстом
> >>>> нельзя, так мы угробим лишние 30-40 мегабайт памяти пользователю, если я
> >>>> правильно понимаю.
> >>> нет, туда кладутся только из списка profile/modules.
> >> Я как бы немножко в курсе ;)
> >
> > так откуда 30-40 мегабайт? ;)
>
> Ну 30-40 - это если класть все по максимуму.

ага. так ведь в mar/tar/cpio они ненамного меньше были бы.

Re: [devel] propagator - diet vs glibc

[Mikhail Yakshin]

Nick S. Grechukh пишет:
>>>>> нет, туда кладутся только из списка profile/modules.
>>>> Я как бы немножко в курсе ;)
>>> так откуда 30-40 мегабайт? ;)
>> Ну 30-40 - это если класть все по максимуму.
> 
> ага. так ведь в mar/tar/cpio они ненамного меньше были бы.

Они примерно так:

Выборочные + запакованные ~ 2.5 мега
Выборочные + незапакованные ~ 9-10 мегов
Все + запакованные ~ 10-11 мегов
Все + незапакованные ~ 35-50-55 мегов

Отсюда и решать, сколько не жалко требовать с пользователя.

Кстати, относительно pivot'а в propagator - он делается так:

         /* overmount image under new root if needed */
         if ( statfs(IMAGE_LOCATION, &sfs) )
                 fatal_error("statfs "IMAGE_LOCATION);
         /* if something is mounted under IMAGE_LOCATION ? */
         if ( sfs.f_type != RAMFS_MAGIC && sfs.f_type != TMPFS_MAGIC ) {
                 if ( mount(IMAGE_LOCATION, "." IMAGE_LOCATION, NULL, 
MS_MOVE, NULL) )
                         fatal_error("overmounting image location");
                 /* test for nested mount: disk or nfs with iso image */
                 if ( statfs(IMAGE_LOCATION, &sfs) )
                         fatal_error("nested statfs "IMAGE_LOCATION);
                 if ( sfs.f_type != RAMFS_MAGIC && sfs.f_type != 
TMPFS_MAGIC )
                         if ( mount(IMAGE_LOCATION, "." IMAGE_LOCATION 
"/isolinux", NULL, MS_MOVE, NULL) )
                                 fatal_error("overmounting nested image 
location");
         }

         umount("/sys");
         umount("/proc/bus/usb");
         umount("/proc");

         /* Delete rootfs contents */
         if ( nuke_dir("/") )
                 fatal_error("nuking initramfs contents");

         /* Overmount the root */
         if ( mount(".", "/", NULL, MS_MOVE, NULL) )
                 fatal_error("overmounting root");

         /* chroot, chdir */
         if (chroot(".") || chdir("/"))
                 fatal_error("chroot");

Судя по вот этому вызову nuke_dir - если он действительно отрабатывает и 
у нас ramfs/tmpfs - то все должно быть хорошо. Просто мы поднимаем 
планку минимального количества памяти, на которой запустится наш новый 
propagator.

-- 
WBR, Mikhail Yakshin AKA GreyCat

Re: [devel] propagator - diet vs glibc

[Nick S. Grechukh]

2007/2/2, Mikhail Yakshin <greycat@altlinux.org>:
> Nick S. Grechukh пишет:
> Они примерно так:
> Выборочные + запакованные ~ 2.5 мега
> Выборочные + незапакованные ~ 9-10 мегов
> Все + запакованные ~ 10-11 мегов
> Все + незапакованные ~ 35-50-55 мегов
понятно. mar чем хорош, из него вытягивается без распаковки.

> Отсюда и решать, сколько не жалко требовать с пользователя.
> Кстати, относительно pivot'а в propagator - он делается так:
>
>          /* overmount image under new root if needed */
>          if ( statfs(IMAGE_LOCATION, &sfs) )
>                  fatal_error("statfs "IMAGE_LOCATION);
>          /* if something is mounted under IMAGE_LOCATION ? */
>          if ( sfs.f_type != RAMFS_MAGIC && sfs.f_type != TMPFS_MAGIC ) {
>                  if ( mount(IMAGE_LOCATION, "." IMAGE_LOCATION, NULL,
> MS_MOVE, NULL) )
>                          fatal_error("overmounting image location");
>                  /* test for nested mount: disk or nfs with iso image */
>                  if ( statfs(IMAGE_LOCATION, &sfs) )
>                          fatal_error("nested statfs "IMAGE_LOCATION);
>                  if ( sfs.f_type != RAMFS_MAGIC && sfs.f_type !=
> TMPFS_MAGIC )
>                          if ( mount(IMAGE_LOCATION, "." IMAGE_LOCATION
> "/isolinux", NULL, MS_MOVE, NULL) )
>                                  fatal_error("overmounting nested image
> location");
>          }
>
>          umount("/sys");
>          umount("/proc/bus/usb");
>          umount("/proc");
>
>          /* Delete rootfs contents */
>          if ( nuke_dir("/") )
>                  fatal_error("nuking initramfs contents");
>
>          /* Overmount the root */
>          if ( mount(".", "/", NULL, MS_MOVE, NULL) )
>                  fatal_error("overmounting root");
>
>          /* chroot, chdir */
>          if (chroot(".") || chdir("/"))
>                  fatal_error("chroot");
>
> Судя по вот этому вызову nuke_dir - если он действительно отрабатывает и
> у нас ramfs/tmpfs - то все должно быть хорошо. Просто мы поднимаем
> планку минимального количества памяти, на которой запустится наш новый
> propagator.

это написано в filesystems/ramfs-rootfs-initramfs.txt
  - When switching another root device, initrd would pivot_root and then
    umount the ramdisk.  But initramfs is rootfs: you can neither pivot_root
    rootfs, nor unmount it.  Instead delete everything out of rootfs to
    free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs
    with the new root (cd /newmount; mount --move . /; chroot .), attach
    stdin/stdout/stderr to the new /dev/console, and exec the new init.

а пропагатор именно initramfs.

Re: [devel] propagator - diet vs glibc

[Nick S. Grechukh]

[-- Attachment #1: Type: text/plain, Size: 28 bytes --]

вот аккуратный патч на гит.

[-- Attachment #2: propagator.git-20061123-glibc.gns2.patch --]
[-- Type: text/x-patch, Size: 3554 bytes --]

diff --git a/Makefile b/Makefile
index 925cf26..e46ff11 100644
--- a/Makefile
+++ b/Makefile
@@ -83,7 +83,7 @@ INITOBJS = $(subst .c,.o,$(INITSRC))
 
 #- frontends
 NEWT_FRONTEND_SRC = newt-frontend.c
-GLIBC_NEWT_FRONTEND_LIBS = newt/libnewt.a slang/libslang.a
+GLIBC_NEWT_FRONTEND_LIBS = $(LIBDIR)/libnewt.a $(LIBDIR)/libslang.a
 DIETLIBC_NEWT_FRONTEND_LIBS = $(DIET_LIBDIR)/libnewt.a $(DIET_LIBDIR)/libslang.a
 
 STDIO_FRONTEND_SRC = stdio-frontend.c
@@ -94,7 +94,7 @@ DIETLIBC_STDIO_FRONTEND_LIBS =
 FRONTEND_OBJS = $(subst .c,.o,$($(F)_FRONTEND_SRC))
 FRONTEND_LINK = $(FRONTEND_OBJS) $($(L)_$(F)_FRONTEND_LIBS)
 
-GLIBC_STAGE1_OWN_LIBS = mar/libmar.a /usr/lib/libbz2.a
+GLIBC_STAGE1_OWN_LIBS = $(LIBDIR)/libmar.a $(LIBDIR)/libbz2.a
 DIETLIBC_STAGE1_OWN_LIBS = $(DIET_LIBDIR)/libmar.a $(DIET_LIBDIR)/libbz2.a
 STAGE1_OWN_LIBS = $($(L)_STAGE1_OWN_LIBS)
 
@@ -125,8 +125,8 @@ ifeq (ia64, $(ARCH))
 LDFLAGS_INIT = $(GLIBC_LDFLAGS_STAGE1)
 INIT_LIBC = $(GLIBC_LIBC)
 else
-LDFLAGS_INIT = $(DIETLIBC_LDFLAGS_STAGE1)
-INIT_LIBC = $(DIETLIBC_LIBC)
+LDFLAGS_INIT = $(GLIBC_LDFLAGS_STAGE1)
+INIT_LIBC = $(GLIBC_LIBC)
 endif
 endif
 
diff --git a/Makefile.common b/Makefile.common
index ffd02c0..f892ff0 100644
--- a/Makefile.common
+++ b/Makefile.common
@@ -14,13 +14,13 @@
  #
  #*****************************************************************************
 
-include /usr/lib/dietlibc/Makefile.rules
+#include /usr/lib/dietlibc/Makefile.rules
 
-DIET_LIBDIR = /usr/lib/dietlibc/lib-$(ARCH)
+#DIET_LIBDIR = /usr/lib/dietlibc/lib-$(ARCH)
 
  #- default lib is dietlibc (honoured by main Makefile whenever possible)
-L = DIETLIBC
-#L = GLIBC
+#L = DIETLIBC
+L = GLIBC
 
  #- default frontend is newt (honoured by main Makefile whenever possible)
 F = NEWT
diff --git a/init.c b/init.c
index 7f394bc..942d734 100644
--- a/init.c
+++ b/init.c
@@ -377,8 +377,6 @@ void unmount_filesystems(void)
 #define RAMFS_MAGIC 0x858458f6
 #define TMPFS_MAGIC 0x01021994
 
-#define MS_MOVE 8192
-
 int main(int argc, char **argv)
 {
 	struct stat rst, cst, ist;
diff --git a/network.c b/network.c
index 29d41d2..5cb7b75 100644
--- a/network.c
+++ b/network.c
@@ -18,6 +18,8 @@
  * Copyright 1996 Red Hat Software 
  *
  */
+#include <sys/types.h>
+#include <sys/stat.h>
 
 #include <stdlib.h>
 #include <unistd.h>
diff --git a/propagator.spec b/propagator.spec
index 7562eaa..250cc26 100644
--- a/propagator.spec
+++ b/propagator.spec
@@ -5,7 +5,7 @@
 
 Name: propagator
 Version: 20061123
-Release: alt1
+Release: alt1.0.glibc.1
 
 Summary: 'Early userspace' set of binaries
 License: GPL
@@ -13,7 +13,10 @@ Group: System/Kernel and hardware
 
 Source0: %name-%version.tar.bz2
 
-BuildRequires: gcc3.4 dietlibc diet-bzlib >= 20050707 diet-newt >= 20050707 diet-slang >= 20050707 mar
+BuildPreReq: mar-glibc
+
+# Automatically added by buildreq on Thu Feb 01 2007
+BuildRequires: bzlib-devel-static libnewt-devel-static libslang-devel-static
 
 %description
 %name is a set of binaries useful in 'early userspace' environment,
@@ -23,7 +26,6 @@ including init and various helpers for hw probing and bootstrapping.
 %setup -qc
 
 %build
-%set_gcc_version 3.4
 make %{?_with_shell:WITH_SHELL=t}
 
 %install
@@ -34,6 +36,9 @@ make %{?_with_shell:WITH_SHELL=t}
 %_libdir/%name
 
 %changelog
+* Fri Feb 02 2007 Nick S. Grechukh <gns@altlinux.ru> 20061123-alt1.0.glibc.1
+- accurate glibc patch, instead of published dirty hack
+
 * Thu Nov 23 2006 Sergey Bolshakov <sbolshakov@altlinux.ru> 20061123-alt1
 - added conditional shell spawning
 - fixed probing of some RAID adaptors

[devel] [JT] Re: propagator - diet vs glibc

[Michael Shigorin]

On Fri, Feb 02, 2007 at 01:53:44PM +0200, Nick S. Grechukh wrote:
> > Например, тот же интерфейс на ncurses вполне можно сделать консольным.
> курсес красивше :)

И напоминает древний mdk ;)

На самом деле не уверен, что "красивше" и вообще "нужно",
но не моя парафия и "работает -- не трогай"...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] propagator - diet vs glibc

[Michael Shigorin]

On Sun, Feb 04, 2007 at 11:56:17AM +0200, Nick S. Grechukh wrote:
> > Они примерно так:
> > Выборочные + запакованные ~ 2.5 мега
> > Выборочные + незапакованные ~ 9-10 мегов
> > Все + запакованные ~ 10-11 мегов
> > Все + незапакованные ~ 35-50-55 мегов
> понятно. mar чем хорош, из него вытягивается без распаковки.

Я когда-то заикался, что в округе у некоторых парней модули
вообще шли сразу gzip'нутые...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [JT] Re: propagator - diet vs glibc

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

On Mon, Feb 05, 2007 at 12:13:40AM +0200, Michael Shigorin wrote:

>>> Например, тот же интерфейс на ncurses вполне можно сделать консольным.
>> курсес красивше :)
MS> И напоминает древний mdk ;)
MS> На самом деле не уверен, что "красивше" и вообще "нужно",
MS> но не моя парафия и "работает -- не трогай"...

Я сейчас крамольную мысль скажу.

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

Синебелый интерфейс хоть и глазоломка, но к нему уже все привыкли.
Ничего лучше чем он, либо такой же но черно-белый я придумать не могу.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
ЗАКОН УИСТЛЕРА
 Никогда не знают, кто прав, но всегда известно, кто в ответе.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] propagator - diet vs glibc

[Nick S. Grechukh]

2007/2/5, Michael Shigorin <mike@osdn.org.ua>:
> On Sun, Feb 04, 2007 at 11:56:17AM +0200, Nick S. Grechukh wrote:
> > > Они примерно так:
> > > Выборочные + запакованные ~ 2.5 мега
> > > Выборочные + незапакованные ~ 9-10 мегов
> > > Все + запакованные ~ 10-11 мегов
> > > Все + незапакованные ~ 35-50-55 мегов

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

> > понятно. mar чем хорош, из него вытягивается без распаковки
>
> Я когда-то заикался, что в округе у некоторых парней модули
> вообще шли сразу gzip'нутые...

можно проверить, сколько будут весить все+запакованный gzip, учитывая
что bzip лучше жмет. или те парни и bz2 могут?