Debian GNU/kReactOS ?

Лучше конечно линукс но для борьбы с проприетарным софтом и такой вариант мне нравится.

Хомячки счастливы. MS в шоке.

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

На этапе «собираем репозитории» и есть главная проблема. Нужно сообщество, чтобы всё это собирало, чтобы всё тестировало, делало обновления.

Нужно предусмотреть /bin, чтобы не было C:\progra~\app1\app1.exe, а был быстрый запуск кучей способов.

Нужно неприбитые к ядру иксы.

И главное - нужно дописать KDE до рабочего состояния. Я вот сегодня даже в Debian попробовал 4.7.2 и 4.7.4 - не работает вообще практически ничего, как надо :(

.

Уж проще сделать это расширением ядра для Linux, чтобы можно было win-приложения и win-драйвера гонять свободно, а всё остальное оставить, как есть. Ну а репозиторий для windows с регулярными обновлениями и без проблем «сто тыщ библиотек zlib1g.dll, а нужной нет» ты можешь уже прямо сейчас собирать, и на совместимость с wine тестировать.

Патенты не везде действуют.

Debian GNU/kReactOS ?

Вот-вот, ядро от ReactOS, а всё остальное от полноценного Debian.

Бред. Но мне нравится .

[несмешная взвесь поскипана]
Допустим они создадут рабочее ядро и стек системных библиотек

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

Это было бы замечательно: всякие бубунтоводы перестали бы ломать линукс и переключились на реактос.

Не беспокойся, они тем не менее, достаточно широко действуют, чтобы сильно осложнить авторам и пользователям(!) жизнь, кроме того наверняка найдут к чему еще придраться, может быть даже к названию WinAPI функций, нарушению правил пользования MSDN и еще к чему-то что и в голову не прийдет. Это если вдруг ReactOS составит реальную конкуренцию.

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

Не знаю, тут даже защитники для Linux что-то слабо находятся, не без них, но например, MS даже с Red Hat таки какие-то мутные соглашения заключает, я уж не говорю про обкладывание данью производителей Android-устройств.

Какие мутные? Что-то конкретно не нравится или опять смутное недовольство «Они продались!»? MS исторически любит подбирать, что плохо лежит, как свое (переизобретать «стандарты») и притеснять тех, кого легче притеснить. Таким каким он стал, мастдай стал потому, что ничем не брезговал и хорошо питался в тени гигантов своего времени (IBM и Ко). Как говорится, сириус бизнес - не покажешь зубы, съедят нахрен. Разновсякому опенсорцу в этом смысле, чтоб выжить в существующем юридическом поле^Wсаванне^Wджунглях, надо в совершенстве владеть методикой демонстрации зубов или на крайняк ядовитой окраске (язык, который понимают традиционные корпоративные хищники - «Если вы будете на нас укать... Вы заипетесь!» И намекать на SCO) Наезды на андроид - просто попытка оттянуть, не мытьем так каканьем, снижение собственной доли рынка, в лучших традициях сириус-бизнеса - не маркетинговыми (когда get the fuckts не помогает) и уж точно не технологическими средствами.

Не мечтай о небесных кренделях. ReactOS умер еще до начала зачатия.

Debian GNU/Windows же. А вообще, мне нравится.

Debian GNU/NT

fix

Вирусописатели хватаются за головы.

Ведь они уже не знают куда пихать заработанные бабки, ведь в ReactOS нет UAC! Слава богам!

У кого траву берешь - поделись контактами.

Апокалипсис описан неплохо за исключением одного «но»: правильно писать не «MS в шоке», а «Разработчики каждого дистрибутива в рамках судебного предписания отчисляют MS по $20 за каждую скачанную копию ReactOS.»

А если срьезно, то я джва года жду ReactOS, но, видимо, не дождусь никогда.

Организации в срочном порядке переводят свои windows-машины
на реактос, ибо 1Сы, фотошопы и автокады работают без проблем.

Ради сэкономленных 3-5 тыс руб?

Нужно предусмотреть /bin, чтобы не было C:\progra~\app1\app1.exe, а был быстрый запуск кучей способов.

Нужно неприбитые к ядру иксы.

и получим линукс :)

А нужна винда.

Допустим

Ехал допустим через реку
Видит допустим в реке допустим
Cунул допустим допустим в допустим
Допустим допустим допустим допустим

Они строят классический велосипед классического (на данный момент) оффтопика. Когда они его достроят, нужно будет

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

На выходе получается система на устаревшем ядре оффтопика, часть виндовых приложений не работает из-за хаков, которые использовали при разработке. Часть приложений портирована с линукса, консольные работают в цигвине. Новые виндовые приложения не работают (т.к. требуют vista/7/8).

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

Единственный положительный момент: замена не поддерживаемой XP. Но он на руку win-программистам, и микрософту, которым теперь можно не делать портирование/обратную совместимость.

Уж проще сделать это расширением ядра для Linux, чтобы можно было win-приложения и win-драйвера гонять свободно, а всё остальное оставить, как есть.

Это будет уже не ReactOS. Я с год назад высказывал мысли о необходимости подобного. Можно даже, чтобы параллельно крутилось два ядра (тогда работы должно быть меньше).

Вирусописатели хватаются за головы.

От чего же?

Пролистал тебя немного, ты вроде бы пописываешь, вот объясни мне, дремучему, почему до сих пор никто не создал такой универсальный БолгенОС, чтобы в нем программы из любых других ОСей запускались? Эдакую платформу из кучи Вайнов. Было бы удобно, мне кажется.

Нужно неприбитые к ядру иксы.

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

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

А какие у нас есть «любые другие» системы на десктопе? Только винда да линукс. Макось еще, но она всегда особняком стояла, не думаю, что у кого-то в здравом уме появится потребность запускать вне макоси бинарники оттуда.

