Подскажите наконец-то нормальную IDE

>> Проект явно вас разочаровал :) (хотя и непонятно, почему).

>посмотрите их код и что это из себя реально представляет, а не статьи комрадо кормчего о том, как всё чудесно и замечательно в проекте FiST.. :-/ код темплейтов Linux 2.4/2.6 - это просто праздник какой-то и больше чем на защиту нерадивого студента "типа отстрелялся" он не тянет.

Код не так уж и важен, а оценить идеи я не могу - слишком мало знаю.

> самой идеи организовать уровень расширения за счёт наращивания очередной файловой системы поверх текущего дизайна VFS ничего не светит.

> union fs и в *BSD есть причём уже родной и существенно Более продвинутый и вылизанный. но это не решение в случае, когда вам нужно расширить или модифицировать функциональность уже существующего уровня VFS. причём сделать это полностью прозрачно для конечного пользователя.

Я не понимаю, куда уж прозрачнее, чем unionfs (или вы хотите обойтись вообще без ФС, перехватывая вещи типа sys_{open|read|write|stat|chmod}?), ну да ладно. А что мешает доработать VFS? И отправить патчи в ядро - раз уж нерадивые студенты из FiST это делают, вам сам бог велел :)

> Код не так уж и важен, а оценить идеи я не могу - слишком мало знаю.

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

если сравнить FiST, допустим, с Dazuko (http://www.dazuko.de/), то второй по качеству кода и применимости в реальной жизни даст сто очков вперёд. впрочем это не удивительно, потому что его делали несколько другие люди в других условиях. и преследуя, судя по всему, совершенно разные цели: если первый оставляет стойкое ощущение, что создавался лишь для написания статей о сферическом коне в абсолютном вакууме, то второй в первую очередь для реальной работы.

впрочем, Бог с ним, с FiST. не суть важно что там и как, живёт себе и пусть живёт, это их проблемы в конце-концов.

> Я не понимаю, куда уж прозрачнее, чем unionfs (или вы хотите обойтись вообще без ФС, перехватывая вещи типа sys_{open|read|write|stat|chmod}?), ну да ладно.

нет, перехватить sys_foo недостаточно.

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

- набор путей может быть любым вплоть до "/". наборов может быть несколько количество каждый со своим ключом.
- низлежащая файловая система локальна, но её тип может быть любым. модификация файловой системы не допускается.
- дерево точек монтирования полностью отслеживается причём для каждого пространства имён и включая все возможные извраты, кои можно учинить с помощью mount (благо на Linux их как грязи).
- наличие механизма шифрования в системе *никак* не проявляется и не влияет на методы её администрирования (sic!). естественно кроме задания администратором набора путей и ключей.
- модификация ядра и требование к его пересборке конечным пользователем не допускается aka все ограничено модулем. правда, как послабление, все должно работать лишь с заданным набором дистрибутивов.
- естественно SMP safe и вообще надёжно как стадо слонов.
- минимальный оверхед промежуточного уровня, естественно за исключением самого процесса шифрования как данности.
- все правила одинаково важны.

> А что мешает доработать VFS? И отправить патчи в ядро - раз уж нерадивые студенты из FiST это делают, вам сам бог велел :)

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

ps: ну и вечный вопрос - что делать с уже существующими заказчиками, которые используют RHEL3/4[/5] или SLES9/10[/11]? их ой как много и требовать от них обязательного обновления текущих установок до самой последней версии - которой ещё даже не существует - с точки зрения маркетинга равнозначно самоубийству..

// wbr

> если сравнить FiST, допустим, с Dazuko (http://www.dazuko.de/), то второй по качеству кода и применимости в реальной жизни даст сто очков вперёд.

> впрочем, Бог с ним, с FiST

Ну да. Изначально-то речь шла о примерах работы внутри Линукс VFS :)

> нет, перехватить sys_foo недостаточно.

Я неудачно выразился - перехватить соответствующие операции над инодами.

> представьте себе задачу навроде реализации прозрачного шифрования данных на файловой системе

