Мобильный Linux: по ком звонит сотовый?

[longshadow]

По поводу линукс-гаджетов я понял: "Главное, чтобы костюмчик сидел" (с) - Чтобы была возможность сменить оригинальную прошивку. И существовала в природе совместимая с имеющимся железом альтернативная прошивка, которая поддерживает непредусмотренные производителем возможности. И если аппарат реально интересный, то со временем альтернатива для него появится.

Даже не так. Главное, чтобы архитектура была открытой. при этом, там изначально может быть и не Линукс. На открытую платформу без "темных закоулков" Линукс портируют быстро. И альтернативную прошивку сделают. Примеры со старыми (времен существования фирмы Компакв) Ипаками и "новыми" Заврами - тому подтверждение.

[ВадимП]

всё что можно, делать через pipeline, но НЕ через dll

А что, в Unix'е есть dll?

[longshadow]

всё что можно, делать через pipeline, но НЕ через dll

pipeline и dll суть разные приемы.

Концепция pipeline предполагает, что вместо того, чтобы включать в каждую программу поддержку максимального функционала (в ущерб надежности и размеру), следует создавать много узкофункциональных программ, способных обмениваться данными через потоки.

Концепция dll (в широком смысле) направлена на то, чтобы облегчить модернизацию модулей API, используемых несколькими программами и сократить их (программ) размер.

Поэтому формулировка "но НЕ через" не канает. Это все равно, что сказать: "у меня нет молотка, поэтому гвозди я забиваю ручкой отвертки". Кроме того, и "отвертки" и "молотки" в Юниксе есть. В достатке. Там вот с "барабанными палочками" послабее.

А что, в Unix'е есть dll?

Были, есть и будут есть . В буквальном смысле - во времена формата aout. В концептуальном - есть и ныне: elf-овские shared objects. Наверное, остались еще какие-то проприетарные Unix-favors, где нет поддержки динамической загрузки библиотек, но на вскидку таких не вспомню. Вот может пресловутый СКО?

[ViV]

А что, в Unix'е есть dll?

wine позволяет их использовать

[ВадимП]

А что, в Unix'е есть dll?

Были, есть и будут есть . В буквальном смысле - во времена формата aout.

Про .so я как-то и сам знаю. А вот не напомните ли мне, когда это "во времена a.out" были dll "в буквальном смысле"?

[longshadow]

Про .so я как-то и сам знаю. А вот не напомните ли мне, когда это "во времена a.out" были dll "в буквальном смысле"?

Первый дистрибутив Линукса, с которым я работал (Yggdrassil 2.x) в 95-м году (ядро 1.2.13! libc-5.4.x! супа! ) имел две среды линкования/выполнения: для elf-бинарников и для aout-бинарников. Первая - основная (эльф тогда уже считался "победившим" ) - в конвенциальных директориях /lib, /usr/lib, вторая - как "кросс-среда" в /usr/i386-linux-aout/. Так вот, вторая содержала динамические библиотеки .dll. Разумеется, это не тот же самый .dll, что используется в форточках - я этого и не утверждал. Автор исходной посылки тоже явно имел в виду не формат/интерфейс виндовых .dll, как таковой, а концепцию. Под "буквальностью" понималась, в данном случае, всего лишь схема именования файлов.

[const_mech]

Автор исходной посылки тоже явно имел в виду не формат/интерфейс виндовых .dll, как таковой, а концепцию

Да, именно так, "dll" это чтобы противопоставить: unix-way VS windows-way.

А в оригинале участники дискуссии употребляли термин "библиотеки":
http://blacklion.livejournal.com/170940 ... 12#t730812

2) теперь собственно о DE.
Что KDE, что GNOME (последний в меньшей степени) поразил один и тот-же червь -- бесконечные библиотечки. и если в GNOME ещё можно разобрать что, где и для чего прикручено, то в KDE это монолитное нечто под названием kdelibs.
с одной стороны можно воскликнуть -- как же, ведь идея *nix и состоит в том чтобы разделять задачи по маленким утилитам. и я скажу -- верно! Законченным утилитам. маленьким кубикам которые сегодня можно использовать для постройки шалаша, которые можно легко разобрать и перенести на понравившееся место, а завтра -- прекрасной крепости которая выдержит натиск войск врагов. библиотеки такими кубиками называть нельзя. по одной причине - они подчас слишком сложны чтобы быть Простым Кубиком и их невозможно разделить на части, поскольку неизвестно что решит создать программист на их основе, какую часть из возможностей он решит использовать. библиотеки - монолитны. и в этом их слабость

еще раз: библиотеки это плохо. Это убийство sh

+++++++++++++++++++++++++

Вопрос (на правах ликбеза): Приложения X-window (или Кутопии) могут встраиваться в цепочки? То есть, могут прочитать при открытии информацию со стандартного входа, а при закрытии, передать результат работы пользователя в этом приложении на стандартный выход (и далее по цепочке)?

[longshadow]

Да, именно так, "dll" это чтобы противопоставить: unix-way VS windows-way.

