Як ви вважаєте, керовані ОС - гарна ідея? [зачинено]


15

Керовані ОС, такі як Microsoft Singularity та JNode - досить цікава концепція. По суті, ОС завантажується з кодом, написаним мовою низького рівня (C / C ++ / Assembly), яка по суті реалізує віртуальну машину. Решта ОС (і всіх додатків користувача) працює на віртуальній машині. У цьому є кілька чудових речей. Наприклад, ви раптом роблять довільні вказівники застарілими. І якщо це добре написано, ви позбудетеся тонни застарілого сирого, що є у більшості сучасних ОС.

Однак, як недолік, ви настільки віддалені від обладнання, і як розробник, ви втрачаєте здатність опускатися до нижнього рівня абстрагування і бруднити руки.

Яка ваша думка з цього приводу?


Я боюся відповідати, оскільки я схильний до мов високого рівня, оскільки вони є єдиними мовами, якими я користувався
TheLQ

2
З все швидшими комп'ютерами я думаю, що це велика справа. Однак якщо MSFT реалізує це, воно буде або чудовим, або багато смокче - між ними немає ніякого проміжку.
Робота

Зауважте, що "застарілий крут" - це те, що змушує запускати існуючі програми. Не варто недооцінювати важливість того, що насправді є чим користуватися.

Відповіді:


8

Я думаю, що це ще один випадок, коли "це залежить".

Якщо ви пишете додатки, такі як веб-браузери, текстові процесори тощо, де ефективність блискавки не обов'язково є проблемою, то такий підхід має свої заслуги. Використовуючи такий підхід, ви можете запропонувати своїм клієнтам безпечніший та більш контрольований досвід. Ви не тільки обмежуєте шкоду, яку може завдати шкідливе програмне забезпечення, але ви також працюєте в більш послідовній обстановці.

Це як різниця між консольними іграми на ПК. Перші точно знають, з яким обладнанням їм потрібно працювати, тому можуть скористатися цими знаннями, тоді як другі повинні мати можливість справлятися з різноманітними відеокартами, звуковими картами, швидкістю жорсткого диска тощо.

Однак знайдуться додатки (наприклад, ігри!), Які потребують доступу низького рівня, і їх все одно потрібно буде запускати "на самому".

Як і керовані мови, вам доведеться використовувати відповідний інструмент для роботи.


3
Я дійсно не згоден. Немає підстав для того, щоб грати в натурному режимі, і немає реальної потреби бути рідним для того, щоб виходити на низький рівень, якщо операційні системи надають вам всю необхідну керовану точку входу. Звичайно, є деякі недоліки продуктивності (насправді мізерно малий, якщо керується всією системою), але сьогодні ми маємо багато процесорних потужностей та багато потреби у надійному програмному забезпеченні.
Wizard79

@Lorenzo Games вже наголошують на комп’ютерах, тому важливо досягти ефективності. Однак я не впевнений, який би вплив на продуктивність мав би, якщо все, що VM робить, завершує власний дзвінок
TheLQ

4
@TheLQ: справа в тому, що ігри вже не мають справу з "предметами низького рівня", оскільки завжди є деякі проміжні програми (DirectX, Open GL тощо). Звичайно, вони обчислювально інтенсивні, але використання проміжного програмного забезпечення вже є хітом для продуктивності. Це було б просто кероване (і сутуле) програмне забезпечення.
Wizard79

3
Якщо ОС піклується про JITting, ви закінчите керований код, який працює більш-менш швидко, як "рідний" код. Пам'ятайте, що якщо ви повинні мати збірки , як контроль над програмою, ви завжди можете використовувати програму безпосередньо в байт-код.
Chinmay Kanchi

3
Afaik, MS Singularity отримує значне підвищення продуктивності завдяки тому, що йому взагалі не потрібно перемикатися між режимом ядра та режимом користувача. Розгортання теж стає значно дешевшим.
9000

3

Як правило, я думаю, що вони хороша ідея, але оскільки їх не так багато навколо або близько, щоб повністю випекти, дуже важко розповісти, як вони виступатимуть у реальному світі. Мені б хотілося, щоб MS оновила проект Singularity, щоб ми могли бачити, куди це йде, але я гадаю, що частина цього працює над якоюсь версією Windows