Если нужно шифровать только данные в файлах, то перехвата функций открытия/чтения/записи должно хватить. Если же надо шифровать и метаданные - тогда даже и мыслей нет (но я и не специалист Ж:))

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

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

> да и доработка уровня VFS в Linux до поддержки им многоуровневой файловой системы с возможностью прозрачного расширения - задача не столь тривиальная и требует массы усилий и времени.

Верю сразу и безоговорочно. Но "жизнь кончается не завтра" - всё равно для "надёжно как стадо слонов" всё равно придется это делать.

> Я неудачно выразился - перехватить соответствующие операции над инодами.

ну не только над инодами но и над другими объектами то-же. операции inode - это лишь управление деревом файловой системы (mkdir, link, unlink, rmdir, setattr etc) но и только aka метаданные. но нужно ещё перехватывать операции суперблока чтобы отследить первичное монтирование файловой системы для перехвата уже её начальных операций, операции файла чтобы видеть open/close/read/wrtie/etc, операции адресного пространства address_space чтобы видеть доступ через разделяемую память etc. но и этого недостаточно, потому что тот-же vfsmount не имеет вектора операций и отследить, например, "# mount --bind /from /to" на уровне перечисленных объектов не удастся так как он исполняется сугубо внутри VFS. тут уже придётся перехватывать некоторые системные вызовы как таковые..

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

> Если нужно шифровать только данные в файлах, то перехвата функций открытия/чтения/записи должно хватить. Если же надо шифровать и метаданные - тогда даже и мыслей нет (но я и не специалист Ж:))

ну это на первый взгляд. на самом деле всё немного сложнее:

- для перехвата записи в файл нужно перехватить операцию write() заданного файла.
- операция файла берётся из его иноды, которая создаётся динамически -> нужно перехватывать создание иноды
- ..для чего нужно перехватывать операции соотв. суперблока
- ..для чего нужно перехватывать создание самого суперблока в описателе файловой системы file_system_type чтобы отследить новые суперблоки
- запись может быть и через разделяемую память -> нужно перехватывать address_space_operations для иноды
- мы имеем набор путей, которые должны шифроваться. чтобы понять, принадлежит ли данный file->write() нашему пути, нужно отресолвить его dentry в обратном порядке. чтобы не делать это на каждый write [накладно] нужно ещё перехватывать file->open() и file->release(). лучше всего держать свой список открытых инод для быстрого поиска.
- и так далее и тому подобное..

получается, что даже для такой в общем то несложной задачи как реализация прозрачного уровня шифрования данных в регулярных файлах придётся перехватить операции практически всех объектов файловой системы [и не только] бо одно автоматически тянет за собой и другое.

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

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

> И эта идеология себя оправдывает.

это весьма спорный вопрос.

// wbr

> Верю сразу и безоговорочно. Но "жизнь кончается не завтра" - всё равно для "надёжно как стадо слонов" всё равно придется это делать.

ну не факт. "на каждый хитрый зад.." (c) народная мудрость. тем более, что задачи улучшения Linux во вселенском масштабе как таковой не стоит а для реализации проекта с заданными ограничениями всегда можно найти обходные - но тем не менее надёжные - пути. для этого в конце-концов и существует инженерная мысль - реализовать невозможное даже в очень неблагоприятных условиях. иначе всё становится совсем просто и неинтересно :)

// wbr

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

Они грамотные люди, так что, ИМХО, это by design.

>> Если нужно шифровать только данные в файлах, то перехвата функций открытия/чтения/записи должно хватить. Если же надо шифровать и метаданные - тогда даже и мыслей нет (но я и не специалист Ж:))

>ну это на первый взгляд. на самом деле всё немного сложнее:

Глупо спорить с человеком, всё это реализовавшим 8), но

> - запись может быть и через разделяемую память -> нужно перехватывать address_space_operations для иноды

AFAIK, даже запись через разделяемую память производится через метод инода

> что вы понимаете под официальной идеологией? stable_api_nonsense.txt?

Да :/

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

