Linux избавляет от необходимости щелкать мышью

2Led: ну ты-то на какую часть среагировал? А Игорь? И сравни с реакцией рута...:) Вообщем-то этого и добивался - отсеять дураков...:)

2Irsi: Угу, а потом user сархивирует файл утилитой, не ведующей о
потоках и отрежет тебе все, что ниже пояса.
Nail

2Irsi:
>директорию как многопоточный файл рассматривать неудобно
Извини, но... неубедительно :)
>К тому же это требует больше ресурсов
Из чего сие следует?
Даже если допустить потребность в многопоточных файлах для
определенных задач (пока не представляю, где без них нельзя было бы
легко обойтись), можно быстренько соорудить сервис-надстройку над
ext2fs, который бы предоставлял директории с определенным атрибутом
как многопоточные файлы - задачка для студента, и то, что такого нет,
говорит лишь о том, что он не нужен :)

2AC: ну так что же ты молчишь про специализированные ОС. Только тебя обломили - так сразу у кусты прячешься?

Вот во время 1-й мировой такие как Ирси и ходили в войска и говорили деструктивные вещи - у вас там коровы дома не доены, жена ... извините неудовлетворенная, а вы тут в окопах вшей кормите. И тут же конструктивная - а давайте воевать перестанем, да домой пойдем!
Чувствуете насколько все похоже? Потом они коммисарами становились, потому что 3.14еть умели хорошо. А потом их Сталин перестрелял...
Вот за это, Led, у НАС в России их не любят.
Это у Ирси в крови. Исправить не удасться. R00T - охолонь трошки.
Офтопик блин.

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

Игорь.

Irsi:Давай ломись в окопы пропогандируй Порутчику что у него MustDie
непричесанный.
Порутчик:У тебя небось жена недоена и коровы неудовлетворены?
Тьфу..все перепутал.
P.S. Интересно это как же можно администрировать после 4-х литров пива?
Ты по клаве то попадаешь?
Boss небось тоже бухает?
Ну и приколы в России кому раскажешь не поверит ведь.

2Led: ну зачем делать такую надстройку? Когда проще добавить возможность ссылаться записи в каталоге не на одну i-node, а на несколько?
Что это дает? При открытии многопоточного файла мы сразу имеем информацию о том где находятся его потоки. При открытии спецкаталога - нет, чтоб получить доступ к каждому из потоков надо сначала произвести поиск, потом открыть еще один файл... Прошу заметить к слову что таблица дескрипторов файлов не резиновая...
Вообщем MacOS предлагаемым тобой способом эмулировала resource fork на однопоточных FS, например fat. Как результат скорость работы патала в геометрической прогресии в зависимости от числа файлов.

2Irsi:
>При открытии многопоточного файла мы сразу имеем информацию о том
>где находятся его потоки
При открытии каталога мы сразу имеем информацию о том где находятся
его "потоки" - в ЭТОМ каталоге, т.е. в нем же :)
>Прошу заметить к слову что таблица дескрипторов файлов не резиновая
Ну и?
>Как результат скорость работы патала в геометрической прогресии в
>зависимости от числа файлов
Из-за чего? Хотя бы приблизительную причину можешь назвать: почему
падает производительность? В UMSDOS тоже падает производительность,
но явно не из-за эмуляции многопоточности, хотя UMSDOS тоже
сервис-надстройка над FAT. А число файлов значительно не возрастет,
потому как многопоточность (я уже говорил) нужна очень немногим
приложениям (IMHO)...
В каталоге же можно разные "потоки" получать с разных носителей (или
по NFS) и каждому "потоку" присвоить разные права доступа (например,
два ключа к закодированному файлу - открытый и закрытый) - и все это
без дополнительных затрат и необходимости вносить изменения в
стандарты и стандартные библиотеки, переносимость - полная,
сложность - на уровне студенческой курсовой работы (да-да, опять
они, "красноглазые"), делается один раз и работает потом на любой
"настоящей" FS, опять же, специальных программ для backup придумывать
не нужно - все уже давно придумано давно (tar, cpio).