3

Я думаю, що переваги повністю керованої ОС величезні, і це справді може бути майбутнє, але для цього знадобиться багато років.

Хороша керована операційна система надасть вам всю керовану точку входу, яка вам потрібна, щоб виконувати будь-яку необхідну вам річ ​​на низькому рівні, незалежно від того, чи керуєте ними: ловити переривання та виконувати введення / виведення пристроїв. C # також дозволяє отримати небезпечний код (маючи справу з покажчиками), але він буде дозволений лише у "драйверах пристроїв" (що буде лише іншим типом програмного забезпечення, ізольовані процесом).

Переваги в безпеці, рівномірності, портативності та особливо надійності, безумовно, перевищать будь-які недоліки в роботі. Тоді повністю керована система на диво швидка, оскільки більше не потрібно робити контекстну комутацію.


Ви впевнені, що контекстний перемикач не потрібен? Вам все одно потрібно запустити кілька програм одночасно.
робота

Якщо і програми, і код працює в VM, не може бути контекстного перемикання. Однак це потребує повторного введення MMU мовою HL, тому я дійсно сумніваюся, що користь від роботи буде значною.
Мацей П'єхотка

2

Керовані ОС, мабуть, як-то схожі на мікроядра - ви жертвуєте продуктивністю заради безпеки.

Можуть виникнути подібні проблеми, оскільки він вимагає розщеплення коду на 2 частини:

  • Ядро низького рівня написано на C / асемблері
  • Ядро вищого рівня, написане керованою мовою

Залежно від вартості безпечного введення / виходу з мови HL, це може спричинити подібні проблеми, як мікроядерні канали - можливо, трохи швидше (залишення HL швидше, ніж повний контекстний комутатор, але IIRC, наприклад, JNI, досить дороге).

Користувачеві програми також, ймовірно, знадобляться окремі контексти, оскільки багато додатків написано на інших платформах (скажімо, на C, Java або .Net). У тих же випадках програми можуть бути пов'язані з процесором (компілятори, перетворювачі музики тощо) і потребувати навіть оптимізації асемблера для виконання з достатньою швидкістю. Крім того - захист MMU, реалізований на мові HL, ймовірно, не буде настільки швидким, як апаратний, навіть якщо він може бути набагато більш точним.

Також HL мова не володіє низькорівневими операціями. Хоча програмне забезпечення, як правило, розроблене з "хорошими" драйверами практики кодування, це не потрібно. Я не думаю, що вони захистять принаймні деяких помилок, оскільки ядра вимагають іноді ручної пам’яті.

Нарешті, я не думаю, що для такої ОС потрібна повна VM. Оскільки ОС не може бути побудована з принципом компіляції одноразово запускати всюди мови HL (навіть з GC & co.), Зробить кращим кандидатом.

Наприклад, ви раптом роблять довільні вказівники застарілими.

ОС по суті є низьким рівнем. Ви передаєте на апаратне забезпечення не лише "довільний покажчик", але ймовірно фізичну адресу, а не віртуальну. Деякі DMA можуть обробляти лише перші 16MiB пам'яті. Хоча така ОС може значно спростити, адреси не позбудуться.

І якщо це добре написано, ви позбудетеся тонни застарілого сирого, що є у більшості сучасних ОС.

  1. Є багато застарілого обладнання. Набагато більше, ніж у програмному забезпеченні. Ви спочатку запускаєтесь у реальному режимі, потім вмикаєте ворота A20 (не запитуйте) переходити в захищений режим, потім у тривалий.
  2. API / ABI сумісність хороша. Скажіть, вони написали таку ОС - що б ви на ній працювали? Firefox - nope (C і C ++ за допомогою WinAPI). Java - ймовірно, її потрібно було перенести або виникли незначні проблеми через ikvm - якщо тільки не сподіватися на використання JNI. Я думаю, що MSSQL (і точно: Oracle, MySQL, Postgresql ...) не пишеться керованою мовою, щоб не підходити для сервера.
  3. Навіть сумісність помилок "хороша". AFAIK MS витрачає багато часу на тестування та перевірку, чи якесь програмне забезпечення не використовує API розумним (читати неправильно) способом. Як і проблема використання вказівника після freeнього, коли Windows насправді почала звільняти пам’ять.