Эти люди создали самую успешную и живучую из современных ОС (да, именно _самую_ - по критерию стоимость/распрстраненность).

> есть заказчики - будут и решения. не смотря на чью-то там "идеологию" и ошибки проектирования и ведения проекта.

С этим никто и не спорит. "Запрограммировать можно всё", как любил гооврить мой начальник.

>> И эта идеология себя оправдывает.

>это весьма спорный вопрос.

Здесь мы agree to disagree :) ИМХО, вещи вроде rmap, SELinux, namespaces, -rt с сохранением двоичной совместимости сделать нельзя (то есть можно, но это будет настолько сложно, что имеющимися силами не потянуть). С сохранением стабильного API - можно, но сильно замусорив систему, и опять же потратив на это время и силы. Другое дело, что ломать API for no good reason - это, блин, бесит.

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

...надежные при соблюдении <длинныйсписоквключающийфазулуны> ограничений :/ Мой опыт говорит о том, что делать надо нормально и надежно, именно потом, что "на каждый хитрый зад.." найдется неучтенная ситуация. Но это моё личное мнение.

> AFAIK, даже запись через разделяемую память производится через метод инода

все-таки не совсем:

--- cut ---
struct inode_operations {
int (*create) (struct inode *,struct dentry *,int, struct nameidata *);
struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *);
int (*link) (struct dentry *,struct inode *,struct dentry *);
int (*unlink) (struct inode *,struct dentry *);
int (*symlink) (struct inode *,struct dentry *,const char *);
int (*mkdir) (struct inode *,struct dentry *,int);
int (*rmdir) (struct inode *,struct dentry *);
int (*mknod) (struct inode *,struct dentry *,int,dev_t);
int (*rename) (struct inode *, struct dentry *,
struct inode *, struct dentry *);
int (*readlink) (struct dentry *, char __user *,int);
void * (*follow_link) (struct dentry *, struct nameidata *);
void (*put_link) (struct dentry *, struct nameidata *, void *);
void (*truncate) (struct inode *);
int (*permission) (struct inode *, int, struct nameidata *);
int (*setattr) (struct dentry *, struct iattr *);
int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
int (*setxattr) (struct dentry *, const char *,const void *,size_t,int);
ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);
ssize_t (*listxattr) (struct dentry *, char *, size_t);
int (*removexattr) (struct dentry *, const char *);
void (*truncate_range)(struct inode *, loff_t, loff_t);
};

struct address_space_operations {
int (*writepage)(struct page *page, struct writeback_control *wbc);
int (*readpage)(struct file *, struct page *);
void (*sync_page)(struct page *);

/* Write back some dirty pages from this mapping. */
int (*writepages)(struct address_space *, struct writeback_control *);

/* Set a page dirty. Return true if this dirtied it */
int (*set_page_dirty)(struct page *page);

int (*readpages)(struct file *filp, struct address_space *mapping,
struct list_head *pages, unsigned nr_pages);

/*
* ext3 requires that a successful prepare_write() call be followed
* by a commit_write() call - they must be balanced
*/
int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
/* Unfortunately this kludge is needed for FIBMAP. Don't use it */
sector_t (*bmap)(struct address_space *, sector_t);
void (*invalidatepage) (struct page *, unsigned long);
int (*releasepage) (struct page *, gfp_t);
ssize_t (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
loff_t offset, unsigned long nr_segs);
struct page* (*get_xip_page)(struct address_space *, sector_t,
int);
/* migrate the contents of a page to the specified target */
int (*migratepage) (struct address_space *,
struct page *, struct page *);
};
--- cut ---

как видно из структуры, операции иноды предназначены лишь для управления деревом файловой системы да доступа к метаданным. в свою очередь, у каждой иноды есть указатель на struct address_space - i_mapping который содержит указатель на операции над адресным пространством и уже они отвечают за.

> Эти люди создали самую успешную и живучую из современных ОС (да, именно _самую_ - по критерию стоимость/распрстраненность).

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

// wbr