2Led: еще раз - при открытии файла с n потоками, в обычной fs создается n дескрипторов, в многопоточной - один.
При этом твою схему нельзя использовать к примеру для реализации ACL.
На счет "немногим приложением нужна" - не согласен. На самом деле для многих приложений она бы была очень полезна. Полезна - в смыле сократила бы число строк кода и/или ускорила работу. Про то что многие вещи стали бы более эээ... "прозрачны" чтоль, а следовательно уменьшилось число ошибок я и не говорю.
Вообще весь этот спор напоминает мне один мой спор с RSX-гуру. Только я ему пытался доказать преимущества древовидной структуры каталогов пере плоской FS. Его аргументы были практически точно такие же как и твои...:)

To anonymous:
>ну так что же ты молчишь про специализированные ОС. Только тебя обломили - так сразу у кусты прячешься?

Nu i kto eto menya oblomil? Chisto, esli ne sekret?
Pogovorili, vopros ischerpan. Razumnuu kontr-dovodi ya videl tol'ko v odnom sluchae -- kogda kto-to mne napisal pro multimedia i number crunching. Tut nado podumat', mozhet li sushestvovat' takoe razdelenie na podsistemi, pri kotorom sootvetstvuushie services ne budut drug drugu meshat'. Dumau, chto v principe da, mozhet.
Krome togo, vvyazivat'sya v _ser'eznie_ spori s anonymousami, kotorie -- to oni est', a to ih net -- nikakogo rezona ya dlya sebya ne vizhu.

P.S.: I voobsche, ya tak ponyal, chto tema ischerpalas' azh v voskresen'e. A seichas zdes' voobsche obshuzhdautsya voprosi mezhnacional'nih otnoshenii...:(

2Irsi:
>еще раз - при открытии файла с n потоками, в обычной fs создается n
>дескрипторов, в многопоточной - один
Какая ПРИНЦИПИАЛЬНАЯ разница - дескрипторы потоков или дикрипторы
файлов? Файлы также имеют свойство не только открываться, но и
закрываться :), открыто только то, что нужно - иконка/тег/цвет/etc
открылось-прочиталось-закрылось.
>При этом твою схему нельзя использовать к примеру для реализации ACL.
Почему нельзя? В каталоге создается файл с необходимой информацией,
доступ к которому имеет только сервис/демон (ну еще и root :))...
>На самом деле для многих приложений она бы была очень полезна
"Полезна" и "необходима" - не одно и тоже. SCSI-диски тоже очень
полезны, только вот накладно выходит и в большинстве случаев не
оправдывает затрат...
>Только я ему пытался доказать преимущества древовидной структуры
>каталогов пере плоской FS
Так она и есть плоская :) Просто один из "сервисов" считает некоторые
файлы "особенными", т.е. списком других файлов...
Честно говоря, что-то неинтересно стало с тобой спорить: аргументы
твои однотипные - "плохо, потому что плохо", "будет работать медленно,
потому что будет меденно работать", "станет все прозрачным" (так ведь
куда уж прозрачней!), "будет меньше ошибок", "будет меньше строк" -
я ж не против многопоточности (нужно тебе - используй), я просто
говорю, что реализовать ее как надстройку не составит труда (в
Linux'е это заложено - см. VFS), вот только почему до сих пор никто
не реализовал - может я самый умный :)))

2Led: на открытие-закрытие требуются ресурсы, разве не ясно?
">При этом твою схему нельзя использовать к примеру для реализации ACL.
Почему нельзя? В каталоге создается файл с необходимой информацией,
доступ к которому имеет только сервис/демон (ну еще и root :))... "
Скопировали файл в другой каталог, файл с ACL скопировать забыли. Здорово да?. Или демон будет отслеживать все копирования? А это опять - ресурсы.
К слову - тебе нравится работать с документом, состоящим из нескольких десятков файлов? Мне лично нет - то один файл потеряещь, то другой. Еслиб все это хранилось в потоках гимору было бы на порядок меньше.
В линуксе это настройку реализовать можно, как я уже сказал это несложно - все сводится к небольшой модификации формата записи в каталоге.
Опять же - эта модификация не обязывает тебя использовать эту возможность, так же как и наличае древовидной структуры не обязывает тебя тебя ее использовать - хочешь вали все в / или ~home, твои проблемы. Но ее наличае, так же как и наличае древовидной структуры каталогов, существенно повышает гибкость системы.