Я здогадуюсь, він придбає популярність приблизно в той же час, що і мікроядер.


2

Особисто я вважаю, що ідея керованої ОС трохи схожа на комунізм: теоретично хороша, але непрактична для реалізації.

Проблема полягає в тому, що я просто не бачу ніякого способу залучити керовану ОС без повного перезапису операційної системи з нуля (і я сподіваюся, що хтось може довести мене неправильно в цій частині). Крім того, як зробити десятиліття некерованого коду, який вписується в керовану ОС?

Ядра найпопулярніших ОС там пройшли випробування на бій і дозріли протягом декількох десятиліть. Ви не просто переписуєте їх на примху. Не кажучи вже про те, що історія наповнена прикладами процесорів дизайну та архітектури ядра, які, безперечно, були кращими, але ніколи не змогли переконати когось, що вони варті вартості зміни на них.

Нарешті, як така компанія, як Microsoft чи Apple збирається продавати керовану ОС клієнтам? Чи буде навіть пересічний користувач комп’ютера піклуватися, якщо їх ОС керує чи не управляється?

Вище сказане, я сподіваюся, що я помиляюся і що керовані ОС стануть реальністю. Але я скептично ставлюсь. Якщо ми коли-небудь це побачимо, це, мабуть, не буде ще десятиліття-два.


2
Ядро ОС не дуже важливе для прийняття. MS створила абсолютно нове, несумісне з чим-небудь ядро ​​NT, і це було успіхом. Apple змінила архітектуру ядра різко (і свою архітектуру процесора, тричі), і все ще процвітає. Ключ - сумісність із існуючим програмним забезпеченням та простота переносу. Шари сумісності та / або віртуалізації, які дозволяють плавно переходити від старого коду до нового коду, не виглядають надмірно важкими в керованій ОС.
9000

2

Керований код - це лише екстраполяція того, що захист віртуальної пам'яті купує вам сьогодні, а саме здатність комп’ютера забороняти доступ до ресурсів.

IBM вже робить це у своїх системах мейнфреймів (вони просто називають це щось інше), тому, на мою думку, це лише питання часу, коли це станеться на системах, доступних для широкої громадськості.

Чи б ви не переймалися, якщо Google Ноутбук (який працює під керуванням Chrome і взагалі нічого іншого) працює з керованим кодом чи ні?


1

Однак, як недолік, ви настільки віддалені від обладнання, і як розробник, ви втрачаєте здатність опускатися до нижнього рівня абстрагування і бруднити руки.

Це насправді не так. Наприклад, в JNode є Unsafeклас (та інші), які дозволяють отримувати доступ до місць пам'яті тощо. Також є деякі "магічні" класи / методи, які перекладаються компілятором JIT в приватні інструкції. Доступ до цих класів / методів обмежується (або буде) обмеженим менеджером безпеки, компілятором JIT тощо. Але якщо ви пишете код, який виконується на рівні операційної системи, ці засоби вам доступні.

Застереження (звичайно) полягає в тому, що неправильне використання Unsafeкласів і пов'язаних з цим класів може призвести до негайних збоїв в операційній системі або вниз по шляху.


0

Я сумніваюся в їх корисності для настільних комп'ютерів. Але час може довести мене неправильно з цього приводу.

Але один цікавий потенціал в моїх очах - як операційна система сервера, точніше як гостьова операційна система у віртуалізованому середовищі. Ніколи мені не доводилося встановлювати повну установку сервера Windows у віртуальному серверному середовищі, знаючи, скільки непотрібних сервісів він працює, включаючи повний графічний інтерфейс.

Тепер встановлення чогось на кшталт Singularity на віртуальний сервер для розміщення програм ASP.NET, що має більше сенсу. Якщо припустити, що вони можуть тримати це легкою ОС.


1
Приємно взагалі вирватися з Windows, коли зможете.
робота

1
Схильність до браузерів із пісочницею та інших речей, що стосуються Інтернету, ймовірно, свідчить про те, що керована ОС або робочий стіл, як мінімум, також бажана.
9000
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.