ReactOS Tech Talk на факультете ВМК МГУ

Да понятно, но будет большим упущением если ACT не будет работать.
А касаемо баз, там ничего прямо особенного что бы было препятствие сделать базы по крайней мере совместимыми (используя один и тот же формат). Тут дело только в наборе самих исправлений. Совсем не сразу ROS будет поддерживать все эти исправления-хаки для приложений. Их ведь там 407, если выкинуть все простые VersionLie, то 385, впрочем там хватает и других простых типа Force640x480, Force640x480x16, Force640x480x8, но их всё же гораздо меньше чем уникальных и довольно сложных — вряд ли получится в короткий срок их всех воплотить. С другой стороны тут можно и продвинуться дальше, добавив те полезные (для тех же некоторых старых игрушек и ПО) исправления которые сама МС не торопится добавлять.

Я то имел ввиду те самые «архитектурные» преимущества ядра NT о которых любят говорить приверженцы ReactOS, то есть те из-за которых якобы стоит пытаться копировать ядро NT (что весьма затруднительно, если вообще возможно) вместо того чтобы взять готовое и 100% работоспособное практически на любом железе ядро Linux. Ну или *BSD если уж Linux не подходит по религиозным причинам. Я не то чтобы сходу отрицаю существование таких преимуществ, но ходелось бы узнать в чём именно они заключаются.

Я то имел ввиду те самые «архитектурные» преимущества ядра NT о которых любят говорить приверженцы ReactOS

Я пока что вижу только два явных преимущества винды над linux: групповые политики (точно можно реализовать в linux, но пока что, насколько я знаю, не сделано), и права доступа (тут я вообще не знаю, реально ли это реализовать).

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

Я пока что вижу только два явных преимущества винды над linux: групповые политики (точно можно реализовать в linux, но пока что, насколько я знаю, не сделано), и права доступа (тут я вообще не знаю, реально ли это реализовать).

Но всего перечисленно тобой нет и в РеактОС. И если уж пилить это всё с нуля, то где шансы на успех больше - в Линуксе где есть рабочее ядро, готовая инфраструктура, деньги корпораций и много разработчиков или в РектОС где нет ничего и перспективый судебного преследования со стороны MS вполне реальны?

Но всего перечисленно тобой нет и в РеактОС.

Ну, мы тут пытались обозначить «идеальную ситуацию» - что было б, если б ReactOS достигла своей цели. Я начал говорить о том, что и в этом случае непонятны её преимущества перед linux+samba+wine, но меня успешно поправили, сказав о правах пользователя и групповых политиках. Я понимаю, что вероятность, что мы когда-то увидим 100% (или 99%) рабочую ReactOS приближается к нулю. На создание более-менее полноценной версии haiku ушло 12 лет, так всё-таки beos куда попроще была...

где шансы на успех больше?

А вот не знаю к стыду своему, можно ли как-то прикрутить nt-like права пользователя к линуксу, и что для этого нужно. Пока что не представляю, как это сделать. В том, что аналог grouppolicy можно запилить, я даже не сомневаюсь.

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

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

И как отсюда выбраться, не понятно.

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

В линуксе всё было б хорошо с этим, если б не gtk3.

А как же Qt против GTK2? А как же единая тема через одно место?

можно ли как-то прикрутить nt-like права пользователя к линуксу, и что для этого нужно. Пока что не представляю, как это сделать.

Увы, пока наблюдаю только вагон костылей в виде SELinux, RSBAC, Grsecurity (gradm), AppArmor, TOMOYO, bindfs и они продолжают плодиться. Может из этого списка что-нибудь подойдёт. Не знаю придут ли они когда-нибудь к единому решению.
Часть из перечисленного даёт больше гибкости и возможности (под винду от сторонних компаний такое тоже есть, если что), но какой ценой — тормоза (мандантный контроль быстрым не бывает), как-то приделано сбоку и довольно стрёмно в администрировании, это не говоря о плохой переносимости (я не сильно ковырялся, так что тут где-нибудь могу ошибаться) — отдельные БД/файлы, а в случае RSBAC, TOMOYO 1 ещё и ядро патчить самому. SELinux тоже например не везде доступен, если говорить о VPS.
Короче явный нестандарт и костыли-костылики. Я кстати удивляюсь почему даже user_xattr по умолчанию выключены, уже намёк что даже такой минимум как-то через жопу сделан.