> Tut nado podumat', mozhet li sushestvovat' 
> takoe razdelenie na podsistemi,
> pri kotorom sootvetstvuushie services
> ne budut drug drugu meshat'. Dumau, chto
> v principe da, mozhet. 

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

2Irsi:
>на открытие-закрытие требуются ресурсы, разве не ясно?
На открытие-закрытие потоков ресурсы не требуются? Только не надо
говорить, что для файлов нужно "МНОГО" ресурсов, а для потоков - "мало"
>Или демон будет отслеживать все копирования?
Нет конечно, так же как и VC в NT не отслеживает... Но демон может
предоставить для этого API, которое ты можешь использовать для
НОВОГО МНОГОПОТОЧНОГО ACL-ного файлового менеджера, а пока ты его
разработаешь, я могу копировать "многопоточные" файлы стандаратным
cp или потратить 5 минут на "разработку" скрипта из 2 строк для того,
чтобы "не забывать копировать файлы с ACL"
>тебе нравится работать с документом, состоящим из нескольких
>десятков файлов?
Так я с ним работатать не буду - с ним будет работать твое
"многопоточное приложение", а мне посрать, что ему нравится, а что не
нравится (не потому, что оно "твое" :))
>то один файл потеряещь, то другой
см. выше :) Зато если их потеряет кто-то другой, востановить руками
(без diskeditora) - пара пустяков (чем проще, тем надежнее, а оно
действительно проще, т.к. не вводятся новые понятия - "потоки")
>В линуксе это настройку реализовать можно, как я уже сказал это
>несложно - все сводится к небольшой модификации формата записи в
>каталоге
В линуксе это реализуется БЕЗ модификации формата записи (я уже сказал
как) причем ОДИН РАЗ для ЛЮБЫХ FS, которые есть и которые будут!
>Опять же - эта модификация не обязывает тебя использовать эту возможность
Ясный перец - не обязывает! Хочешь используй, хочешь - нет :).
А на счет различных прав доступа для разных потоков? Или это "не
актуально"? :))

2Led: так, на тему принципиальной разницы - у тебя исходники ядра под рукой? Кинь форматы записи в каталоге и дескриптора файла и я тебе наглядно продемострирую эту разницу. :)
Различные права для разных потоков это не просто не актуально - это не нужно! Есть четкая аналогия между и файлом и фаловыми потоками и процессом и тредами соответственно.

2Irsi:
>Кинь форматы записи в каталоге и дескриптора файла и я тебе наглядно
>продемострирую эту разницу
Не понял - что и куда кинуть? И для какой именно FS?
>Различные права для разных потоков это не просто не актуально - это не нужно
Ааа, убедил! Несколько потоков для файлов тоже не нужно (мне). Я тебя
убедил? :) Потоки - продолжение древовидной структуры FS, только
называем мы это уже "ветки и листья", а "сучки и листочки", и
приделывем их не как обычно, а сбоку и гвоздиками (чтоб прочнее и
"меньше ресурсов" использовать) - я тебя правильно понял?
>Есть четкая аналогия между и файлом и фаловыми потоками и процессом
>и тредами соответственно
Нет четкой аналогии: треды - одна из разновидностей fork() (с общими
данными) - см. реализации clone(). Что же общего у потоков - имя
файла? Ну так и оставь его общим - я другого и не предлагаю...
А как тебе такая фишка: на сервере большой текст (просто текст) только
для чтения, а пользователи могут подмонтировать его по NFS в свой
"многопотоковый файл" и форматировать тем, что у них есть (или чем
нравится) - хоть в html, хоть в pdf, хоть в doc, хоть в одно и тоже,
но по разному? То, как я предлагаю (наверное, далеко не первый) -
реализуется не просто, а очень просто. С потоками - сложнее: все
придется хранить на сервере (значит должно быть право записи), а
значит - все общедоступно и в один прекрасный день я могу не
обнаружить "свой" вариант документа :(

2Led: не только имя файла - также права доступа и дескриптор у них тоже общий.
Кидай прям сюда описание из хедеров на С - там не так много текста имхо...:) Личше всего ext2fs - она достаточно примитивна и детали отвлекать не будут...:) Если лень - могу немного попозже продемонстрировать тоже самое, но на примере UFS...