> ...надежные при соблюдении <длинныйсписоквключающийфазулуны> ограничений :/ Мой опыт говорит о том, что делать надо нормально и надежно, именно потом, что "на каждый хитрый зад.." найдется неучтенная ситуация. Но это моё личное мнение.

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

банальный пример - vfsmount_lock или files_lock. обе блокировки иногда жизненно необходимы для надёжной работы с VFS "извне". но в зависимости от минорной (sic!) версии ядра их то объявляют глобальными и экспортируемыми, то просто глобальными, то вообще статиком. видимо, на это сильно влияет фаза луны. и хрен тут угадаешь, разресолвятся они завтра или уже нет. а помножим это на активную самодеятельность конкретных дистрибутивописателей, которые то-же не могут не отличиться и взять и спрятать вроде бы открытые объекты в своём конкретном творчестве версии x.y.z.. русская рулетка и только. о какой надёжности "в целом" можно говорить при таком подходе :-?

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

ps: sic! речь идёт о ядре а не о userland.

// wbr

> операции иноды предназначены лишь для управления деревом файловой системы да доступа к метаданным. в свою очередь, у каждой иноды есть указатель на struct address_space

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

> даже если допустить, что это действительно так

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

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

> патчи, бэкпорты, отсебятину и нововведения

Всё-таки при _текстовой_ модификации VFS достигается другой уровень надежности. По крайней мере, адрес нужного спинлока не уплывет :) Да и вообще возможностей больше. В этом и есть идеология системы.

"We've put procedures in place. It's called SOURCE CODE" -- Alan Cox, в ответ на какие-то жалобы по поводу отсуствия процедур, обеспечивающих совместимость драйверов с разными релизами ядра.

> Ну да - операции записи достижимы из иноды: при создании иноды подменить их, занести во внутреннюю таблицу резольвенное имя, и потом не больше ни за чем не следить. По крайней мере, на первый взгляд неспециалиста :)

ну сама идея лежит где-то там, это верно. и подменяются они на пару с inode/file_operations для каждой новой и существующей инод. всё что можно подменить, то и подменяется..

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

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

> Всё-таки при _текстовой_ модификации VFS достигается другой уровень надежности. По крайней мере, адрес нужного спинлока не уплывет :) Да и вообще возможностей больше. В этом и есть идеология системы.

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

> "We've put procedures in place. It's called SOURCE CODE" -- Alan Cox,

btw я не понял смысла этого выражения.

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

отмазки, кругом одни отмазки..
впрочем, не привыкать.

знаете, когда MS Windows действительно наступит конец? когда Vista не сможет или откажется запустить приложения N-летней давности, собранные под WinNT. после этого можно смело начинать отчёт времени и идти пить кофе. но этого, очевидно, не наступит бо в Microsoft работают совсем не дураки.

ps: однако firefox-овыский спелчекер знает, что есть слово раздолбай.. :) это приятно.

// wbr

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

Да

>> "We've put procedures in place. It's called SOURCE CODE" -- Alan Cox,

>btw я не понял смысла этого выражения.

Диалог был примерно такой:

"Ктототам: Ну почему вы, уйопки, не можете сделать так, чтобы драйверы работали для любой версии ядра?

Алан: Мля, да не вопрос - давай исходники, и они БУДУТ работать для каждой версии"

Конечно, в оригинале это звучало гораздо эффектнее :)

> знаете, когда MS Windows действительно наступит конец? когда Vista не сможет или откажется запустить приложения N-летней давности, собранные под WinNT

Речь же шла о драйверах, а не о userland :)

Резкого вендекапца не будет. В лучшем случае - медленное угасание и уход. Более реально длительное сосуществование с медленно набирающим свою долю Линуксом.

> Диалог был примерно такой:
> "Ктототам: Ну почему вы, уйопки, не можете сделать так, чтобы драйверы работали для любой версии ядра?
> Алан: Мля, да не вопрос - давай исходники, и они БУДУТ работать для каждой версии"
> Конечно, в оригинале это звучало гораздо эффектнее :)

btw открытость исходников в данном случае есть отмазка чистой воды. в ожидании, что их, исходники, оппонент не откроет и на этом спор закончится [что видимо и последовало].

