Comments 185
Смотришь на иконки и оформление и ощущаешь привкус Linux на языке.
я бы предпочел более компактный вид.
Предполагаю, что часто задают этот вопрос, но все же как с поддержкой реального железа? Если пока все плохо, есть какой-то roadmap?
Почему на первом скриншоте у двух окон разные тени?
А у нижнего окна она вообще порвалась слева вверху ;(
У меня еще на 4.10(qemu) команда ping google.com выдавала ip адрес а дальше Host Unreachable
Firefox 48 работает, 52 — уже нет.
Ну как работает… Поиск в яндексе уже вешает систему.
Рискну предположить, что коли заявлен е1000, то нужно выбрать тип машины windows 7, т.к. в противном случае будет другой адаптер. Выбирать нужно при создании ВМ.
Какой версии виртуалбокс?
Этот метод запуска стал еще результативнееВот от этой фразы накатила ностальгия: ставишь Windows 95, а она на тёплом ламповом мониторе подобные рекламные сообщения крутит…
(Хотя после этого пришла и мрачная мысль: в ReactOS «еще результативнее» может значить, что раньше загрузка падала на 70%, а теперь на 90%)
Активирована поддержка выравнивания окон приложений относительно краёв экрана или раскрытия/сворачивания при перемещении окна мышью в определённых направлениях.Только сделайте, пожалуйста, возможность переопределить эти хоткеи другой программой. Я, например, раньше настраивал управление плеером на Win+Left и Win+Right, а потом Микрософт мне это обломал :(
хорошим тоном было бы завести ветку в реестре и определенную логику обработки хоткеев.
А прототипом может послужить http://www.brianapps.net/hotkeyplus/
Особенно интересует возможность запуска Kings Bounty II
Однако, если разработчикам ReactOS удастся использовать видеокарту с Vulkan API, то через трансляторы, вроде DXVK и D9VK, можно будет те же игры запустить.
хотел бы полностью отказаться от Винды заменив его на Реакт.
Добавлен свободный драйвер для сетевого адаптера Intel e1000...
А у вас не такого же только для Intel e100 из коробки? И, да, я понимаю всю абсурдность просьбы.
Но мы сами вряд ли будем этим заниматься
Там большинство глюков вызвано с несовершенством механизма управления питанием и PnP-менеджера.
Почему такой же совместимости нет для драйверов?
Есть, но пока нет. В сборки Вадима Галянта успешно тащится пачка драйверов из оригинальной Windows 2003 (список), но ещё не все изменения из его сборок доехали в апстрим
а взять уже готовые виндовые
Взять-то может и можно, и может они даже заработают, только помещать-то в сборку их всё равно нельзя по юридическим причинам
На каком уровне совместимости с WinAPI сейчас находится проект, еще Windows 98 или уже хотя бы Windows 2000 догнали? :)
Идея подарить миру «Бесплатную Windows» конечно хороша, но 100% утопична — даже чисто по человеко-часам группа энтузиастов не сможет догнать команду Microsoft в реализации всех API, обновлений и драйверов, которые появляются ежегодно. А если бы вдруг и смогли, MS задавила бы всё это юридически, как только появилась бы опасность упущенной прибыли.
Но как хобби, почему нет, авторам удачи ;) Может для каких-то старых железяк на производстве, где до сих пор древние версии винды работают, оно и пригодится даже.
MS задавила бы всё это юридически, как только появилась бы опасность упущенной прибыли
вы так говорите, будто всю жизнь занимаетесь корпоративным правом в области ПО, хотя это явно не так.
Может для каких-то старых железяк на производстве, где до сих пор древние версии винды работают, оно и пригодится даже
ядро Виндовс и системные вызовы во многом остаются совместимыми со времен первого NT, навороты именно там очень редко и мало появляются.
Даже по отзывам в этой ветке видно, что ни у кого толком ничего не работает.
Сравнение с Nintendo в данном случае некорректно. Сайт, выложив бинарные копии игр 1 к 1, грубо нарушил авторские права.
Здравствуйте, а как работает и работает ли обновление дистрибутивов внутри установленной ОС?
Что-то наподобие atp get update?
И еще вопрос — как идут досовские утилиты?
Есть ли поддержка dx9?
Просто упоминается возможность запуска приложений под из win8 и win10
Тогда что насчет стандартных майковских решений типа cx, wpf, uwp?
Поддержка dx9 без аппаратного ускорения только, через трансляцию вызовов в OpenGL.
Поддержка приложений win8/10 только если это стандартные win32 или .NET2.0/4.0 приложения, скомпилированные без сильно специфических API от новейших версий Windows.
OpenGL — надеюсь аппаратный?
Тот же вопрос про Vulkan, PhysX, CUDA, OpenAL, OpenML.
Аппаратность OpenGL зависит напрямую от конкретного драйвера конкретной видеокарты, который надо ставить отдельно. :) встроенный OpenGL по-умолчанию тоже software.
Все остальные страшные слова только в планах. Наверное Vulkan будет проще всего.
Первая ассоциация при виде заголовка: ReactOS мхом поросла.
Активирована поддержка выравнивания окон приложений относительно краёв экрана или раскрытия/сворачивания при перемещении окна мышью в определённых направлениях.
Похоже, вектор развития сменился с достижения совместимости по API, на достижение совместимости по наиболее раздражающим «фичам». Этак и до плиточного интерфейса докатитесь.
Выравнивание/прилипание окон и метро-интерфейс с метро-приложениями — очень разные и далёкие друг от друга фичи вообще-то.
если базовую поддержку мышек/клавиатур обещают добавить к версии 0.4.15 (примерно через 1год), хотя удачные опыты по их полной поддержке были уже более 1.5 — 2 года назад.
P.S. В той же KolibriOS это работает с незапамятных времён из коробки и многое другое. :)
Пока много усилий разрабов уходит на «борьбу» с регрессиями, которые «сами» же разработчики создают, а RoadMap — это как движение к линии горизонта, вроде и есть она, но не достижима.
Можно, только, пожелать разработчикам ReactOS удачи в том «хаосе» её разработки
или быть может «божественного провидения»
Возможно, внедрение в процесс разработки, каких то уже существующих моделей «ИИ» (нейронных сетей) поможет в более осмысленном развитии проекта в будущее. :)
Мышки и клавиатуры получат универсальную поддержку в версии 0.4.13, которая выйдет приблизительно через 2-3 месяца
Фото синего экрана с acer
i.imgur.com/qQf8ADA.jpg
У старого ноута привод пишущий, но диска нет. Попробую завтра поспрашивать у коллег, может у кого cd-rw завалялся.
Но это, кончно, нужно в первую очередь фиксить, я считаю. Невозможность загузаться с usb отрезает кучу людей, которые хотели бы «по-быстрому попробовать». У многих ведь уже и приводов давно нет, не то-что дисков.
Тогда есть смысл подождать до выхода 0.4.13, там эта проблема будет частично решена.
Дано: выбрана при установке по умолчанию раскладка русская, выявился вот такой баг
переключится на английскую раскладку удается только через значок в трее
Подумалось, дай-ка в настройках, установлю по умолчанию английскую раскладку и будет мне счастье. Ан нет! В трее значок показывает, что английская раскладка, а начинаешь набирать текст в поле ввода при установке программ, и оба-на, русские символы, и пофигу Ctrl+Shift. Только на значке в трее туда-сюда клац и нужная раскладка, вуаля! Но новое окно ввода и всё начинай заново.
А вот я рад за то, что ещё есть проекты которые держатся на энтузиастах, только их уже мало осталось, Haiku, kolibrios, reactos и хотелось бы побольше, я надеюсь что эту систему когда нибудь уже допилят до состояния что ее можно будет пользовать на повседневку.
Однако, TRIM в ReactOS пока не поддерживается. Но это не фатально.
Но ведь без TRIM диск не знает, что эти 30% свободного пространства действительно свободны, не?
interface31.ru/tech_it/2015/04/mozhno-li-effektivno-ispolzovat-ssd-bez-podderzhki-trim.html
Собственно, в этой же статье сказано про всего 6-7% резервной области, что далеко от желаемых 30%. Поэтому я как-то не уверен, что без TRIM износ ячеек не будет повышенным независимо от контроллера
Диски дохли от того, что данные писались в некоторые яичейки чаще, чем в другие, или даже несколько раз подряд в одну и ту же. Эффект усиливался, если ОС постоянно теребила на запись один и тот же служебный файл. Теперь контроллеры постоянно (и независимо от наличия TRIM) пишут данные каждый раз в другую яичейку. Это механизм выравнивания износа.
TRIM помогает диску узнать об освобождающихся областях одновременно с файловой системой, а не тогда, когда от файловой системы придет прямое указание на стирание какой-то области, потому что нам уже сейчас нужно туда писать.
В этом у SSD принципиальная разница с HDD: на SSD нужно дополнительное время на стирание, а на HDD — нет. Поэтому SSD пытается стирать заранее, в минуты простоя, получая информацию от TRIM.
Ну так а защита от физической деградации откуда берётся-то?
Вместо внятного ответа — минус в карму. Вот так на Хабре конструктивные диалоги ведут.
Оказывается, ответ на мой вопрос был написан путём редактирования комментария выше вместо того, чтобы добавить новый ответ ниже. Вот так на Хабре тайм-парадоксы ведут.
Редактирование комментария после того, как на него ответили, должно быть запрещено.
Редактировать комментарий после того, как на него ответили — некрасиво и создаёт тайм-парадоксы.
Теперь контроллеры постоянно (и независимо от наличия TRIM) пишут данные каждый раз в другую яичейку.
Так ведь "других ячеек" нет, все ячейки же заняты (кроме резерва).
Если прям все занято, то вам файловая система скажет «стопэ, тут некуда писать». Но как правило на диске всегда есть хотя бы парочка свободных секторов, о которых контроллер точно знает. Туда он и будет писать методом Copy-on-write. И зона записи все время будет сдвигаться. Просто это будет не очень быстро в плане производительности. Всего 512 килобайт свободного места достадочно для работы механизма выравнивания. И в крайнем случае их контроллер всегда может занять в резервной зоне
Я не редактировал свое сообщение после появления вашего комментария.
Редактировали. Возможно, вы этого просто не заметили, потому что не обновляли комментарии перед редактированием, и никакого злого умысла не имели, но — редактировали. Когда я писал свой комментарий с вопросом, ваш комментарий состоял из одного предложения.
Если прям все занято, то вам файловая система скажет «стопэ, тут некуда писать».
Нет, потому что свободные блоки свободны только с точки зрения файловой системы, но диск без TRIM никак не может знать, что эти блоки не используются файловой системой, если в них записывали хотя бы один раз — в ячейках, связанных с этими блоками, будут продолжаться бережно храниться все удалённые файлы.
Всего 512 килобайт свободного места достадочно для работы механизма выравнивания.
То есть держать 30% свободного места уже необязательно?
Туда он и будет писать методом Copy-on-write.
Но так как других свободных ячеек нет (почему — см. выше) — эти «парочка свободных секторов» быстренько сломаются первыми из-за постоянной перезаписи. Что я упускаю в своих рассуждениях?
Всего 512 килобайт свободного места достадочно для работы механизма выравнивания.
То есть держать 30% свободного места уже необязательно?
Без 30% свободного места выравнивание износа будет работать, но все будет очень медленно.
эти «парочка свободных секторов» быстренько сломаются первыми
Не сломаются. Килобайт свободного места будет мигрировать по всему диску.
Килобайт свободного места будет мигрировать по всему диску.
Для того, чтобы этот килобайт свободного места смигрировать в новую ячейку и затем записать туда новые данные, старое содержимое новой ячейки нужно куда-то переместить — то есть записать в другую свободную ячейку. Таким образом получаем (условно) двойную нагрузку на запись (на перемещение старого и на запись нового) и, как следствие, снова повышенный износ. Что я опять упускаю в своих рассуждениях?
2. А если его даже свободного места и нет совсем, диск возьмет взаймы 512 килобайт из резервной зоны.
Не будет никакой двойной нагрузки. Еще раз повторю, поиграйте в «пятнашки». И почитайте про механизм copy-on-write.
В условиях задачи у нас уже есть 512 килобайт свободного места.
Ну раз вы не понимаете логику моих рассуждений, давайте по шагам.
1) Забиваем место под завязку и оставляем свободной ровно одну ячейку (для простоты рассуждений предположим, что все ячейки из резерва уже неисправны или их просто нет).
2) Из ОС поступает запрос на перезапись существующего файла размером в одну ячейку.
3) Чтобы уменьшить износ, диск записывает данные в свободную ячейку, а старую ячейку от файла начинает считать свободной.
4) Из ОС снова поступает запрос на перезапись того же файла.
5) Чтобы уменьшить износ, диск по вашей логике выполняет миграцию свободной ячейки:
5.1) берёт какую-то третью занятую ячейку, перемещает из неё данные в старую свободную ячейку (запись раз)
5.2) и записывает в эту третью ячейку новые данные файла (запись два)
5.3) а старую ячейку, в которой хранились старые данные файла, начинает считать свободной.
6) Повторяем пункты 4-5.3 до израсходования ресурса.
В каком пункте/пунктах я ошибся и как мне избавиться от двойной записи в своих рассуждениях?
Про copy-on-write я прекрасно знаю и это здесь неприменимо, а аналогия с пятнашками некорректна.
В ситуации с полностью забитым под завязку диском TRIM не поможет вообще никак. Даже ускорения никакого не даст. Эта функция заранее сообщает диску об освобождающихся областях, а когда их почти нет, ей и сообщать не о чем.
При использовании современного диска без TRIM его износ никак не изменится относительно такого же диска с включенным TRIM. Будут только скоростные характеристики плавать.
TRIM не оказывает значимого влияния на износ современных дисков
Вы утверждали это уже неоднократно, но подтверждений этому утверждению я так и не увидел ни в одном вашем комментарии.
а только позволяет сохранить диску его скоростные характеристики
Почему «только»? Объясните, пожалуйста.
В ситуации с полностью забитым под завязку диском TRIM не поможет вообще никак.
Я рассматриваю ситуацию при отсутствующем TRIM, когда диск считает себя занятым, даже если в файловой системе 99% свободного места. В этом случае включение TRIM как раз очень сильно поможет, потому что диск узнает, что он свободный, и сможет использовать ячейки как ему угодно ради уменьшения износа. Что я упускаю в своих рассуждениях, вы так и не рассказали.
Работа механизма выравнивания износа продлевает жизнь накопителю равномерно используя для записи все ячейки диска по очереди.
Работа механизма выравнивания не проходит бесплатно, требует дополнительных затрат со стороны контроллера SSD, вызывая снижение производительности диска при определенных условиях.
Чтоб были
TRIM заранее информирует диск о том, какие сектора больше не содержат данных по мнению файловой систем, до того как ему ОС прямо скажет «стирай, сука, я сейчас сюда писать буду».
В результате SSD диск успевает спланировать и провести свои мероприятия по Wear leveling без заметной потери производительности.
Я это всё прекрасно знаю, и это никак не противоречит тому, что я писал выше. При наличии TRIM механизм выравнивания износа может избегать двойной записи за счёт более частого переиспользования свободных ячеек, а без TRIM — не может, потому что свободных ячеек мало и приходится мигрировать в занятые ячейки (по вашей же логике), так что без TRIM не только падает производительность, но и (предположительно) повышается износ из-за двойной записи. Вопрос всё тот же: что я упускаю в своих рассуждениях?
Но как оно в реальности работает гадать бестолку и не расскажет никто…
Правильный WL должен изнашивать ячейки равномерно, т.е. производить «двойную запись» даже когда есть куча свободного места. См. static wear leveling.
Да, но если свободного места много (привет от TRIM), то они используются в среднем чаще, «двойных записей» становится в среднем меньше и в итоге износ тоже меньше, не? В первом приближении такие рассуждения вроде бы и со static wear leveling могут работать
Но как оно в реальности работает гадать бестолку и не расскажет никто…
Кажется, это было бы самым разумным завершением разговора)
Можно 30% просто не размечать, будут тогда всегда свободными.
Да, я на своём SSD так и сделал.
ОС постоянно трёт своп
Поэтому я не держу своп на SSD) Но БД браузера держу, чтоб не тормозил.
этих 6-7% резерва по идее должно хватать
Всё же у меня по-прежнему есть опасение, что если предположить вырожденный случай с постоянной перезаписью одного и того же файла, то будут постоянно перезаписываться эти самые 6-7% резерва за неимением других ячеек — они первые и сломаются из-за постоянной перезаписи. А с TRIM (ну и с неразмеченными 30%, да) у контроллера вроде бы должно быть побольше свободы выбора, какие ячейки в каком порядке изнашивать (по моим предположениям о принципах работы SSD).
Вывод сделанный лично для себя, а возможно годный кому-то ещё,- выносить своп, папки темп и т.д. для мифической экономии ресурса SSD, затея НЕ нужная, а в контексте падения производительности и ВРЕДНАЯ! С учетом того факта, что настоящая система морально устареет, значительно раньше чем будет выработан ресурс диска.
Моему SSD четыре года, работает круглосуточно, согласно smartctl ресурс выработан на 40%. Боюсь, если бы я не вынес своп, ресурс уже кончился бы)
Я оставил 10ГБ неразмеченными (диск в целом 120ГБ), а основной системный раздел работает с TRIM и свободное место варьируется от половины до нуля в зависимости от того, что мне приспичит установить
Вот, например, andiriney.ru/testirovanie-ssd-na-vynoslivost
Резервировать место смысл явно есть, раз это даже штатная функция в самсунговской утилите.
А жить без трима по видимому можно, но наверно стоит брать накопитель пофирмовее.
Есть так же Cinnamon и Mate, их активно используют в Linux Mint, не говоря о куче различных других оболочках для энтузиастов.
Веду к тому что выбора достаточно, и нет смысла плодить новые сущности.
Учитывая огромное количество софта на Win32, а так же старых драйверов, которое до сих пор в ходу, смысл в существовании ReactOS есть, и наверное будет ещё долго. Wine не панацея, но не поможет решить вопрос отсутствия драйверов, но с другой стороны обмен наработками между ним и React'ом выгодно всем, и это здорово.
Учитывая огромное количество софта на Win32, а так же старых драйверов, которое до сих пор в ходу,
Попробую девятый фотошоп установить на ОС в виртуалке!
Судя по скриншоту товарища ниже в комментариях, он по-моему пытается с сетевого диска запустить.
Слишком просто запускать .exe на Линукс т.е.?
Наверное, но к чему это вот сообщение тогда, или это такой юмор?
И «бездействие системы» периодически жрет все ресурсы ЦП
В мастер ветке эту проблему с запуском программ из сетевых шар (в том числе из общих папок) исправили кстати.
Слежу за проектом лет 15 как и сегодня наконец-то решил поэкспериментировать с железом. Не умеет грузиться с флэшэк — ладно: есть двдшник и сидишная болванка. Записал, ребут. Попробовал в режиме лив сиди — облом: не видится ни юсб клава, ни юсб мышь. Ладно, думаю, попробую бут сиди. Дошёл до выбора языка и всё: опять таки не видится ни клава ни мышь. Искать для этого пиэс2 устройства не буду. Ребята, ну так же нельзя в самом деле. У меня не было таких проблем ни с линуксом, ни даже с Хайку и OS/2. Решите, пожалуйста сперва первостепенные задачи, а потом уже как-то пиарьтесь. Конфигурация моего компа более стандартная, без изысков: Коре и3 2100, 16 гиг оперативы, ГеФорсе 1050ТИ, ничего особенного. Клава-мышь — стандартные юсб а4тех. Наверное до встречи ещё через… 15 лет. :-(
Добрый день!
Не буду вдаваться в долгие объяснения, просто попрошу скачать свежую ночную сборку отсюда https://reactos.org/getbuilds/ и попробовать сделать ровно тот же самый эксперимент, который только что закончился неудачей.
По поводу 4ТБ диска, было бы неплохо потестить когда мы перейдём на новый стек storage драйверов
Пока что оно от ливсиди сугубо отрицательное.
Он предназначен больше для быстрого тестирования возможности запуска на железе, если установить туда возможности нет (например, не хочется переносить данные), и для реанимационных мероприятий.
Сетевуха тоже не видна.
Без драйвера, это нормальная ситуация. Будет драйвер — будет работать. :) Драйвер можно подкинуть в iso файл.
Не запускается ни одно 32 разрядное приложение для винды, ни АИМП, ни Миранда: все ругаются на отсутствие майкрософтовских длл библиотек + «инструкция по адресу...».
Библиотеки, при наличии интернета, очень легко можно поставить из менеджера RAPPS, который находится в «Пуске». Там есть все нужные библиотеки. Только для этого нужна устанавливаемая версия, а не LiveCD.
А что насчёт 64 битной сборки, когда планируется начать её АКТИВНО разрабатывать?
А что насчёт 64 битной сборки, когда планируется начать её АКТИВНО разрабатывать?
github.com/reactos/reactos/pull/83
github.com/reactos/reactos/pull/82
github.com/reactos/reactos/pull/200
github.com/reactos/reactos/pull/256
github.com/reactos/reactos/pull/268
github.com/reactos/reactos/pull/335
github.com/reactos/reactos/pull/337
github.com/reactos/reactos/pull/420
github.com/reactos/reactos/pull/465
github.com/reactos/reactos/pull/783
github.com/reactos/reactos/pull/516
github.com/reactos/reactos/pull/757
github.com/reactos/reactos/pull/894
github.com/reactos/reactos/pull/1158
github.com/reactos/reactos/pull/1157
github.com/reactos/reactos/pull/1160
github.com/reactos/reactos/pull/1172
github.com/reactos/reactos/pull/1173
github.com/reactos/reactos/pull/1262
github.com/reactos/reactos/pull/1263
Еще, почему не работает (и тут, и раньше) самописная программа на Си, юзающая WMI (через СОМ, на вин2к работает). Просто ради теста запускал разные ехе, и вот этот упал.
Для начала нужен отладочный лог в момент глюка, полученный через ком-порт
Можно с виртуалки.
Ну то есть это не чья-то очередная недоделка, какого-то одиночки, а целый международный проект ведь, кем он финансируется, для кого\чего существует?
Ведь у всего должна быть цель, или нет?
Заранее спасибо за ответы.
А еще выбор толщины линии — не меняет рисуемую толщину линий, рисуется все равно 1 пиксельной толщиной. Получается Delphi 7 рисует линии на растре через что-то, что в react os не слушается указываемой толщины.
Надо будет попробовать снова на ноут поставить. Раньше все попытки установки react os на старые ноуты типа старого Samsung N310 и некоторых других — заканчивались неудачей. Может быть в этой новой версии все эти проблемы с установкой решились.
Интересный скриншот :)
Для опытов с реальным железом рекомендую релиз-кандидаты 0.4.13, они уже лежат на саурсфордже.
ReactOS 0.4.12: 华为, 你认为这个怎么样?