2Irsi:
>не только имя файла - также права доступа и дескриптор у них тоже общий
ОК хочешь общие права - поставь общие (а можно и разные, можно даже
разных владельце поставить - а почему бы и нет? мне нравится :)) я
уже писАл для чего может понадобится)
А дескриптор у них не общий, а один - тут может возникнуть проблема
на совместное одновременное использование файла. В моем случае (при
соответствующей поддержке прикладного ПО) - один документ из
нескольких разделов, у каждого раздела - свой владелец (автор), все
авторы могут одновременно редактировать ОДИН документ (только
каждый - свой раздел) и при этом в динамике видеть в ОДНОМ окне своего
приложения ВЕСЬ документ. Итак, как енто реализовать с твоими
"стандартными" потоками?

2Led: а ты осознаешь что потоки тоже не панацея? Это удобный инструмент для определенного круга задачь, не более того.
Немного отвлекусь от темы... Вообще само понятие FS - отрыжка тех времен, когда железные ресурсы были в дефеците. Сам подумай - по большому счету ОЗУ является всего лищь еще одним уровнем кеша на пути данных из хранилища (диска) к обработчику (процессору). Т.е. в идеале есть некий объект (документ и т.д.), который обрабатывается неким обработчиком (программой). Где находится этот объект - на диске, в ОЗУ и т.д. никого не должно волновать. Т.е. сами пункты меню File Open & File Save - мастдай, их не должно быть! Я каким-то образом начал обработку документа, потом ее прекратил. Все, никаких других действий придпринимать я не должен, заботится о его "сохранении" - тоже... Бред? Ну посмотри на архитектуру AS/400 для примера...:)

2Irsi:
>а ты осознаешь что потоки тоже не панацея? Это удобный инструмент
>для определенного круга задачь, не более того.
То, что я предлагаю, тоже не панацея, но оно включает потоки, как
подмножество, и тебе будет оччень сложно доказать, что при этом
будет расходоваться больше ресурсов.
Я всего лишь предлагаю вариант реализации потоков, которые тебе так
нравятся, не изобретая при этом велосипед, не внося изменения в
стандарты, ядро и библиотеки (ты ж сам кричал, что сервисы в
userspace - это круто) и при этом не ковыряясь в различных FS...
>Где находится этот объект - на диске, в ОЗУ и т.д. никого не должно
>волновать. Т.е. сами пункты меню File Open & File Save - мастдай, их
>не должно быть! Я каким-то образом начал обработку документа, потом
>ее прекратил
Ну а я о чем? Пользователю - по%уй, программисту - по%уй (api -
интерфейс как ТЕБЕ нравится), в закрытой системе (не OpenSource) -
вобще не должно волновать оно реализовано... О чем спор-то?!

2Led: уффф... ну точно как тот RSX-гуру, отрицающий полезность и необходимость древовидной структуры каталогов...:) ладно, я понял что копаться в исходниках ядра, чтоб извлечь оттуда пару структур данных тебе лень... Ну чтож - я это сделаю... точнее дойду до дому, возъму книжку по какому-нибуть юниксу и возьму их оттуда... Это будет не линукс разумеется, но что-то аналогичное ext2fs... И продемонстрирую тебе как говориться "на пальцах"...

2Led: добавочка - я на выходные отдыхать уматываю, так что это не сразу наверно будет, может завтра, а может и в понедельник-вторник. Напомни если что...:)
На счет user level servecis - да, это хорошо, нужно и полезно. На микроядерной архитектуре. На ядре линукса тормозить будет.

не... все-тки дырочки в перфокартах нада ЗУБАМИ делать :))

Led, Irsi а что само приложение не может один поток из файла разбить на несколько по содержанию или по алгоритму ? Ведь системе я понял это сильно не надо а приложения сами могут разобраться. А ?

Игорь.

2Игорь: может... получаем что-то типа формата исполняемых файлов в виндах. Оно тебе надо? Имхо - криво. Хотя к слову пришло в винды из юниксов - формат испольняего файла в виндах это расширенный вариант COFF.
К тому же одно из применений потоков - ACL, становится невозможной.
Да, вопрос - реализация ACL и гуя это чья задача? Системы и прикладной программы?
2Led: к слову - ты меня запутал, а я протормозил...:) Насколько я помню атрибуты файла храняться всеже в i-node, а не записи каталога, так что извиняйте - может поток иметь свои собственные атрибуты...

