Комментарии 95
Не, мне реально нравится идея реактося, но с таким подходом и темпами оно имеет огромные шансы морально устареть, что называется *в нулину* до выхода v1.0
Ну я так понимаю, ReactOS это moving target, они целятся на все более поздние и поздние винды, поэтомуустареть, скорее всего, не устареетстать стабильным, скорее всего, не станет.
Fixed
Хотя лично я желаю проекту исключительно успехов. А то мне скоро не на чем будет игры запускать.
Вот есть РеактОС, которая появилось во времена Вин 9х.
Прошел 21 год. 9х устарел более чем полностью.
ReactOS выглядит вполне нормально в этом плане.
Что должно произойтие с ReactOS чтобы она устарела?
Windows 8..10 уже не становится лучше настолько, насколько это было во времена Windows 95,2000,XP,7.
До тех пор, пока ReactOS догоняет Windows — ей нет необходимости тратить огромные ресурсы на поддержание огромного парка оборудования, тех поддержки(обновлений безопасности), маркетинга, бюрократов, сэйлов.
Да и идти по проторенной дороге всегда легче (например нет необходимости тратить время на изобретение плиток и метро).
Но у догоняющих всегда будет бонус — им не нужно реализовывать всё, что внедряют Майки. Те сами не знают, взлетит ли новая технология. Сколько уже примеров, когда они тратят силы и время, пиарят, продавливают, рекомендуют нам, а потом выбрасывают в корзину: «не взлетело» (
Ну не будет она 100% совместима. 100% не совместима винда относительна винды (32/64/ru/en, обновления, фреймворки, поколения и проч.)
Не взлетит одна программка, взлетит другая, от конкурентов.
На домашних ПК — сейчас большинство приложений — это WEB (кроме игр).
На офисных… Представим, что функционал реакт будет удовлетворять требованиям по софту для всего 50-70% раб мест, остальным таки придется ставить Windows — уже огромный выхлоп.
Винда раздувается просто неприлично, такое количество ненужной неотключаемой хрени больше нигде нет
А что мешает сделать эту хрень отключаемой в ReactOS?
Совместимость с каким-нибудь старым софтом нужна не каждый день и не всем пользователям (но, тем не менее, время от времени возникает реальная нужда в совместимости).
Мне кажется, нужные штуки пробьются со временем. Если в РОС чего-то нет, найдутся люди и компании, которые напишут недостающее для себя, ну и с сообществом поделятся. А разработчиков софта это заставит задуматься: а так ли мне мне нужна в программе эта новая проприетарная фича от МС, или, может, есть что-то более универсальное?
Doom 1 на React 21
На онлайн конференции разработчиков в марте этого года обсуждали состояние готовности нового USB стека: reactos.org/project-news/march-2018-meeting-minutes
Винда десятая, которая IoT, вполне себе работает на малинке
Я не минусовал, но предположу, что толку для обычного пользователя от windows iot на малинке чуть меньше, чем никакого. Для разработчиков — да, но что там делать обычному пользователю? А вот linux на малинке вполне выполняет офисные функции
Спасибо за вашу работу, это очень круто.
А то под wine за лет 10 так и не нашёл способа писать кириллицей в информационном центре.
Да и вообще, можно попробовать ребёнку на комп поставить, это же не винда, так что идеологически можно, тем более что по идее должна завестись куча развивающих игрушек для детей.
Под винду такого добра значительно больше, чем под никсы.
Сейчас ему 4,5 года.
Ларчик, собственно, открывается очень просто:
env WINEPREFIX="/home/<имя_пользователя>/.wine" LANG=ru_RU.utf8 wine C:\\windows\\command\\start.exe steam://rungameid/214730
Между прочим, я это даже в документации к «Революции» указывал прямым текстом :)
Если что, вот ссылка на коммит: github.com/reactos/reactos/commit/2dfe5e3f463ca4d7eb920d25c2a33b29a70f3e27
Вот раньше был проект coLinux, такое специальное ядро, которое можно было запускать под виндой и оно эффективно использовало ресурсы (в отличии от виртуальной машины, например память только та, что реально занята). Было бы здорово иметь coWindows ядро. Чтобы для всего, что выше ядра, оно было неотличимо от настоящего, а работало поверх Linux. Ну, что-то вроде теперешнего WSL.
Можно было бы загружать рядом стоящую винду с подменой ядра и эффективным использованием ресурсов.
Я бы винду вообще не загружал и с удовольствием пользовался только Linux. Но некоторый софт заставляет поступать иначе. Под Wine работает не всё, в виртуалке часть ресурсов уходит в никуда.
(как-то я об этом уже писал в подобной теме. ЕМНИП, ничего конкретного не ответили)
Откуда оно возьмётся?
Я имел в виду отсутствие накладных расходов от виртуальной машины. Памяти потребялется столько, сколько надо приложениям, а не сколько выделено (да есть механизмы для решения проблемы). Нет тормозов из-за файловой системы в файле и т.п.
проще использовать упомянутый WSL
Это понятно. Но у меня основная причина, что винда не нравится. Чем меньше её будет, тем лучше.
Native versions of these DLLs do not work: kernel32.dll, gdi32.dll, user32.dll, and ntdll.dll. These libraries require low-level Windows kernel access that simply doesn't exist within Wine.
wiki.winehq.org/Wine_User%27s_Guide
Думаю, что кроме этих ещё многие настоящие dll откажутся работать.
Некоторое время назад можно было подменить ядро ReactOS ядром WinXP, и оно запускалось и даже работало, правда ругалось на неимплементированные функции системных библиотек/приложений.
А вот вопрос: оно у вас всё-еще древним mingw (с msys) собирается? Я собственно не про сам msys/mingw а про build-tools в нём и gcc в частности… Т.е. вот этим вот?
$ gcc --version
gcc (GCC) 3.4.4 (msys special)
А то оно же и правда старое, и медлючее...
Собирать с новыми build-tools не пробовали? Например:
$ export PATH=/c/mingw-w64-32/bin:$PATH
$ gcc --version
gcc.exe (i686-win32-dwarf-rev0, Built by MinGW-W64 project) 7.3.0
Да 7.x чуть капризнее (можно запросто UB словить где раньше не было), но зато рвёт все остальные компиляторы как тот Тузик ту грелку, особливо если O3, march=native и т.д…
У меня в некоторых довольно больших проектах после перехода (и вычистки всех UB;) прирост скорости был 15%-30% (а местами до 50%) по performance-тестам.
Есть люди, которые компилят на других версиях, в том числе и на clang, но пока официально не поддерживается. Можете прислать фикс :)
Вообще, сейчас речь про перфоманс особо не стоит, сделать бы чтобы оно просто стабильно работало.
O3 не имеет столь значимых преимуществ по сравнению с O2
Это не совсем так, например с O3 вы намного реже получите branch misprediction, просто потому, что компилятор создаст меньше условных переходов.
Про стабильность, согласен (но только пока все-то не вычищено).
Вы ведь всё равно хукаете все виндосовские вызовы по умолчанию, так почему бы не сделать и песочницу — по умолчанию?
www.bountysource.com/teams/reactos
ReactOS стал самодостаточным в год своего 21-летия