[убиться тапком] в файловый диалог gtk наконец-то добавили просмотр размера файлов

> Юникс мёртв. Это всем ясно.

Это ясно в лучшем случае тебе :)

> Юниксвей-стайл "программированием" (это когда сишные проги с текстовыми интерфейсами связанные башными соплями с тиклетекашным фронтендом)

Это юниксвей для непосвященных :D

Ну и как у sK1 с популярностью ? По инкскейпу уже сотни скринкастов с туториалами, виндузятники его юзают, коммюнити вокруг него. А sk1 отметился пока только тем что его автор привлекает национальную диаспору для выигрывания конкурсов.

>Можно ещё использовать shared mem.

Те же грабли, вид сбоку. Кто-то запорет общую память и превед. И какие проблемы с тем чтобы гонять данные через сокет? Видео и слышео вон гоняют через IP-сети и ничаво. А ты думаешь об оверхэде в условиях локалхоста.

>> Тем, что его понимают все и оно не имеет родимых пятен дбуса.
> Его не понимает никто, потому что ты его еще не придумал :D

Как бы я не я его придумал: http://vitus-wagner.livejournal.com/293683.html

>> всё необходимое для связи панельки с апплетами предоставляется уже сегодня иксовыми сокетами (и fd.o tray, в принципе)
> Если верить выводу netstat -A unix у меня на машине, D-Bus работает поверх unix-сокета, как и иксы. В чем проблема?

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

>> Если нужно что-то дополнительное, апплет волен выбрать любое нужное ему IPC.
> "Апплет волен", я плакал... И панель будет должна поддерживать все это?

Зачем панели это поддерживать? Апплету надо с кем-то общаться --- он общается. Причём тут панель?

> Я терпеть не могу D-Bus и то, что его везде суют, но то, что ты предлагаешь, просто неработоспособно.

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

>> Он кагбэ на петоне.
> О_О!!!! Разве?! А с чего я взял что он на tcl/tk? Нет народ, точно вам говорю - склероз у меня. Или маразм? Или разом?!

python/tkinter. Так что tk там есть и ты маразматик только наполовину :)

>Это ясно в лучшем случае тебе :)

в худшем случае это неясно только тебе и тиклисту.

>Это юниксвей для непосвященных :D

нет это именно тру юниксвей. Любая дивиация от текста это уже не юниксвей. Это уже 90оcтые. Корбы, комы, жабы, итп.

> Как бы я не я его придумал: http://vitus-wagner.livejournal.com/293683.html

Это неважно. Пока библиотеки его поддержки нет везде, его вообще не существует.

> "иксовый сокет" --- это не "unix-сокет для иксов".

А что это? Сокет, через который прилижение соединено с X-сервером? И ты предлагаешь панели и апплету общаться через него?

>> "Апплет волен", я плакал... И панель будет должна поддерживать все это?

>Зачем панели это поддерживать?

Потому что пока что речь шла об общении апплета и панели.

> Апплету надо с кем-то общаться --- он общается. Причём тут панель?

Если панель ни причем, то кто помешает апплету самомоу выбрать любой протокол общения? :D Хоть через X-сервер ;)

>> Я терпеть не могу D-Bus и то, что его везде суют, но то, что ты предлагаешь, просто неработоспособно.

> Это уже работает.

Причем тут трей, если речь о панели? В огороде бузина...

>> Это юниксвей для непосвященных :D
> нет это именно тру юниксвей. Любая дивиация от текста это уже не юниксвей. Это уже 90оcтые. Корбы, комы, жабы, итп.

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

>>Это ясно в лучшем случае тебе :)

>в худшем случае это неясно только тебе и тиклисту.

Согласен. Но ситуация гораздо ближе к лучшему случаю, иначе LINUX.org.ru просто не было бы :-P

> Любая дивиация от текста это уже не юниксвей. Это уже 90оcтые. Корбы, комы, жабы, итп.

Чушь, милейший. Почитай Кернигана и Плоджера (книга написана в 70-х).

>Кто-то запорет общую память и превед.

Кто-то запорет содержимое IPC месажда и превед.

ALSO Что можно запороть в картинке ?

>гоняют через IP-сети и ничаво.

Видео как бы не делает round-trip вообщето. А итнерактивщина делает. На видео заранее потрачено вычислительное время на компрессию. Отзывчивость RDP тебя устраивает ?