>Led, Irsi а что само приложение не может один поток из файла разбить >на несколько по содержанию или по алгоритму ? Ведь системе я понял >это сильно не надо а приложения сами могут разобраться. А ?

Skoree vsego, net, ne mozhet. Potomu chto v takom sluchae _kazhdii_ file potencial'no dolzhen imet' _v_sebe_ nekii header, chtobi pozvolit' prilozheniu razobrat'sya v ego potokah. Esli rech' idet o special'nih formatah (application-specific), to da, tak ono i est' -- sm. structured storage, etc.
No preimuschestvo mnogopotochnoi FS imenno v tom, informaziya structurirovana imenno dlya _vseh_ files, a application, obrabativaushee files, mozhet i ne znat', v kakoi ono FS zhivet.

2Irsi:
>ты меня запутал, а я протормозил...:) Насколько я помню атрибуты
>файла храняться всеже в i-node, а не записи каталога, так что
>извиняйте - может поток иметь свои собственные атрибуты...
Я не путал, а спросил: может или нет, ты сказал, что нет и это не
нужно... Если может - скажи как в NT ты присвоишь разные аттрибуты
разным потокам одного файла, поставишь им разных владельцев? Это не
наезд, я действительно хочу знать...
>формат испольняего файла в виндах это расширенный вариант COFF
Да гибридный там какой-то формат: кусок от MZ точно есть...

2Led: стоп, в NT дело совсем особое:
1. Там-то "досовские" или "старые" атрибуты файла, храняться именно в записи каталога. Вообщем-то они никакой роли не играют и оставлены для совместимости со старыми приложениями.
2. Система безопасности NT основанна на ACL, необходимые данные для которой храняться именно в отдельном потоке. Структура этих данных не предусматривает задания различных прав для потоков одного и того же файла.
Так что:
1. Если не используется ACL, базирующаяся на хранение своих данных потоках, то "классические" юниксовы права возможно будет задавать для каждого потока в отдельности.
2. Если ACL использует, то все зависит от ее реализации. Хочешь - реализуй возможность задавать права для каждого потока, не хочешь - не реализуй.

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

2Irsi:
>Там-то "досовские" или "старые" атрибуты файла, храняться именно в
>записи каталога. Вообщем-то они никакой роли не играют и оставлены
>для совместимости со старыми приложениями.
Я не об этом: скажи каким стандартным (или не стандаотным)
файлменеджером/утилитой можно назначить арибуты/владельца/группу
каждому потоку?
>Структура этих данных не предусматривает задания различных прав для
>потоков одного и того же файла
А жаль... Было бы неплохо...
Кстати, об ACL: использование ACL предусмотрено в ext2 - см.
/usr/src/linux/include/fs*.h (по крайней мере в 2.4.5 есть)...
>MZ там только небольшой кусок
Да знаем, ковырялись (в свое время) :)

2Led: ну возникает идея адресовать потоки например таким образом chmod 666 /usr/home/irsi/test.txt:2, где 2 это номер потока... Ну вместо : может стоит использовать другой разделитель... подумать надо...:)

Irsi:
>ну возникает идея адресовать потоки например таким образом chmod
>666 /usr/home/irsi/test.txt:2, где 2 это номер потока...
Ты или не правильно понял меня (или сделал вид, что не понял)...
Повторяю: как стандартными средствами реализуется присвоение атрибутов
и владельца каждому потоку в OS и FS, где эти потоки реализованы,
в частности в NT/NTFS и BeOS/BFS?

2Led: да, не понял, извини.
Как я уже сказал в NT/2K их реализация такова что сделать это невозможно.
В BeOS я честно сказать даже не разбирался, ибо это система однопользовательсткая. Т.е. вроде все структуры данных, необходимые для поддержки стандартных юниксовых атрибутов имеются, их даже можно менять, но это ни на что не влияет.
В QNX6 я тоже если честно с этим не разбирался. Имхо - нечто аналогичное описанному мною выше, но не пробовал. Ну не возникало у меня ранее идеи попробовать сделать нечто подобное ибо имхо настолько экзотична та ситуация, когда это может реально потребоваться...