Вообще на заметку. Почему так часто патчат под свои фичи ядро Linux?
Почему куча антивирей и отдельных мандатных решений и так сносно работают с ядром винды, а тут и для SELinux нужна поддержка и для RBAC и для AppArmor с его Yama и для TOMOYO и т. д. Как-то это всё не очень похожее на хороший дизайн ядра.
Есть только некое AKARI (ответвление TOMOYO) выполненное в виде модуля ядра, но он не всё может что может TOMOYO.
Как я понял есть проблемы в механизме LSM (Linux Security Module).

А что мешает сделать точно так же в линуксе?

Ну вот что-то мешает - такого зоопарка тут нет.

А как же Qt против GTK2? А как же единая тема через одно место?

Qt vs GTK2 - это, всё-таки, больше тулкитофобия. Qt3/4/5 и GTK2 можно привести к единству, установив очень хорошо настраиваемый движок QtCurve. А вот GTK3 - нет.

Увы, пока наблюдаю только вагон костылей в виде SELinux, RSBAC, Grsecurity (gradm), AppArmor, TOMOYO, bindfs и они продолжают плодиться.

Вот и я о том же. И ни один не даёт той совокупности настраиваемости с прозрачностью, что есть у Windows. Как ни смешно звучит, но для нормального распределения прав на сервере проще использовать samba server плюс samba client на десктопах, хотя самба-то вроде как и не для того предназначена.

удобной консоли управления - нема

Справедливости ради заметим, что удобной консоли управления у GPO тоже нет.

можно ли как-то прикрутить nt-like права пользователя к линуксу

Это какие? NTFS ACL? Ну так POSIX ACL есть.

У меня есть вопрос. Зачем столько больших букв?