но допустим, я, производитель 3d party software ранее закрытого, говорю мол - OK нате пжалста. у нас тут есть одна очень хитрожопая штуковина мы её навояли и теперь открываем ядерную часть. она пользует то, то и то (abc_lock как пример). и действительно открываю исходники смотри не хочу. не факт, что под GPL, но открываю. а пусть даже и под GPL.

ну и что это меняет? ну открыл. в ядро по ряду причин они не попадают да этого и не нужно. ну нахрена в нём хостить подсистему прозрачной защиты данных Иван Иваныча, если без внешнего ПО (99%) она никому не нужна? правильно, незачем. что, факт открытости какого-то 3d party продукта заставит задуматься Васю Пупкина перед тем, как он в порыве страсти добавит очередной постфикс _GPL к ранее открытому EXPORT_SYMBOL или вообще снесёт его нахрен? не думаю. Васе на это вообще фиолетово и думает он сейчас совершенно о другом. единственное, что может реально остановить Васю - это пиз&^%^%$ от мейнтейнеров что после его криворукого патча ядро почему-то перестало собираться или работать. тогда да, Вася уже придётся подумать. а так, само ядро собирается - да. а на остальных нам с высокой колокольни, пусть сами трахаются как хотят.

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

> Резкого вендекапца не будет. В лучшем случае - медленное угасание и уход. Более реально длительное сосуществование с медленно набирающим свою долю Линуксом.

флейм по поводу приближения конца винды лучше всего проводить всё-таки в Talks. его читает существенно большая аудитория а здесь это пока что тема нонграта :0

// wbr

> btw открытость исходников в данном случае есть отмазка чистой воды. в ожидании, что их, исходники, оппонент не откроет и на этом спор закончится [что видимо и последовало].

Жаль, у меня нет ссылки на ту дискуссию. Не выглядело это отмазкой. Алан занимался переносом SCSI-драйверов 2.0 -> 2.2 -> 2.4, и привел конкретный пример с aha1542: был, мол, драйвероr для ISA и 1.3, и работает на SMP и 2.4, ну и какой вендор закрытой ОС вам такое обеспечит?

> ну открыл. в ядро по ряду причин они не попадаю

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

>> Резкого вендекапца не будет. В лучшем случае - медленное угасание и уход. Более реально длительное сосуществование с медленно набирающим свою долю Линуксом.

>флейм по поводу приближения конца винды

Да ни боже мой. Я не заинтересован во флейме по поводу вендекапца. По крайней мере, не сегодня и не с вами.

> Жаль, у меня нет ссылки на ту дискуссию. Не выглядело это отмазкой. Алан занимался переносом SCSI-драйверов 2.0 -> 2.2 -> 2.4, и привел конкретный пример с aha1542: был, мол, драйвероr для ISA и 1.3, и работает на SMP и 2.4, ну и какой вендор закрытой ОС вам такое обеспечит?

я так понимаю, вопрос "а зачем мне в 2007м году AHA1542" не рассматривается? в принципе IMHO зря.. в любом случае, покупая железку, я всё-таки покупаю цельный и готовый к употреблению продукт а не просто печатную плату с кусочками кремния. и IMHO вполне резонно ожидать, что вместе с железкой производитель обеспечит мне её работоспособность на моей системе. в противном случае, мне не нужна такая железка и я не буду её покупать и вопрос исчерпается сам собой. и есть ещё некоторые системы, для которых подавляющее большинство вендоров именно так и поступают..

впрочем, это опять уход от темы и офтопик.

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

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

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

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

впрочем, это то-же уже начинает напоминать флейм. какая есть система ведения проекта такая и есть.

> Конечно, порог входа высок, но зате наступает эра стабильного API - ваш компонент правят люди, занимающиеся изменениями API.

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

// wbr

> я так понимаю, вопрос "а зачем мне в 2007м году AHA1542" не рассматривается?