>> "иксовый сокет" --- это не "unix-сокет для иксов".
> А что это? Сокет, через который прилижение соединено с X-сервером? И ты предлагаешь панели и апплету общаться через него?

Да что ты передёргиваешь-то? Иксовый сокет -- как раз та хрень, которая создаётся с помощью "frame -container". И к нему файлового интерфейса нет.

>> Зачем панели это поддерживать?
> Потому что пока что речь шла об общении апплета и панели.

Кроме чисто окошечных общений (bounding box, resize) ничего не требуется. Или ты видишь что-то ещё?

>> Апплету надо с кем-то общаться --- он общается. Причём тут панель?
> Если панель ни причем, то кто помешает апплету самомоу выбрать любой протокол общения? :D Хоть через X-сервер ;)

Ну и? К слову, libICE как раз через X-сервер и передаёт.

> Причем тут трей, если речь о панели? В огороде бузина...

А чем тебе сильно растянутый трей не панель с апплетами? Там есть какое-то секретное определение, которое от меня скрыто?
Ещё пример общения чере иксовые сокеты: fvwmbuttons.

>>> "иксовый сокет" --- это не "unix-сокет для иксов".

>> А что это? Сокет, через который прилижение соединено с X-сервером? И ты предлагаешь панели и апплету общаться через него?

> Да что ты передёргиваешь-то?

Тебе не приходило в голову, что тебя трудно понять без телепатии? "Иксовый сокет", my ass.

>> Если панель ни причем, то кто помешает апплету самомоу выбрать любой протокол общения? :D Хоть через X-сервер ;)

>Ну и?

Что "ну и"? Кто помешает, почему это тебя беспокоит?

> К слову, libICE как раз через X-сервер и передаёт.

Я знаю.

> А чем тебе сильно растянутый трей не панель с апплетами?

У панели взаимодействие с пользователем сложнее.

> Такое ощущение, что разработчики Гнома чем-то обделены.

Твоей неустанной заботой о них если только

> О_О!!!! Разве?! А с чего я взял что он на tcl/tk? Нет народ, точно вам говорю - склероз у меня. Или маразм? Или разом?!

Разве. Точно. Разом.

> Тебе не приходило в голову, что тебя трудно понять без телепатии? "Иксовый сокет", my ass.

Ну я считал, что оно так и называется.

>>> Если панель ни причем, то кто помешает апплету самомоу выбрать любой протокол общения? :D Хоть через X-сервер ;)
>> Ну и?
> Что "ну и"? Кто помешает, почему это тебя беспокоит?

Это ты начал говорить "если панель не при чём"...

>> А чем тебе сильно растянутый трей не панель с апплетами?
> У панели взаимодействие с пользователем сложнее.

Чем именно сложнее?
Что панель --- набор кнопочек по которым можно тыкать, что трей.

> А sk1 отметился пока только тем что его автор привлекает национальную диаспору для выигрывания конкурсов.

sK1 отметился тем, что его юзают в предпечатке без раундтрипа с применением Scribus

>>Кто-то запорет общую память и превед.

>Кто-то запорет содержимое IPC месажда и превед.

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

>Почитай Кернигана и Плоджера (книга написана в 70-х).

Причём здесь это ? Это не дефиниция юниквея.

Если посмотреть сюда то http://en.wikipedia.org/wiki/Unix_way для выяснения обще признанного понимания понятия, то видно что

>Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, summarized the philosophy as follows:[1]

>This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Первым абзацем между прочим.

Все остальное, вроде "Rule of Modularity: Write simple parts connected by clean interfaces." не может быть свойством исключительно юниквея ни в какой мере. Ибо модульность, интерфейсы и софтваре инжениринг были изобретены не в юниксе, и он не имеет на них монополию.

Таким образом юниквей это текстовые потоки, и программы как модули.

его юзают мало. Даже в дистрибутивах ещё нету.

>сокет это локальная проблема того кто плохой датаграммой подавился.

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

> Все остальное, вроде "Rule of Modularity: Write simple parts connected by clean interfaces." не может быть свойством исключительно юниквея ни в какой мере. Ибо модульность, интерфейсы и софтваре инжениринг были изобретены не в юниксе, и он не имеет на них монополию
> Таким образом юниквей это текстовые потоки, и программы как модули.

Ты поражаешь своими способностями в логике.

>Как бы я не я его придумал: http://vitus-wagner.livejournal.com/293683.html