NTSTATUS
21 NTAPI
22 IoConnectInterrupt(OUT PKINTERRUPT *InterruptObject,
23 IN PKSERVICE_ROUTINE ServiceRoutine,
24 IN PVOID ServiceContext,
25 IN PKSPIN_LOCK SpinLock,
26 IN ULONG Vector,
27 IN KIRQL Irql,
28 IN KIRQL SynchronizeIrql,
29 IN KINTERRUPT_MODE InterruptMode,
30 IN BOOLEAN ShareVector,
31 IN KAFFINITY ProcessorEnableMask,
32 IN BOOLEAN FloatingSave)
33 {
[\code]

POSIX ACL

А ты их смотрел вообще? Вот удивляет (ты не первый такой) — увидели надпись «ACL» значит то же самое?

Ну вот что-то мешает - такого зоопарка тут нет.

Ну и программ в целом меньше. А так вспоминаются: Blender, Sublime Text, Steam. Как бы не вышло так что с большей популярностью болезнь перекочевает. Если же нет, то очень любопытно что же может мешать.

А ты их смотрел вообще?

Да, а ты?

Справедливости ради заметим, что удобной консоли управления у GPO тоже нет.

Да, могло бы быть и получше, но я бы не сказал, что там что-то прям так плохо.

Ну так POSIX ACL есть.

Сравнил ежа с ужом...

Я тоже, а вот ты виндовых похоже не видел. В винде не только права на файлы, но мы остановимся только на файловых:
1. у POSIX ACL всего 3 права на файл и папку; у Windows ACL на файл 13, на папку 14 прав;
2. у POSIX ACL нет наследования, у Windows ACL есть наследование;
3. у POSIX ACL в правах каталогов нельзя указать на что то или иное правило распространяется; в Windows ACL можно.
4. не знаю стоит ли сюда примешивать, но у Windows ACL есть по такой же схеме встроенный аудит (журналирование).
Ещё у POSIX ACL есть такой костыль в виде mask, в Windows ACL об этом думать не надо.
Тут ещё у Windows ACL есть особенности, типа возможности запретить тем же админам менять владельца, но думаю и всего этого достаточно.
Поправь меня если не так.

В винде не только права на файлы, но мы остановимся только на файловых:

Да, я именно о файловых (NTFS ACL) речь и веду.

1. у POSIX ACL всего 3 права на файл и папку;

На слово «папка» брезгливо поморщусь, но промолчу.

у Windows ACL на файл 13, на папку 14 прав;

Да, но практическое значение из этих 14 имеют только Read, Write и Execute. Кому и для чего может понадобиться, скажем, разрешение на смену владельца?

2. у POSIX ACL нет наследования, у Windows ACL есть наследование;

Либо я чего-то очень не понимаю, либо наследование у POSIX есть.

3. у POSIX ACL в правах каталогов нельзя указать на что то или иное правило распространяется; в Windows ACL можно.

Либо я снова чего-то очень не понимаю, либо опять-таки можно.

4. не знаю стоит ли сюда примешивать, но у Windows ACL есть по такой же схеме встроенный аудит (журналирование).

Я тоже не знаю, и судя по тому, что в стандарте (POSIX 1003.1e DRAFT 17) аудит прописан, но AFAIK нигде не реализован, единого мнения на этот счет нет.

Ещё у POSIX ACL есть такой костыль в виде mask, в Windows ACL об этом думать не надо.

Разверни мысль, будь добр.

Тут ещё у Windows ACL есть особенности, типа возможности запретить тем же админам менять владельца

Эти особенности происходят от того, что админ в винде — не то же самое, что рут в линухах (и прочем unix like). Эффективно запретить что-либо NT Authority\Local system нельзя, насколько мне известно.

я бы не сказал, что там что-то прям так плохо.

Простой пример: тебе по наследству достался хост, в умолчательные групповые политики которого внесены некоторые изменения. Что именно отличается от дефолтов — неизвестно и спросить не у кого. Штатными средствами работы с GPO ты забодаешься выяснять, где и что менялось.

Сравнил ежа с ужом...

См. мой ответ EvilFox'у чуть выше.

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

Тут написан один из способов, как это сделать.

См. мой ответ EvilFox'у чуть выше.

Ну простой пример. Сразу говорю - уж извини за слово «папка», но я не знаю, какое ещё употреблять. В IT-терминологии что английского, что испанского языка слова folder (carpeta), directory (directorio) и catalogue (catálogo) имеют совершенно разное значение, и мне прискорбно, что в русском их пытаются смешать. То, что есть в винде, когда речь идёт о правах доступа, корректно называть именно «папка» и никак иначе!

Итак, пример.
Есть file server, на нём папка share и куча разных папок. В одну из них доступ должен быть только у некоей группы лиц, и никто другой доступ иметь не должен - а если и должен, то это должно указываться явно. Далее, есть группа лиц, которые должны иметь доступ ко всем документам, есть те, кто ко всем, кроме вышеназванной папки. Есть часть, которые должны иметь доступ только к своим папкам. Далее: часть папок должны быть винды всем, но запускать открывать расположенные в них документы нельзя без получения разрешения (при этом можно увидеть, какие документы там есть); а часть не должны быть видны никому кроме тех, у кого есть на них права.

Как реализовать это на никсах? Я не говорю, что это не возможно - если честно, подобных задач не было; но я не в курсе, как это сделать и сходу мне ответ в голову не приходит. Думаю, при этом не надо напоминать, что пользователи все эти права должны получить сразу на своих компьютерах.

И вот всё описаное выше - это не «высосаное из пальца», а реальная задача, стоявшая передо мной совсем недавно...

На слово «папка» брезгливо поморщусь, но промолчу.

Ой какой брезгливый, у тебя там случаем не сектантский фанатизм?

Да, но практическое значение из этих 14 имеют только Read, Write и Execute. Кому и для чего может понадобиться, скажем, разрешение на смену владельца?

Даже и не знаю что ответить на такие утверждения. Оставлю без комментариев про практическое применение 14 прав и отвечу конкретно про смену владельца: кому? да ынтерпрайзу например, сходу тебе пример привести мне сейчас сложно (я не системный администратор), но я уже не раз встречался с ситуациями когда что-то на первый взгляд лишнее потом очень сильно пригождается в жизни, так что меньше категоричности — если есть значит кому-то надо. Тут ещё при аудите полезно.

Либо я чего-то очень не понимаю, либо наследование у POSIX есть.

И какое же наследование у POSIX ACL есть? Можешь показать пример? Только не надо показывать права по умолчанию это ≠ наследование. Наследование это когда я помещаю файл в папку и он наследует права данные ему от папки, при этом куски запрещающих правил перекроют разрешающие. Твоя же херня даёт права в этой папке только новым там созданным файлам. Из хоть каких-то решений на этот счёт я видел только bindfs через FUSE, но это нельзя назвать POSIX ACL.

Либо я снова чего-то очень не понимаю, либо опять-таки можно.

Вот такое можно?
http://i.imgur.com/rh0yfOE.png
http://i.imgur.com/9r9nb6E.png
Покажи как.

Я тоже не знаю, и судя по тому, что в стандарте (POSIX 1003.1e DRAFT 17) аудит прописан, но AFAIK нигде не реализован, единого мнения на этот счет нет.
DRAFT

Черновик с того времени так и не стал нормальной спецификацией? Тогда понятное дело почему не реализован и единого мнения нет.

Разверни мысль, будь добр.

http://users.suse.com/~agruen/acl/linux-acls/online/

In minimal ACLs, the group class permissions are identical to the owning group permissions. In extended ACLs, the group class may contain entries for additional users or groups. This results in a problem: some of these additional entries may contain permissions that are not contained in the owning group entry, so the owning group entry permissions may differ from the group class permissions.
This problem is solved by the virtue of the mask entry. With minimal ACLs, the group class permissions map to the owning group entry permissions. With extended ACLs, the group class permissions map to the mask entry permissions, whereas the owning group entry still defines the owning group permissions. The mapping of the group class permissions is no longer constant.
The group class permissions represent the upper bound of the permissions granted by any entry in the group class. With minimal ACLs this is trivially the case. With extended ACLs, this is implemented by masking permissions (hence the name of the mask entry): permissions in entries that are a member of the group class which are also present in the mask entry are effective. Permissions that are absent in the mask entry are masked and thus do not take effect.
The owner and other entries are not in the group class. Their permissions are always effective and never masked.

http://www.opennet.ru/docs/RUS/posixacl/posixacl-security.html.gz

При установке дополнительных прав доступа, также присваивается значение и элементу ACL_MASK, маске действующих прав доступа (effective rights mask). Значения ACL_MASK определяет лимит значения режима доступа для дополнительных пользователей и групп. Т.е. если режим доступа к файлу у пользователя rwx (чтение, запись, запуск), а маска - r--(только чтение), то у пользователя реально будет только доступ на чтение. По умолчанию (если не указывать конкретно) значение маски равно максимальному доступу среди всех дополнительных пользователей и групп.

http://docscom.ru/blog/nix/98.html

Иначе говоря, маска определяет верхний предел прав доступа, которые система ACL может присваивать отдельным группам и пользователям. Концептуально эта маска аналогична команде umask, за исключением того, что маска ACL действует всегда и указывает предоставленные, а не отобранные права. Записи ACL для названых пользователей, названых групп и группы, заданной по умолчанию, могут содержать права доступа, отсутствующие в маске, но ядро будет просто их игнорировать.

А ещё такая беда:

Эта принудительная целостность атрибутов позволяет более старым программам, которые даже не подозревают о существовании ACL, достаточно успешно работать в использующей эти списки среде. Однако существует и определенная проблема. Несмотря на то что ACL-запись group:: в приведенном примере вроде и отслеживает средний набор традиционных битов режима, это не всегда так.
С точки зрения унаследованной программы файл выглядит неизменяемым, хотя в действительности он доступен для записи для любого члена группы staff. Подобная ситуация нежелательна.

Там дальше ещё почитай, не буду я всё сюда копировать.

Эти особенности происходят от того, что админ в винде — не то же самое, что рут в линухах (и прочем unix like). Эффективно запретить что-либо NT Authority\Local system нельзя, насколько мне известно.

Верно, но мы от системы не работаем. Насколько я сейчас знаю без дыр войти из под системы можно только через:
а) планировщик событий;
б) службу запущенную от учётной записи системы.
Программа PSEXEC делает вариант б — можно увидеть по помеченной на удаление службе.
Раньше ещё через команду AT легко работало. Сейчас многое поприкрывали — теперь окно не появится если попытаться так запустить ту же консоль.
Если эти краники перекрыть, админы не смогут ворочить правами через СИСТЕМУ, а через неё можно например получить права на любой объект в ФС, даже если ей запретить всё, она всё равно может сбросить права и/или назначить себя владельцем (хотя если не сбрасывать, то доступ к объекту и его правам она получить не может).
С СИСТЕМОЙ много тонкостей, у неё не для всего есть права по умолчанию, я читал она сначала их должна получить от другого пользователя, но я не вникал в программерские дебри на этот счёт, не хватает опыта. Заметил сейчас что зачем-то для Program Files стоит запрет ей сменять владельца и разрешений, видимо какой-то смысл есть.