Ну вот. Только противопоставлять здесь нечего. Динамические библиотеки в Унихе есть и это правильно. А иначе пришлось бы каждый раз, при выходе очередного патча для libc, собирать систему from scratch - ужжжас.

...

Аффтар прав лишь частично, как и любой ортодокс. Правота его в том, что (возможно, лишь возможно) архитектура KDE и Gtk не была изначально разработана с учетом такого огромного количества функций, что и привело к чрезмерному укрупнению либов.

еще раз: библиотеки это плохо. Это убийство sh

А "противопоставление библиотек шеллу" - это вообще что-то из серии "скрещивания ужа с ежом".

Вопрос (на правах ликбеза): Приложения X-window (или Кутопии) могут встраиваться в цепочки? То есть, могут прочитать при открытии информацию со стандартного входа, а при закрытии, передать результат работы пользователя в этом приложении на стандартный выход (и далее по цепочке)?

Разумеется.

[ВадимП]

Я помню дистрибутив Yggdrasil производства одноименной компании (черт ее знает, что с ней потом сталось) и готов поклясться, что там никогда не было никаких файлов с суффиксом dll. Да и не должно было быть - gcc был одним и тем же на всех дистрибутивах.

[longshadow]

готов поклясться, что там никогда не было никаких файлов с суффиксом dll.

К счастью, сей дистрибутив у меня оказался под рукой (храню, как раритет). Непосредственно "файлов с суффиксом .dll" на диске нет. Но есть упомянутая мной "кросс-директория" в скелете фаловой системы и пакет dlltools, с соответствующим описанием.

Код: Выделить всё

[root@penguin-hole backuper]# find /mnt/cdrom/ -name \*dll\*
/mnt/cdrom/usr/dll
/mnt/cdrom/usr/i486-linuxaout/dll
/mnt/cdrom/usr/lib/xemacs-19.12/lisp/pcl-cvs/dll-debug.el
/mnt/cdrom/usr/lib/xemacs-19.12/lisp/pcl-cvs/dll.el
/mnt/cdrom/usr/lib/xemacs-19.12/lisp/pcl-cvs/dll.elc
/mnt/cdrom/usr/lib/yggdrasil/components/dlltools.xbm
/mnt/cdrom/usr/lib/yggdrasil/components/dlltools.include
/mnt/cdrom/usr/lib/yggdrasil/components/dlltools.description
/mnt/cdrom/usr/lib/yggdrasil/components/dlltools.size
/mnt/cdrom/usr/lib/yggdrasil/components/dlltools.bytes
/mnt/cdrom/usr/packages/postgres/include/lib/dllist.h
[root@penguin-hole backuper]# cat /mnt/cdrom/usr/lib/yggdrasil/components/dlltools.description
Tools to build old-style (a.out) shared libraries.

gcc был одним и тем же на всех дистрибутивах.

Это весьма спорное утверждение. Я навскидку могу вспомнить прецеденты, когда дистрибутивы включали минимум две версии компилятора для одной и той же архитектуры (кросссредства в расчет не берем).

[ВадимП]

gcc был одним и тем же на всех дистрибутивах.

Это весьма спорное утверждение. Я навскидку могу вспомнить прецеденты, когда дистрибутивы включали минимум две версии компилятора для одной и той же архитектуры (кросссредства в расчет не берем).

Было такое. В момент перехода от от одной версии к другой. В redhat'е, например, в своё время наряду с их фирменным gcc 2.96 был еще gcc 3.0 под именем gcc3.
Только шла речь не об этом...

[longshadow]

Только шла речь не об этом...

Не об этом. Это был ответ на конкретное утверждение:

gcc был одним и тем же на всех дистрибутивах.

приведенное в доказательство тезиса "не могло быть" файлов с суффиксом .dll.

В частности, в обсуждаемом дистрибутиве было два gcc: один для elf, второй для aout. Одной и той же версии, но собранные с разными опциями и лайоутами.

Что же касавется волнительного вопроса о наличии "файлов с суффиксом .dll", постараюсь на досуге развернуть дистрибутив и посмотреть, что генерилось dlltools'ами.

[Alex_The_Cleaner]

To Viv - число команд меньше, но суть та же... А вот UNIX WAY это фактически подтягивание пользователя (которому это нафиг не надо), до уровня Power User... (IMHO)
To longshadow - Я понимаю что такой кофеварки еще нет (а жаль;)), но что-то подобное хотелось бы? А Рапсодия это случайно не отечественный прибор под кодовым названием "НАШ ОТВЕТ их IP телефонии"?. Если мы говорим об одном приборе, то вобщем прибор то ублюдочный... А уж цена...

[ViV]

А вот UNIX WAY это фактически подтягивание пользователя (которому это нафиг не надо), до уровня Power User...

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

[Alex_The_Cleaner]

Меня пугает то, что при UNIX WAY требуется некий "цемент" для кирпичей... И вот этот цемент (как правило) - скрипт. А к скриптам я со времен bat файлов отношусь настороженно... Вкратце - цемент в кирпичном доме может быть хренового качества... %) И в кирпичном доме это намного более заметно чем в панельном...