нехилый оверхед на парсинг умалчиваем сознательно, или бешеному тиклефилу миллион тактов не крюк? =)

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

Какой ещё сервер? Откуда он внезапно появился?

> нехилый оверхед на парсинг умалчиваем сознательно, или бешеному тиклефилу миллион тактов не крюк? =)

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

> Если посмотреть сюда то http://en.wikipedia.org/wiki/Unix_way

Это как раз для непосвященных :D

> Все остальное, вроде "Rule of Modularity: Write simple parts connected by clean interfaces." не может быть свойством исключительно юниквея

"Свойством"? Unix shell просто реализует этот принцип. На уровне 40-летней давности назад, пайпами и текстом. Но в Unix есть (и всегда был) не только shell.

> Ибо модульность, интерфейсы и софтваре инжениринг были изобретены не в юниксе, и он не имеет на них монополию.

Unix и на пайпы/текстовые интерфейсы не имеет монополии. Более того, Unix не имеет монополии на юниксвей %)

А меня поражаете вы. Потому что убери текстовые потоки, и под это описание прекрасно подойдёт винда c её сервисами, COMами компонентами и модульностью скрытыми от пользователя...

> его юзают мало

Зато по делу. Я когда открывал на фликре группу Inkscape, даже не думал, что бывает столько трэша :)

> Ты идиот, головотяп и не смыслишь ни в оптимизации, ни в простоте отладки, ни в рассмотрении типичных юз-кейзов.

ч0рт, это ж бля прекрасно ящитаю. /me тащится, тащится, тащится.

> убери текстовые потоки, и под это описание прекрасно подойдёт винда c её сервисами, COMами компонентами и модульностью скрытыми от пользователя...

Это у нас теперь "simple parts connected by clean interfaces"? Ааааа, ты стебешься %)

>Ты идиот, головотяп и не смыслишь ни в оптимизации, ни в простоте отладки, ни в рассмотрении типичных юз-кейзов. Достаточно полный ответ?

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

>Это как раз для непосвященных :D

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

>Unix и на пайпы/текстовые интерфейсы не имеет монополии.

Имеет. В винде их практически нет. Уж одним из основных интерфейсов к программам/компонентам они не являются точно. В маке в общем то тоже самое. В 10ках ресёрческих операционок - тоже самое (ну кроме плана, который именуется наследником юникса).

>Это у нас теперь "simple parts connected by clean interfaces"? Ааааа, ты стебешься %)

Идеологически это именно так. Читай книги по COМу, если не веришь. Что у них получилось это другой вопрос...

>Имеет. В винде их практически нет.

msdn://CreateNamedPipe

>Зато по делу.

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

> даже такой идиот, как я понимает, что бинарные данные, которые парсить не надо и текстовые, которые парсить надо - это две большие разницы.

Отлично, распишу по пунктам.

> В каком случае потенциальные баги,

Прочитать строку в любом высокоуровневом языке --- одна команда. Разбить строку по пробелам --- ещё одна.

Прочитать бинарный блоб, разобрать его по составляющим, обратить при надобности порядок байт, запихать это в память (а в некоторых архитектурах за неправильный alignment бюьт по почкам SIGBUS-ом), а потом взлететь --- совсем не тривиальная операция.

Про то, что бинарный поток не грепабелен, нечитаем и т.д. можешь сам прочитать у авторов, владеющих художественным словом лучше меня.

> накладные расходы на цпу и память больше - сам догадаешься, или гении выше этого? =)

А вот тут как раз сказывается отсутствие мыслей о типичных use case-ах. Покажешь мне вполне типичный по твоему мнению апплет, гоняющий гигабайты данных через IPC?

> Читай книги по COМу, если не веришь.

Слава ТНБ, я их только читал. Ощущение лютого песца осталось до сих пор.

> Что у них получилось это другой вопрос...

Это единственный важный вопрос. А получилось у них дерьмо.

Давно ли ты как пользователь соединял ворд с чем-нибудь через пайп ? В линуксе тоже есть КОМ-подобные API. Много ли ты видел софта интегрированного через них ?

> В линуксе тоже есть КОМ-подобные API. Много ли ты видел софта интегрированного через них ?

Бгг, нашёл у кого спросить. Этот софт является его жизненной силой :о)

>>сокет это локальная проблема того кто плохой датаграммой подавился.

>в данном случае, плохой датаграммой давится сервер, и поэтому это тоже общая проблема.

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