P.S. Блин, и без того современные "продвинутые" ACL эээ... весьма сложны и непрозрачны имхо, по сравнению со стандартной юниксовой системой прав...

2Irsi:
Ты сам ответил на все свои вопросы: возможность многопоточности
зарезервирована (на всякий случай), но практической пользы от нее -
никакой, по крайней мере она не позволяет сделать чего нибудь такого,
чего нельзя было бы реализовать (без напряга) другими средствами,
потому все и стараются реализовывать свои проекты именно этими
"другими средствами" дабы не усложнять систему и не вносить в нее
новые понятия, т.е. не снижать надежность...
>Блин, и без того современные "продвинутые" ACL эээ... весьма сложны
>и непрозрачны имхо, по сравнению со стандартной юниксовой системой
>прав...
Еще раз повторяю - ACL заложены в ext2: кому надо - используйте...

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

Если какие-то "придурки слезли с мастдая", то откуда слезают такие придурки как ты, мне понятно - явно с дерева. Посмотрю я на тебя, как ты в Gimpe будешь клавой рисовать :-)))

И кстати ничего лучше Фотошопа для растровой графики пока не придумано, все серьезные дизайнеры (которые зарабатывают) работают там.

GIMP ваш сраный мне на хер не нужен. А вообще лучше всего рисовать на бумаге. Кисточкой. Тут никакой гимп с фотожопом не годятся.

2Irsi:
OK, приведи примеры обратного - где использование многопоточности
увеличивало надежность
KDE, GNOME, Nautilus - всего лишь надстройки - из-за какой-то
надстройки (которая нужна далеко не всем) вносить серьезные
изменения в файловую систему и API - по-моему это глупо...

2Led: ты уже сам привел эти примеры...:) Вообщем они будут очень полезны для небольших БД типа постгреса и mysql, для крупных конечно RAW девайс все равно нужен будет... Я также описывал как их можно использовать в текстовых процессорах, хранение полей From, To, Cc, Subj в отдельном потоке для почтовых програм тоже сильно упрощает поиск и очень сильно увеличивает его скорость даже без применения специального индексного файла. Понятно что отсутствие этго файла упрощает систему и следовательно - повышает надежность... Электронные таблицы - так же как и для БД полезно, посколько они есть частный и специфический случай БД... Ньюсы - то же что и почта... Что еще? Назови практически любую область и я приведу примеры каким образом для нее окажутся полезны потоки...
А как я уже говорил изменения в файлувую систему вносятся гораздо более простые, чем например при добавлении журнала...

2Irsi: Опять не правильно понял :) Я имел в виду реальные примеры, а не "область предположительного применения"...

2Led: аааа! see BeOS & QNX6, особенно BeOS. По крайней мере родной почтовыи и родной редактор там активно используют потоки... да и вообще - покопайся в ней, удивишся как много там именно на многопоточность завязано...

2Irsi: Да как-то в трупах копатся неохота ;) (BeOS имеется в виду - недоделанная система нежизнеспособна). А QNX - слишком специализированна, в не только потоки, а и еще много чего экзотического можно увидеть... Да и как там помотришь - код ведь закрыт (разве что дебаггером :))

2Led: ну BeOS не труп, правда жива она в несколько иной реинкарнации - BeIA...
Кстати - чем недоделана? Софта мало? Так это не она недоделана, а софт...:) А сама BeOS имеет вполне законченный и логичный вид имхо...

2Irsi: Реинкарнацию, к сожалению, не видел... Недостаток программ как раз и есть следствие недоделанности. Лично для меня отсутствие текстовой консоли - недостаток. Отсутствие многопользователности (слово-то какое:)) - большой недостаток (не только для меня). Закрытость кода - тоже недостаок (я не требую на него GPL или BSD-like лицензию, но открыть-то его можно?). Слабый TCP/IP стек - зачем было изобретать плохой велосипед, если можно было взят из BSD? Если-бы не эти недостатки, я уверен, что нашлось бы немало желающих побаловаться с ней, а так получается, что она позиционируется на пользователей Windows'9x, а для них она без MS Office (именно MS!) не нужна...