Нет, по одной простой причине - разговор относится году к 2000-2001 :) IIRC, у нас тогда еще был жив ком с aha1542 - может, поэтому я и запомнил.

> покупая железку, я всё-таки покупаю цельный и готовый к употреблению продукт а не просто печатную плату с кусочками кремния. и IMHO вполне резонно ожидать, что вместе с железкой производитель обеспечит мне её работоспособность на моей системе.

Нет. Потому что не на "вашей системе", а на Windows. Увы, именно так обстоят дела.

> а что до примера, то ключевое слово тут - включили в ядро и прикрепили сопровождающего.

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

> представьте себе размер психиатрической больницы для сотрудников компании Microsoft, если бы все - даже самые мелкие - вендоры стали коммитить им свои драйвера хотя бы просто для включения в состав базового дистрибутива... :)

:D

Вы почти буквально повторили аргумент Джеффа Мерки примерно тех же времен 8) Может, это даже было сказано в том же треде (Jeff Merkey - бывший ведущий разработчик NetWare, после ухода оттуда - глава Timpanogas, автор NWFS для Линукс). Он говорил, что для выживания и сохранения здравого рассудка разработчиков нужно зафиксировать интерфейс драйверов и организовать раздельные релизы core kernel и драйверов. Он сказал это несколько лет назад - но ничего не изменилось, Линукс живет и развивается, а психиатры маются без работы.

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

Не надо нас пугать драйверами :) На самом деле, всё не совсем так (даже совсем не так). Во-первых, нормально написанный драйвер (а другой в ядро не примут) на maintenance ядра почти никакого влияния не оказывает. Его надо править при изменении драйверных API, но знающему человеку это совсем ни разу не вопрос (ИМХО, чем больше драйверов в дереве ядре - тем лучше будет драйверный API). Во-вторых, драйверов гораздо меньше, чем кажется - во многих железках под разными марками скрывается один и тот же силикон, так что один и тот же драйвер может рулить кучей железок (как на практике и происходит).

> не всегда есть хорошо когда кто-то начинает править мой код

Да никто не будет его править просто так, с целью улучшения - только когда происходят whole-tree changes

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

Единственное, что меня раздражает - это то, что на совершенно невинный символы вешается EXPORT_SYMBOL_GPL. Ну еще отношение Линуса к userspace-драйверам, но это не столько политика, сколько психология :)

Что-то народ совсем от темы отвлекся :) Пользуясь случаем, хотел бы узнать как можно выставить шрифт в конфиге GVim.

Делаю примерно так ( ~/.vimrc ): if has("gui_running") colorscheme desert set guifont=terminus endif

Шрифт выставляется, но как выставить его размер? Как только я не пробовал... не выходит. А каждый раз после запуска лезть в меню выбора шрифта не хочется.

Извиняюсь, форматирование поехало.

Что-то народ совсем от темы отвлекся :) 
Пользуясь случаем, хотел бы узнать как можно выставить шрифт в конфиге GVim.

Делаю примерно так ( ~/.vimrc ): if has("gui_running") colorscheme desert set guifont=terminus endif

Шрифт выставляется, но как выставить его размер? Как только я не пробовал... 
не выходит. А каждый раз после запуска лезть в меню выбора шрифта не хочется.

set guifont=terminus\ 10

Спасибо! Помогло.

разделяю мнение автора о vime тоже им пользуюсь но считаю не очень удобным , поэтому в основном пользуюсь Kate + два плагина 1 http://www.kde-apps.org/content/show.php?content=47743 плагин для подержки ctags в проектах нужно только настроить комбинации клавиш как на vim, одна проблемка по тегам можно скакать только вперед но внесением небольшого фикса легко делается стек переходов по функциям и мы можем возвращатся назад по стеку фикс я написал на в комментах (см ссылку) 2 http://www.kde-apps.org/content/show.php?content=51805 а это мой плагин он просто показывает дерево функций классов структур в открытом файле + поиск функций + doxygen документация отображение и генерация шаблона описания объектов ну и вообще написанием плагинов Kate можно расширять не хуже вима в некоторых моментах даже лучше