>Это единственный важный вопрос.

Это единственный вопрос в оценке инженерных подходов. Но не в оценке идеологических подходов. Ибо идеология может быть реализована по разному. К примеру реализация идеологии, которая говорит что судебную законодательную и исполнительные власти нужно разделять - в западных странах, и в россии реализована с разными результатами.

> Если подавился - это серьезный баг конкретно сервера. При разделяемой памяти он может рухнуть и из-за бага клиента.

Причём ещё хорошо, если ошибка проявляется явно, а не является "наведённой".

>> Unix и на пайпы/текстовые интерфейсы не имеет монополии.

> Имеет. В винде их практически нет.

Что значит "практически нет" - то есть они всё таки есть? :D

> Уж одним из основных интерфейсов к программам/компонентам они не являются точно.

Они и в Unix не являются таковыми. Текст и пайпы - это shell, и всё (shell давно не является основным средством программирования). К библиотекам доступ через Си API.

Unix shell и пайпы - это просто первая, самая известная реализация юниксвея :)

> 10ках ресёрческих операционок - тоже самое (ну кроме плана, который именуется наследником юникса).

IIRC, в Plan9 самое главное - это 9P, протокол (не текст поверх пайпа) доступа к файловым ресурсам.

>При разделяемой памяти он может рухнуть и из-за бага клиента.

C какой стати то ? Блок можно отпускать по таймеру.

>Прочитать строку в любом высокоуровневом языке --- одна команда. Разбить строку по пробелам --- ещё одна.

лол, в _высокоуровневых_ языках есть и регекспы, которые сразу разобьют строку и вернут список переменных правильных типов.

ты посчитай нагрузку на цпу, ага.


>Прочитать бинарный блоб, разобрать его по составляющим, обратить при надобности порядок байт, запихать это в память (а в некоторых архитектурах за неправильный alignment бюьт по почкам SIGBUS-ом), а потом взлететь --- совсем не тривиальная операция.

все это гораздо быстрее, чем распарсить строку и уже сделано в либе d-bus

про порядок байт - это ты бугага написал, в локальной шине такого нет, а по сети - напиши код, который твой текстовый уникод переставлять байты в правильный порядок. И удавись

за перл про выравнивание данных в IPC тебе отдельное спасибо. Поржал.

>Про то, что бинарный поток не грепабелен, нечитаем

нахрена его грепать и читать? Ты tcp-пакеты грепаешь и читаешь?

>А вот тут как раз сказывается отсутствие мыслей о типичных use case-ах. Покажешь мне вполне типичный по твоему мнению апплет, гоняющий гигабайты данных через IPC?

апплет тут совершенно ни причем. d-bus - шина _универсальная_. Если ты хочешь отдельный велосипед для апплетов - то лучше сразу убейся, это говно, когда в системе дефакто десятки несовместимых между собой IPC мы уже проходили.

>> Это единственный важный вопрос.

> Это единственный вопрос в оценке инженерных подходов.

В оценке результатов.

> Но не в оценке идеологических подходов. Ибо идеология может быть реализована по разному.

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

>Давно ли ты как пользователь соединял ворд с чем-нибудь через пайп ? В линуксе тоже есть КОМ-подобные API. Много ли ты видел софта интегрированного через них ?

причем здесь ворд? пайпы в венде, если чо - активно используются для связи между сервисами/драйверами/по

так что слова про "практически не используются" можешь забирать обратно

COM-like используется в гноме, фф, опенофисе, гномофисе. Ы?

> Unix shell и пайпы - это просто первая, самая известная реализация юниксвея :)

Зато она имеет самую надёжную изоляцию.
Собственно, именно поэтому в среде опенсорса, который пишется в общем случае абы кем и абы как, только её и можно рассматривать как интерфейс для расширений. В особенности, для "десктопных" gui-приложений.

>Собственно, именно поэтому в среде опенсорса, который пишется в общем случае абы кем и абы как, только её и можно рассматривать как интерфейс для расширений. В особенности, для "десктопных" gui-приложений.

лол

> Наличие незаменимых фич - это вообще не показатель качества.

Наличие мозга в голове --- не показатель интеллекта.

>Давно ли ты как пользователь соединял ворд с чем-нибудь через пайп ?

Если Word истанциировать из vbs скрипта как out-of-proc COM сервер, то OLE-Automation вызовы будут маршаллизироваться через именованные каналы.