Это невозможно по причинам, перечисленным выше. В первую очередь - по юридическим и лицензионным ограничениям.
Создать клон ядра Винды, чтоб без изменений работали её драйверы -- да, пожалуй, нельзя по этим самым причинам.
Однако технически ничто не мешает сделать нормальную драйверную модель в своём собственном ядре (даже если она будет на 95% совпадать с драйверной моделью Винды) и не ломать её, а лишь расширять при возникновении необходимости. Но разработчики Линуха именно что ломают внутриядерные механизмы каждую большую версию, из-за чего старые драйверы регулярно оказываются непригодными для новых версий ядра -- т.е. нельзя взять доступный исходник старого драйвера и просто его перекомпилировать под новую версию, его нужно переписывать (а вот полностью корректно написанный драйвер для Вынь-2000 с очень большой вероятностью удастся заставить работать в Вынь-11, просто перекомпилировав его с новой версией DDK; важнейшим исключением являются драйверы видюх -- но тут, по крайней мере, была реальная причина для того, чтоб сломать драйверную модель -- она была кардинально переработана при переходе к Висте, чтобы поддерживать все возможности новых GPU и позволить их развивать дальше).
В общем, идеология Линуха порочна в самом своём корне, остальное -- следствие.
Они её режут. Например, выпустили вынь-8, которая заточена под планшеты и т.п. технику и малопригодна для серьёзной работы на обычном настольном ПК, т.е. как раз там, где подавляющая масса пользователей Винды и сидит, -- из-за чего в 10-ке пришлось многое откатывать назад. Изменения в 11-й тоже весьма, скажем так, сомнительны.
Проблема в том, что "эффективным менеджерам" достаточно получить прибыль здесь и сейчас, чтоб отчитаться перед акционерами и получить премии -- ну а что будет с компанией завтра, их абсолютно не волнует, они просто перейдут в другую компанию, и так далее. Именно подобные руководители компании и гробит, причём в любой области (см., например, на страдания Боинга).
в чём был успех Windows и почему Linux никогда не вытеснит Windows
Никогда не говори никогда (с)
А если серьёзно, руководство МС уже лет 15 делает всё, чтоб убить Винду и заставить пользователей уйти с неё (а, кроме Линуха, уходить некуда). Просто Винда -- уж очень фундаментальный продукт, его так просто, как, например, Скайп, не убьёшь. Собсно, с отходом БГ от руководства компанией это и началось.
Ну, мэйнфреймы IBM были анонсированы в 1964 году, первые модели пошли в продажу в 1965-м -- и их потомки выпускаются до сих пор. Так что да, говорит: переносимость ПО -- очень важная вещь.
Разница между 386DX и 386SX -- в ширине внешней шины данных: 32 бита у DX и 16 бит у SX (вдобавок, у SX и шина адреса обрезана до 24 бит; по сути, "с внешней точки зрения" это быстрый 80286 -- хотя внутри это уже 80386).
У настоящих ЕС ЭВМ (которые мэйнфреймы, а не ублюдские персоналки) ещё в первой половине 70-х многослойки были (первой такой была ЕС-1050 -- точней, её процессор; периферии многослойки не требовались, там обычные двухсторонние). Тогда это хайтеком ещё было, но к середине 80-х не было даже у нас.
Можно ещё вспомнить, что достаточно продвинутые контроллеры и карты умеют работать на намного больших частотах (кажется, 200 МГц могут поддерживать). Правда, там уже нужны преобразователи уровней, поскольку высокие частоты не на 3,3, а на 1,8.
Не для 8080 (который 8-разрядный), а для 8086/8088, тогда уже. И не изобретён: сам порядок байтов LE к тому времени уже достаточно длительное время использовался. Оптимизацию под него придумали -- это вполне возможно и разумно, но не более того.
С популярностью тоже есть вопросы. В частности, до массового распространения IBM PC и его клонов, самой популярной архитектурой, получившей широчайшее распространение, тоже была LE -- в виде PDP-11. Тот же ARM возник не шибко позже появления IBM PC -- в 1984-м, если память не изменяет, и основным вариантом был LE. Ну и т.д. и т.п. Так что не думаю, что именно ПК от IBM в одиночку сыграли роль в доминировании именно LE -- но определённо сыграли такую роль для многих современных ИТшников, считающих этот порядок "единственно верным".
А если длинная арифметика с числами переменной длины, то в BE - вообще вешалки...
Абсолютно никаких проблем, поскольку такая арифметика реализуется не чисто аппаратными средствами, а чисто программными, и абсолютно ничто не мешает именно для таких чисел хранить байты в порядке "младший-старший" -- всё равно их интерпретацию (как чисел переменной длины) осуществляет программа, а не процессор (для которого таких чисел попросту нет -- если не рассматривать весьма специфические случаи вроде десятичных чисел на мэйнфреймах IBM).
BE столь же логичен. И вообще, нет никакой реальной разницы, дело лишь в привычке. Я в своё время с лёгкостью переходил от СМ ЭВМ (PDP-11) с LE и восьмеричной системой на ЕС ЭВМ (System/370) с BE и шестнадцатеричной системой и обратно -- вообще никаких проблем не испытывал.
Ну так у Линуха сейчас доля рынка во всяких промышленных компьютерах и прочих Малинках близка к 100% -- примерно как у Винды на обычных ПК. А соответственно, его разработчикам давно уже не требуется заботиться о поддержке каждого чиха того или иного процессора. Хочет сообщество RISC-V полноценной поддержки в Линухе -- пускай само пишет все необходимые драйверы и т.д. и т.п., опираясь на исходники обычного "стандартного" ядра. Ну а не сделает этого -- у них не будет шансов на успешную конкуренцию с, скажем, ARM, за исключением микроконтроллерного сегмента, где Линуху просто не место -- там либо голое железо, либо недосистемы вроде FreeRTOS.
Вообще, MS не разрабатывает дрова видюх и другой сложной периферии, которая плохо стандартизирована (или вообще никак не стандартизирована) -- и ничё, живут как-то. Кроме того, сейчас у разработчика некоего процессора стоит вопрос: либо он обеспечивает совместимость с Линухом, а значит, предоставляет необходимые драйверы, либо уже он, а не Линух, идёт куда подальше.
Вот с этим я, в общем и целом, соглашусь. Но, как по мне, достаточно внедрить в Линух поддержку лишь определённого подмножества всех возможных вариантов сей архитектуры.
Очевидно, например, что никакой "настоящий" Уних, а значит, и Линух невозможен без виртуальной памяти, что требует наличия MMU -- т.е. микроконтроллеры сразу идут лесом (как это имеет место и на, скажем, ARM: Линух работает на архитектурах ARMv7-A, 8-A, 9-A, но никак не на -R или -M -- на них бывают лишь нестандартные "огрызки" типа ucLinux). Соответственно, это прописывается как безусловное требование к поддержке.
То же самое можно сказать и относительно набора команд: вполне разумно требовать наличия тех расширений, без которых невозможна эффективная реализация ядра ОС (скажем, связанных с семафорами, барьерами и прочим для многопроцессорных систем), но глупо объявлять обязательными расширения для всяких там нейросетей и прочие специализированные прикладные фишки.
Периферия -- это драйверы, а соответственно, забота не команды, занимающейся собственно Линухом (ядром), а производителей процессоров, содержащих эту периферию.
Регистры же... Не думаю, что там будет 100500 вариантов -- скорей, всё сведётся к всего нескольким дефайнам для условной трансляции модулей, отвечающих за поддержку архитектуры и абсолютно никак не будет влиять на ядро в целом. Но это надо погружаться в тему, чтоб сказать наверняка.
Порядок "младший-старший" был реализован, как минимум, ещё в PDP-11 -- а это 1969-й год, т.е. существенно раньше, чем появился 8086. Что касается порядка "старший-младший", то он возник одновременно с делением машинного слова на байты -- в IBM System/360, 1964 год. Так что всё это возникло совершенно без участия Интел и без всякой оглядки на подобные оптимизации.
Периферия к архитектуре процессора относится вообще чуть более чем никак: один и тот же периферийный контроллер можно прикрутить (либо вообще без переделок, либо с минимальными переделками) и к ARM, и к MIPS, и к RISC-V, и даже к IA-32/AMD64, особняком стоят только IBMовские мэйнфреймы (z/Architecture) из-за принципиально иной организации ввода-вывода.
Насчёт кучи вариантов поддержки тех или иных расширений... По большому счёту, ядру нужно лишь знать про то, какие регистры процессора надо сохранять/восстанавливать при переключении процессов/потоков/задач, как устроено MMU и ряд подобных вещей; ему вовсе не требуется знать про наличие/отсутствие расширений системы команд, прямо не влияющих на набор регистров (это разработчикам компиляторов это нужно знать и учитывать, чтобы генерировать код, наиболее оптимальный для конкретного процессора). Все такие вещи являются зависящими от архитектуры и реализуются специфичными для неё модулями, которые не должны сколько-нибудь "стратегически" влиять на код ОС в целом.
Ну так низкое качество кода -- не повод отказываться от поддержки чего-то там. Если на то пошло, само ядро Линуха, как и любой крупный проект, -- тоже та ещё свалка дерьма (а иначе они бы не ломали в каждой большой версии совместимость с драйверами из более ранних версий).
"8 байт числа memcpy-нули в unsigned long для удобства работы" (недавно такое разбирал из 1994 года)
Нельзя слегка поподробнее? Ну или ссылку, где сие описано. Просто интересно знать, что за проблема такая всплыла.
Создать клон ядра Винды, чтоб без изменений работали её драйверы -- да, пожалуй, нельзя по этим самым причинам.
Однако технически ничто не мешает сделать нормальную драйверную модель в своём собственном ядре (даже если она будет на 95% совпадать с драйверной моделью Винды) и не ломать её, а лишь расширять при возникновении необходимости. Но разработчики Линуха именно что ломают внутриядерные механизмы каждую большую версию, из-за чего старые драйверы регулярно оказываются непригодными для новых версий ядра -- т.е. нельзя взять доступный исходник старого драйвера и просто его перекомпилировать под новую версию, его нужно переписывать (а вот полностью корректно написанный драйвер для Вынь-2000 с очень большой вероятностью удастся заставить работать в Вынь-11, просто перекомпилировав его с новой версией DDK; важнейшим исключением являются драйверы видюх -- но тут, по крайней мере, была реальная причина для того, чтоб сломать драйверную модель -- она была кардинально переработана при переходе к Висте, чтобы поддерживать все возможности новых GPU и позволить их развивать дальше).
В общем, идеология Линуха порочна в самом своём корне, остальное -- следствие.
Они её режут. Например, выпустили вынь-8, которая заточена под планшеты и т.п. технику и малопригодна для серьёзной работы на обычном настольном ПК, т.е. как раз там, где подавляющая масса пользователей Винды и сидит, -- из-за чего в 10-ке пришлось многое откатывать назад. Изменения в 11-й тоже весьма, скажем так, сомнительны.
Проблема в том, что "эффективным менеджерам" достаточно получить прибыль здесь и сейчас, чтоб отчитаться перед акционерами и получить премии -- ну а что будет с компанией завтра, их абсолютно не волнует, они просто перейдут в другую компанию, и так далее. Именно подобные руководители компании и гробит, причём в любой области (см., например, на страдания Боинга).
Никогда не говори никогда (с)
А если серьёзно, руководство МС уже лет 15 делает всё, чтоб убить Винду и заставить пользователей уйти с неё (а, кроме Линуха, уходить некуда). Просто Винда -- уж очень фундаментальный продукт, его так просто, как, например, Скайп, не убьёшь. Собсно, с отходом БГ от руководства компанией это и началось.
Ну, мэйнфреймы IBM были анонсированы в 1964 году, первые модели пошли в продажу в 1965-м -- и их потомки выпускаются до сих пор. Так что да, говорит: переносимость ПО -- очень важная вещь.
Разница между 386DX и 386SX -- в ширине внешней шины данных: 32 бита у DX и 16 бит у SX (вдобавок, у SX и шина адреса обрезана до 24 бит; по сути, "с внешней точки зрения" это быстрый 80286 -- хотя внутри это уже 80386).
У настоящих ЕС ЭВМ (которые мэйнфреймы, а не ублюдские персоналки) ещё в первой половине 70-х многослойки были (первой такой была ЕС-1050 -- точней, её процессор; периферии многослойки не требовались, там обычные двухсторонние). Тогда это хайтеком ещё было, но к середине 80-х не было даже у нас.
Можно ещё вспомнить, что достаточно продвинутые контроллеры и карты умеют работать на намного больших частотах (кажется, 200 МГц могут поддерживать). Правда, там уже нужны преобразователи уровней, поскольку высокие частоты не на 3,3, а на 1,8.
И уж точно лучше, чем с пивасиком зависать перед зомбоящиком.
Собрать все вантузы в Фоллауте -- это святое! :)
скорей, как понос сознания...
Не для 8080 (который 8-разрядный), а для 8086/8088, тогда уже. И не изобретён: сам порядок байтов LE к тому времени уже достаточно длительное время использовался. Оптимизацию под него придумали -- это вполне возможно и разумно, но не более того.
С популярностью тоже есть вопросы. В частности, до массового распространения IBM PC и его клонов, самой популярной архитектурой, получившей широчайшее распространение, тоже была LE -- в виде PDP-11. Тот же ARM возник не шибко позже появления IBM PC -- в 1984-м, если память не изменяет, и основным вариантом был LE. Ну и т.д. и т.п. Так что не думаю, что именно ПК от IBM в одиночку сыграли роль в доминировании именно LE -- но определённо сыграли такую роль для многих современных ИТшников, считающих этот порядок "единственно верным".
Абсолютно никаких проблем, поскольку такая арифметика реализуется не чисто аппаратными средствами, а чисто программными, и абсолютно ничто не мешает именно для таких чисел хранить байты в порядке "младший-старший" -- всё равно их интерпретацию (как чисел переменной длины) осуществляет программа, а не процессор (для которого таких чисел попросту нет -- если не рассматривать весьма специфические случаи вроде десятичных чисел на мэйнфреймах IBM).
BE столь же логичен. И вообще, нет никакой реальной разницы, дело лишь в привычке. Я в своё время с лёгкостью переходил от СМ ЭВМ (PDP-11) с LE и восьмеричной системой на ЕС ЭВМ (System/370) с BE и шестнадцатеричной системой и обратно -- вообще никаких проблем не испытывал.
Ну так у Линуха сейчас доля рынка во всяких промышленных компьютерах и прочих Малинках близка к 100% -- примерно как у Винды на обычных ПК. А соответственно, его разработчикам давно уже не требуется заботиться о поддержке каждого чиха того или иного процессора. Хочет сообщество RISC-V полноценной поддержки в Линухе -- пускай само пишет все необходимые драйверы и т.д. и т.п., опираясь на исходники обычного "стандартного" ядра. Ну а не сделает этого -- у них не будет шансов на успешную конкуренцию с, скажем, ARM, за исключением микроконтроллерного сегмента, где Линуху просто не место -- там либо голое железо, либо недосистемы вроде FreeRTOS.
Вообще, MS не разрабатывает дрова видюх и другой сложной периферии, которая плохо стандартизирована (или вообще никак не стандартизирована) -- и ничё, живут как-то. Кроме того, сейчас у разработчика некоего процессора стоит вопрос: либо он обеспечивает совместимость с Линухом, а значит, предоставляет необходимые драйверы, либо уже он, а не Линух, идёт куда подальше.
Вот с этим я, в общем и целом, соглашусь. Но, как по мне, достаточно внедрить в Линух поддержку лишь определённого подмножества всех возможных вариантов сей архитектуры.
Очевидно, например, что никакой "настоящий" Уних, а значит, и Линух невозможен без виртуальной памяти, что требует наличия MMU -- т.е. микроконтроллеры сразу идут лесом (как это имеет место и на, скажем, ARM: Линух работает на архитектурах ARMv7-A, 8-A, 9-A, но никак не на -R или -M -- на них бывают лишь нестандартные "огрызки" типа ucLinux). Соответственно, это прописывается как безусловное требование к поддержке.
То же самое можно сказать и относительно набора команд: вполне разумно требовать наличия тех расширений, без которых невозможна эффективная реализация ядра ОС (скажем, связанных с семафорами, барьерами и прочим для многопроцессорных систем), но глупо объявлять обязательными расширения для всяких там нейросетей и прочие специализированные прикладные фишки.
Периферия -- это драйверы, а соответственно, забота не команды, занимающейся собственно Линухом (ядром), а производителей процессоров, содержащих эту периферию.
Регистры же... Не думаю, что там будет 100500 вариантов -- скорей, всё сведётся к всего нескольким дефайнам для условной трансляции модулей, отвечающих за поддержку архитектуры и абсолютно никак не будет влиять на ядро в целом. Но это надо погружаться в тему, чтоб сказать наверняка.
Порядок "младший-старший" был реализован, как минимум, ещё в PDP-11 -- а это 1969-й год, т.е. существенно раньше, чем появился 8086. Что касается порядка "старший-младший", то он возник одновременно с делением машинного слова на байты -- в IBM System/360, 1964 год. Так что всё это возникло совершенно без участия Интел и без всякой оглядки на подобные оптимизации.
Периферия к архитектуре процессора относится вообще чуть более чем никак: один и тот же периферийный контроллер можно прикрутить (либо вообще без переделок, либо с минимальными переделками) и к ARM, и к MIPS, и к RISC-V, и даже к IA-32/AMD64, особняком стоят только IBMовские мэйнфреймы (z/Architecture) из-за принципиально иной организации ввода-вывода.
Насчёт кучи вариантов поддержки тех или иных расширений... По большому счёту, ядру нужно лишь знать про то, какие регистры процессора надо сохранять/восстанавливать при переключении процессов/потоков/задач, как устроено MMU и ряд подобных вещей; ему вовсе не требуется знать про наличие/отсутствие расширений системы команд, прямо не влияющих на набор регистров (это разработчикам компиляторов это нужно знать и учитывать, чтобы генерировать код, наиболее оптимальный для конкретного процессора). Все такие вещи являются зависящими от архитектуры и реализуются специфичными для неё модулями, которые не должны сколько-нибудь "стратегически" влиять на код ОС в целом.
Ну так низкое качество кода -- не повод отказываться от поддержки чего-то там. Если на то пошло, само ядро Линуха, как и любой крупный проект, -- тоже та ещё свалка дерьма (а иначе они бы не ломали в каждой большой версии совместимость с драйверами из более ранних версий).
Нельзя слегка поподробнее? Ну или ссылку, где сие описано. Просто интересно знать, что за проблема такая всплыла.