2Led: на тему реинкарнации - http://www.evilla.com/
Поддержка от Sony это тебе не ... собачий - эти умеют продвигать всякую фигню...:)
Многопользователность - нафига на десктопе? К тому же все необходимое для ее реализации есть, осталось только написать соответствующий сервер к микроядру.
Открыть код - увы все не так просто. Во-первых это отпугивает инвесторов, во-вторых в ней дофига кода, лицензированного у третих фирм, которые никогда не согласяться на его открытие. Вариант, аналогичный тому, которое выбрало BSD разделившись на FreeBSD & BSDi обсуждался вроде, но после краха линуксовых компаний после которого инвесторы и так с недоверием относившиеся к OpenSource, а опсле этого ставшие шарахаться от этой модели как черт от ладана, эти обсуждения прекратились...
TCP/IP стек к слову из NetBSD и взят... :) Они его просто слегка кастрировали с целью ускорения... В принципе для десктопа и такого хватает считали они. Но потом вроде одумались - BONE beta уже доступна.
Офис к слову на ней есть и имхо он гораздо лучше всех линуксовых, хотя конечно это не MS Office... Он правда коммерческий, но цена для буржуйского пользователя копеечная. Да и я бы купил еслиб: 1. Он у нас продавлся. 2. Яб не нашел то место, где можно спереть...:)

2Irsi: Многопользовательность (псевдо) даже в Win'9x есть :) Все-таки разграничение прав по владельцам файлов хотя-бы на элементарном уровне нужна даже для домашнего пользователя (если, конечно, не живешь не один)... Если так просто сделать, то почему ж не сделали? А если сделать, то как себя в такой среде поведут написанные ранее без ее учета прогаммы - перестанут работать, или будут на права ложить? IMHO, это такая вещь, которую "потом" прикрутить не так просто, она должна быть изначально. А без этого место BeOS даже в SOHO не просматривается, разве что в PDA и телеприставках... На счет Оффиса: все дело в том, что глупым юзерам не нужен просто Оффис, им даже не нужен Хороший Оффис, им нужен MS Office и ничего более ;) Поделись, где можно "спереть" :)

2Led: где спереть, где спереть... а какже "мы линуксоиды честные люди, пользуем токо легальный софт, в отличае от Вас виндузятников, воришек поганых!" ;))) Шутка... на сайте linker'a посмотри... или на BeZone - не помню точно на каком из них... на www.bebits.ru увы ссылка нерабочая...:( Может правда поправят, хотя есть признаки того что нет...

На счет многопользовательности (блин не выговыришь!) - а как себя ведут приложения из 9х в nt/2k? Если с головой писались - то нормально, если без головы - то только из-под админа и/или с бубном. Первых имхо больше все же, к тому же BeOS имхо организована так, что написать приложение, которое будет глючить при многопользовательском окружении несколько сложней, чем под винды... хотя тоже можно разумеется.
И еще раз - на десктопе многопользовательское окружение возможно и полезно, но его присутствие некритично. Мне удобно, но большинство юзверей от него плюются, например макентоиды назвали присутствие многопользовательского окружения в MacOS X шагом назад и грязно на него плюются... Впрочем я давно заметил что большинство решают эту проблему автологоном с правами админа/рута... Так что как не крути, но на десктопе для большинства это не более чем лишнее геморой и тормоза.
Да, я дома его использую... но не активно если честно.

На счет телепреставок и пда - а они на этот рынок и орентируются... На рынке десктопов с мелкософтом может бороться только тот, про которого в психиатрии говорится "полная утрата контакта с реальностью, неспособность адекватно оценивать факты и ситуацию" :)
Более того - я всегда говорил что BeOS это как концепт-кар в автомобилестроении, интересно, познавательно, приятно посидеть за рулем и вообще - тщательное знакомство очень полезно, просто необходимо для професионалов. Но вот ездить на нем каждый день на работу - увольте!

Ребята, не надо спорить из-за ерунды! Linux отли- чается от форточек не мышью, а идеологией. Ну, и еще много чем. ;-) Главное, что бы его не сгубили гоняющиеся за красотой и простотой kde-шники и про- чие бисексуалы ( т.е. любители и Линукса и Винды). Всем привет!