планировщик событий
планировщик заданий

Но не суть важно.

Забыл прокомментировать:

зато наконец-то нормальный проводник

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

который не хочется первым делом поменять на что-то другое

После DirectoryOpus на проводник винды даже смотреть не хочется. DO мощный, шустрый, хорошо настраиваемый. В линуксе ему я кстати тоже аналога не нашёл.
Надо будет попродвинуть его лучшие идеи в New Explorer который в ReactOS пилится, тогда можно будет брать проводник из ReactOS и забить на DO.

Я вижу результат - windows xp было невозможно пользоваться, vista стало возможно, 7 - хорошо; 8.1 - отлично и удобно. Исчезли зависания винды при зависании одного приложения; исчезло «засерание» ОС - windows xp даже на более-менее используемой виртуалке тормозить начинает через какое-то время, а семёрка/восьмёрка может жить без переустановок годами.

Так говорят после появления ЛЮБОЙ винды.

Исчезли зависания винды при зависании одного приложения;

Исчезло еще после выхода Windows NT. Чтобы XP завесить надо постараться. С другой стороны у меня и Win7 зависали и что? Это часто вообще от железа, а не ОС зависит.

а семёрка/восьмёрка может жить без переустановок годами.

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

Итак, пример. Есть file server, на нём папка share и куча разных папок. В одну из них доступ должен быть только у некоей группы лиц, и никто другой доступ иметь не должен - а если и должен, то это должно указываться явно. Далее, есть группа лиц, которые должны иметь доступ ко всем документам, есть те, кто ко всем, кроме вышеназванной папки. Есть часть, которые должны иметь доступ только к своим папкам. Далее: часть папок должны быть винды всем, но запускать открывать расположенные в них документы нельзя без получения разрешения (при этом можно увидеть, какие документы там есть); а часть не должны быть видны никому кроме тех, у кого есть на них права.