Если рассматривать не эмуляцию, а нативный запуск, то:

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

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

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

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

А какие у нас есть «любые другие» системы на десктопе?

Линукс, БСД, Винда, Макось, остальные Юниксы, всякие усопшие системы для некрофилов (Амига, Беос), КьюЭнЭкс, Андроид, ВинМобайл, почему нет? Все в одной коробке, не обязательно эмулировать только десктопные ОСи.

Запуск виндовых программ в линуксе обеспечивается вайном.

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

Короче, я правильно понимаю, что основное аргумент это «потому что не нужно»? Он весомый, не спорю.

А что насчёт того, что не надо тянуть всё в ядро? Я понимаю драйвера, без которых система собственно функционировать нормально не может (например, при отказе драйвера жёсткого диска нет ничего плохого в том, что ложится вся система - всё равно перезагрузить этот драйвер уже не получится из-за отсутствия доступа к системному разделу). Но оконная подсистема является достаточно второстепенной по отношению ко всей системе и её перезапуск всегда возможен (если только этот сбой именно в ней, а не в видео-драйвере). Поэтому и надо её вынести подальше от ядра, чтобы она отдельно рушалась, но всю систему не валила. Это положительно скажется как на стабильности системы, так и на быстродействии и безопасности (эксплойт в юзерспейсе может только то, что может приложение, в которое он внедрился. Экспойт в пространстве ядра может всё).

Линукс

Ну вот его и берем за основу. И смотрим:

БСД

И какие приложений есть под БСД, которых нет под линукс?

Винда

Вайн пилят.

Макось

Нет практической необходимости.

остальные Юниксы, всякие усопшие системы для некрофилов (Амига, Беос)

Ну это уже не просто отсутствие необходимости, это извращение какое-то.

КьюЭнЭкс

Аналогично.

Андроид, ВинМобайл

Да, это было бы полезно, возможно.

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

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

Короче, я правильно понимаю, что основное аргумент это «потому что не нужно»? Он весомый, не спорю.

Потому что некому. А некому, потому что ненужно.

Под повышением быстродействия я имею ввиду, что ядро будет меньше весить и быстрее грузиться.

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

А если мы не с диска грузились? А если у нас рамдиск корнем? Или tmpfs? Или корень обслуживается другим контроллером с другим драйвером? Будет последователен — выносить драйвера, так все. :)

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

И какие приложений есть под БСД, которых нет под линукс?

Бздю в глаза не видел, но м.б. там есть что-то уникальное?

Винда

Вайн пилят.

С этим неплохо, да.

Макось

Нет практической необходимости.

Цель в самой возможности, наверняка есть те, кто хочет запускать ЭксКод в Линуксе.

остальные Юниксы, всякие усопшие системы для некрофилов (Амига, Беос)

Ну это уже не просто отсутствие необходимости, это извращение какое-то.

Каким-нибудь спецам теоретически может пригодиться как минимум софт из Юниксов.

КьюЭнЭкс

Аналогично.

Тоже для спецов.

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

Вроде бы и Вайн есть какой-то крутой специально для МСО и 1С. Этерсофт или как-то так, я вопросом не интересовался.

Потому что некому. А некому, потому что ненужно.

Жаль, не тратятся достаточные силы и средства на новые решения, так и сидим на винтелах. Это обобщенно, моя идея может и бредовая.

Батька не одобрит и MS начнет троллить патентами

Драйвера работают, подсистема winapi работает.

Дальше что. Берем эту базовую систему. Ставим туда пакетный менеджер. Вроде ж были какие-то попытки прикрутить сбоку к виндам управление пакетами... Ну не суть, пакетный менеджер — не сложный софт, какой-нибудь портируют с линукса, если что

...потом написать нормальную POSIX-подсистему, и портировать ничего не надо. Будет Wine наоборот :)

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

Пока что к самым существенным потерям отзывчивости приводит использование на десктопной системе серверного планировщика, баги в драйверах (например, эпичный баг FF на nvidia, когда при рендеринге масштабированной картинки в системе даже звук заикается) и просто кривая архитектура приложений, чьи авторы не слышали о fork или многопоточности. На фоне всего этого вопрос о снижении производительности микроядерной системы как-то меркнет. Особенно если вспомнить о микроядерных RTOS-ах.

Во-первых, к тому времени, как реактивные сделают более-менее работоспособную копию XP, большинство софта уже будет с ним несовместимо. И MS такое движение будет только поошрять.

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

Ну, и в-третьих, — юристы, СШП, идиотская патентная система. Как только реактосом можно будет пользоваться, пользоваться им станет можно разве что в Китае.

Засудят их и все.

поошрять

Поощрять же.

кривая архитектура приложений, чьи авторы не слышали о fork или многопоточности

Дело не в кривой архитектуре приложений и аффтарах, которые чего-то там не слышали, а в цене форка в системе при помощи API CreateProcess, создатели которого ничего подобного fork() не имели в виду. А насчет многопоточности, как бэ единицей квантования кое-где является не процесс, а поток, так что про «не слышали» - это уж совсем толсто. (Или ты про какую систему?)

Или ты про какую систему?

Подумай.

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

репы не нужны - соберут дистр 1С и Инфраресурс. На 2 DVD всё влезет.

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

Ну если в линуксе и про форк не знают... Разве что это какие-то альтернативные программисты - с другой стороны, если они знают про потоки, могут обосновать, что форк им «не нужен» :)

Lindows же!

релоадед

Линукс, БСД, Винда, Макось, остальные Юниксы, всякие усопшие системы для некрофилов (Амига, Беос), КьюЭнЭкс, Андроид, ВинМобайл, почему нет?

Забыл Haiku и Minix3 :)