имеем ресурсы:

• /srv/files/share
• /srv/files/dir_n(1-n)

группы:

• share_users
• priveleged_users
• all_users

setfacl -R -m g:share_users:rwx /srv/files/share
setfacl -Rd -m g:share_users:rwx /srv/files/share
setfacl -R -m g:priveleged_uses:rwx /srv/files/dir_n*
setfacl -Rd -m g:priveleged_uses:rwx /srv/files/dir_n*
...
setfacl -R -m u:user1:rwx /srv/files/dir_n1
setfacl -Rd -m u:user1:rwx /srv/files/dir_n1
...
setfacl -m g:all_users:rx /srv/files/dir_for_show
setfacl -d -m g:all_users:rx /srv/files/dir_for_show

где dir_for_show - те ресурсы, содержимое которых должно отображаться всем.
По поводу видимости сложнее, есть, конечно, в самбе hide unreadable, но тогда и список файлов в папке не покажет. Как вариант - ссылки в личных подпапках, а на ресурсы выставить browseable=no.
Нужна также тастройка create mask=0600, directory mask=0700 и inherit acls=yes. Ну и выставить юних-права строго на рута или самбу, чтобы не мешались.
Разумеется, если я правильно понял, что вы хотите сделать.

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

Это вряд ли. Те, кто из команды ReactOS хотел свалить в Microsoft - свалили уже давно. Было такое. И их вклад был поменьше, чем у Брагина.

А Брагину, как я понимаю, просто интересно сделать открытый аналог Windows. Ничего плохого я тут не вижу. И Linux, и *BSD когда-то были аналогами коммерческих unix-систем.

Если устанет - тогда может и свалит. Его право. Что опять-таки никому не помешает воспользоваться его наработками. GPL-ными, между прочим.

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

О, а вот и наш Носовский-Фоменко подтянулся. Привет, давно не виделись.

Насчёт «иностранных», кстати, спорить не буду, проект действительно международный. Вот по поводу «фрилансеров»... «Фрилансеры» они за редкими исключениями в такой же степени, как Линус Торвальдс в первые годы разработки Linux.

Ты сам только что сказал, почему линукс нельзя подпускать к продакшену.

О, два тролля сцепились друг с другом. Какая прелесть.

MS можно хаять сколько угодно, но совместимость драйверов у них от NT4 до win2k/winxp была на очень хорошем уровне. Да, работало не всё и не всегда, но немалая часть драйверов могла работать не меняясь десятки лет.

Это, мягко говоря, преувеличение. Даже при переходе от Win2k к WinXP (которые по кишкам вроде бы отличались очень слабо) мне пришлось обновлять драйвер ТВ-тюнера. А уж переход от NT4 к Win2k - это переход на новую модель драйверов.

Я уж не говорю, что до появления XP подавляющее большинство юзеров не пользовалось теми виндами, которые ты назвал, а сидело на 9x, где всё было ну вообще совсем другое, и драйвера тоже.

Вот драйвера для XP действительно жили долго, но это следствие долгой жизни самой XP.

но совместимость драйверов у них от NT4 до win2k/winxp была на очень хорошем уровне

Наверное поэтому у меня на диске от материнки, купленной году так в 2003, было 4 каталога с дровами — NT4, 9x, 2k/XP, 2003.

ШТА? Церковная десятина? Или мы еще строим коммунизм?

Opensource обладает всеми признаками коммунизма.

Столько раз говорилось, что если человеку не дадут делать то, что он хочет, он не станет делать автоматом то, что от него требует «сообщество».

Да без проблем, пусть не делает. Но и кормить его не надо. Выкинуть посреди тайги, пущай делает что хочет без ограничений.

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

Вообще на заметку. Почему так часто патчат под свои фичи ядро Linux?

«Почему некоторые животные лижут свои половые органы?» «Потому, что ОНИ ЭТО МОГУТ, профессор!»

Ядро линукс можно патчить под себя - поэтому этим и занимаются. На недавнем OS Day был интересный доклад про Parallels Containers for Windows. Докладчик признал, что линукс они патчили, смотрели, делали что хотели - а с виндой это не проходит, приходится изворачиваться. А вовсе не потому, что винда из коробки позволяет что-то, чего не позволяет линукс.

www.linux.org.ru/people/vasya_pupkin/profile

Но сообщество GNU такого, что оно построено на вражде. KDE vs Gnome, XWindows vs Wayland/Mir, Systemd vs. остальное, и т.д.

Алексей, при всём уважении - это глупое заявление. Сообщество GNU построено на осознании зла, которое несёт с собой монополия проприетарного ПО. И у KDE и Gnome вполне себе здоровая конкуренция, на мой взгляд. Нельзя всех разработчиков выстроить в линейку и заставить писать одно DE. Тут в своё время MuZHiK-2 носился с лозунгом «Одна ОС, один десктоп». А потом Убунту бросила Гном и начала пилить Unity. Тут он и понял, что не всё так просто.

И да, не надо путать сообщество GNU и лоровских троллей.

А легенду про «нанимаемых за гроши фрилансеров» здесь форсит ровно один анонимус, в каждой новости про реактос. Ну и ещё пара человек начала за ним повторять, просто от недостатка объективной информации. Развеять этот миф очень просто - опубликовать на reactos.org обзорную сводку, кто и сколько раз финансировался из фонда ReactOS и показать, какую долю коммиты этих людей занимали в общем объёме за все эти годы. Насколько я понимаю - крайне незначительную.

вайн нужнен с одной целью: дешево портировать игры

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

Сообщество GNU построено на осознании зла, которое несёт с собой монополия проприетарного ПО. И у KDE и Gnome вполне себе здоровая конкуренция, на мой взгляд.

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

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

https://en.wikipedia.org/wiki/Halloween_documents
https://ru.wikipedia.org/wiki/FUD

2. Приверженцы определенного продукта, как правило даже лучше конкурентов знают недостатки этого продукта. Ситуацию можно сравнить с двумя машинами, застрявшими на одном болоте. Экипажи обоих машин пытаются вытолкнуть их из грязи, но им кажется, что это у них не выходит. Было бы логичным, попросить помощи у соседнего экипажа. (Но интересен не этот момент, а то, какое они принимают решение). Зачастую, вместо сотрудничества или соблюдения нейтральности, участники одной группировки, руководствуясь своим честолюбием, гордостью, чувством собственной уникальности, вместо цивилизованных методов начинают поливать участников другой группировки грязью, стремясь всячески ее дискредитировать, а самим остаться на коне. Это делается в тайной надежде, что поверженные потом смирятся с поражением и придут «выталкивать чужую машину».

И виноваты тут не только ЛОРовские троли, того же Поттеринга травят далеко не они.

Развеять этот миф очень просто - опубликовать на reactos.org

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

Имелось виду то, что кроме людей-сторонников здоровой конкуренции, существуют целые группировки проповедующие ненависть к определенному (чаще всего конкурирующему) продукту или его юзерам.

Да в интернете полно срачей: PS vs XBOX, Mac vs PC, ипхон вс ведроид, хром вс огнелис — везде, где есть две похожие сущности, будет срач.

Срачей бояться — в интернет не ходить.

Как с поддержкой WDF (KMDF? UMDF?)?