<font size=«+1»>Одной из «блестящих функций» новой версии настольной среды Linux станут ограничительные инструменты для администратора.</font>
Следующая версия GNOME будет содержать ряд инструментов, нацеленных на облегчение внедрения администраторами настольной среды Linux на предприятиях. Согласно статье разработчика GNOME Дэвида Мейдли, опубликованной на веб-сайте проекта в конце прошлой недели, версия GNOME 2.14, которая должна выйти 15 марта, будет включать новые инструменты администрирования, такие как менеджер профилей и редактор для ограничения функциональных возможностей ПК.
В своем блоге Мейдли поясняет, что он написал статью, чтобы «донести о блестящих возможностях» GNOME 2.14, хотя и предупреждает, что окончательный состав финальной версии 2.14 может измениться.
Менеджер профилей Sabayon позволяет администраторам создавать профили групп пользователей и устанавливать параметры по умолчанию и обязательные параметры для этих групп. А при помощи редактора ограничений Pessulus можно запрещать определенные функции настольной среды GNOME. «Это бывает полезно в корпоративной среде и в интернет-кафе, где пользователям нельзя позволять редактировать панели, работать с командной строкой и т. п.», — пишет Мейдли.
GNOME 2.14 должен обеспечить также «значительное» повышение производительности, благодаря новому распределителю памяти. По словам Мейдли, он выполняет операцию, которая у прежнего распределителя памяти занимала 26 с, всего за 2 с.
Хотя у GNOME много преданных сторонников в техническом сообществе, основатель Linux Линус Торвальдс не фанат этой настольной среды. В прошлом году Торвальдс заявил, что GNOME разработан «фашистами от интерфейса», и порекомендовал пользователям переходить на конкурирующую настольную среду KDE.
источник: ZDNet
// Тему переместил(а) Dmitry Shurupov из форума «Новости».
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
делают фторую винду
думаю, что нет. просто добавляют инструментарий, который необходим для продвижения/развития продукта на рынке. а кто, что делает — это еще вопрос…;)
может, винда делает Linux ;)
все к этому и идет.
М$ намеревается же сдалать какие-то загрузочные скрипты в следующих версиях…
с этого места поподробнее…
Более того, уже в Windows Vista планируется разделить ядро и графическую оболочку.
Впрочем вынь настолько крив, что вряд ли им это поможет.
Думаю, что в Microsoft осознают, что даже предложи они раскрыть код своей Windows, над ними просто посмеются. Пользы уже от этого никакой.
Блин, чуваки, вы мне глаза на мир каждый день открываете. Я понимаешь ежедневно ковыряюсь в ядре nt, а там оказывается еще и графическая оболочка есть…
Линуксойды отжигают по-полной…
А еще говорят, пользователи винды пьют кровь христианских младенцев…
Скорее всего имелось в виду следующее:
PS: <font color=«blue»>Microsoft to move graphics outside OS kernel</font>
самому интересно :)
буржуйские журналисты не лучше наших.
Я заявляю, что в ядре линукса тоже есть графическая подсистема, называемая framebuffer, и некоторые ушлые товарищи ее пользуют дабы рисовать красивый фон в терминале. За что линуксу, как ядру, позор и порицание.
Сравнил… В любом случае, framebuffer из линуксового ядра выдирается легко и непринуждённо, а вот графическая подсистема из виндового… ммм… как бы это сказать.. пока никак, да? ;).
А она там есть? Исходники 2k спижжены и лежат, например, у меня на винте. Скажи в каком файле там графическая подсистема :)
Т.е. мне посмотреть лежащие у тебя на винте спижженные исходники, и что-то в них найти и показать тебе? Клёва ;) А их вообще обязательно смотреть? Ты уверен, что ориентируешься в тех исходиках? ;)
Для начала предлагаю удалить файл win32k.sys (лежит в %windir%\system32 в случае WinXP), и ответы на вопросы: «А она там есть?», «что это за win32k.sys такой» и «каким образом он относится к ядру виндовса» — предлагаю найти в гугле самостоятельно.
нет.
это: 1)драйвер минипорта графического адаптера и 2)почти все вызовы NtGdi*. Рассказать что такое gdi и почему это не графическая подсистема?
Никаким. Это во первых драйвер, во вторых kernel level runtime сисколы(syscall) которых может и не быть. Например в Windows XP Recovery Console он не загружен.
Если тебе интересно, то я могу рассказать как загрузить любую NT без него и получить девстенно чистый экран черного цвета и командный интерпритатор.
И еще, хорошо бы определиться в понимании разницы между:
- OS Kernel
- Kernel Level API
- User Level API
дабы не было недопонимания.
PS
Ликбез:
непосредственно ядро: ntoskrn.exe
подсистемы, типа dos, win16, etc : nt*.sys
HAL : hall.dll
user level syscalls : user32.dll
kernel level syscalls : kernel32.dll
PPS:
From «Inside Windows 2003 Server» book
Мне интересно, расскажи.
С удовольствием послушаю ;). А так же о том, что такое «графическая подсистема» и из чего она состоит.
Интересно, а как мне сделать, чтобы этих вызовов не было? Точнее, чтобы при отсутствии win32k.sys (я пока ещё его считаю частью графической подсистемы ;)) у меня XP не уходила в перезагрузку?
Что из себя представляет 'recovery console' я знаю. Во-первых это не то чтобы не операционка, а не оболочка даже. А вот как выглядит «девстенно чистый экран черного цвета и командный интерпритатор» очень даже интересно увидеть. Как сделать?
Ой, ну да. Дабы не было недопонимания. Под: «Графическая подсистема Windows Vista под кодовым названием Avalon и известная как Windows Presentation Foundation (WPF) будет вынесена из ядра новой ОС» — как раз, подразумевается, что графическая система будет вынесена из kernel level в user level.
Спасибо ;)
Thats it!
Т.е. все уже поняли что графическая система nt не часть ядра, а в драйверы и библиотеки уровня ядра?
Без него никак. Из-за того, что в этом драйвере(читай выше) минипорт графического адаптера. Т.е. без него HAL не будет знать о существовании видео карточки, вернее не будет интерфейсов взаимодействия с ней.
Можно загрузить nt без инициализации gdi.
графическая подсистема состоит из интерфейсов(драйверов) и библиотек обращения к ним. Т.е. фактически графическая система должна позволять зазставить ОС нарисовать пиксель заданного цвета в заданых координатах. Дальше эти(чаще всего kernel level) вызовы используют прикладные библотеки, которые тоже можно считать частью графической подсистемы). В nt над драйверами сидит непосредственно GDI(то что в linux, наверное, делает framebuffer). GDI в nt реализован в виде множества вызовов, часть из которых kernel level( в win32k.sys), а часть user level(gdi.dll) и DirectDraw(из DirectX). Дальше над GDI сидит Common Controls Library, еще выше MFC, и еще выше Windows.Forms в .NET. DirectDraw сам представляет пользовательские вызовы и сам работает непосредственно с драйверами(хотя вот тут я точно не знаю)…
Вот такая примерно картина ;)
Вывод: То что часть графической системы работает в kernel level, не делает ее(часть или всю) составной частью ядра. Так как напрямую с ядром работает только драйвер минипорта(ну а ему и положено:)
PS
Кстати, говорят что до nt 4.0, т.е. <= 3.5, GDI целиком жил в user level, но оказался слишком тормозным и переехал частично в kernel level.
Думаю, и с самого начала все подразумевали о том, что графическая подсистема винды работает на уровне ядра, а не часть бинарника ntoskrn.exe. Даже Sasha2, который, наверное, просто неудачно выразился.
Т.е. ты всё-таки согласен с моим изначальным утверждением: «framebuffer из линуксового ядра выдирается легко и непринуждённо, а вот графическая подсистема из виндового пока никак».?
Если уогодно, то для улучшения понимания этого выражения можно перед словами «framebuffer» и «графическая подсистема» вставить слово «поддержка».
Дык, как? Я ещё в прошлом письме сказал, что мне это интересно. И, вон, LONGOBARD тоже ждёт рассказа ;).
К концу твоего сообщения до меня всё-таки дошло. По-твоему ядро — это лишь ntoskrn.exe? А я почему-то считал, что модули и ядерные библиотеки — это тоже части ядра. Потому как без них ОС работать не будет.
А теперь поняли, что GDI в kernel level слишком рискован (да и, кстати, совсем не нужен) для работоспособности всей системы, и перевозят обратно в user level ;). Собственно, с чего и начался весь этот познавательный флейм ;)
Очень странно ты считал, учитывая возможность пересборки ядра в linux:)
Интересно как модули(они же драйверы) могут быть частью ядра, если они опциональны для загрузки. В linux ты можешь часть драйверов не собирать вообще. Драйвер не часть ядра, так как драйвер — это, хм, ну это просто драйвер:) и ты прекрасно знаешь что это такое. Ни драйвер, ни библиотеки не являються частями ядра. У тебя же ядром является vmlinuz, так? а модуляим /lib/modules? Ну дык в nt, ядро ntoskrnl.exe, а модули %systemdir%[system32]\*.sys.
OC безусловно не будет. А вот ядро будет. Мы же про ядра говорим, а не про ОС? Что нужно для того что бы забутить(до kernel panic) linux? Да ничего кроме загрузчика и пачки жизненно важных драйверов. Тоже самое и в nt. Часть драйверов можно не грузить совсем, часть вкомпилена в ядра, а часть загрузит само ядро тебя не спросив.
Обязательно расскажу, надо в обеденный перерыв дойти до другого корпуса. Как получу инструкцию — напишу.
Именно засчёт возможности пересобирать линуксовое ядро, объясню ниже, почему нестранно ;).
Т.е. ты утверждаешь, что если модули включить в ядро монолитно (всё одним vmlinuz), то они будут частью ядра, а если их вынести в отдельные файлы *.ko, то они автоматически перестают быть составляющим ядра? Ошибаешься. Знаешь почему? Потому что у Linux (да, и у Windows также) — макроядро. Все части макроядра работают в одном адресном пространстве, составляя при этом единое целое. Отличие модульной сборки от монолитной в таких ядрах заключается лишь в том, что отдельные модули можно подгружать лишь в момент их надобности. И всё.
То, о чём говоришь ты, скорее ближе к микроядрам (таким, как в QNX и где там ещё?).
Жаль, что в виндовсе нельзя пересобирать ядро. Вот и путаются потом люди, называя ядром лишь ntoskrn.exe, а всё остальное так… модули какие-то ;).
:))) Лол. Нихрена ты про nt не знаешь. Потому что kernel level модулям не доступно адресное пространство самого ядра :) Это в linux — да. Но не в nt :)
from Microsoft Windows Internals, 4th edition (w2k3)
не путай себя. :)
Мы же про NT помнишь? В Linux все именно так(хотя я точно не знаю, тебе виднее), но в NT нет. В NT — модули, не являются частями ядра, так как не имеют возможности с ним напрямую взяимодействовать. Т.е. дабы какой-нить драйвер мог что-то спросить непосредственно у ядра(через kernel level hal), то ему надо позвать так называемый system service, который обслужит его запросы.
Тоже самое в принципе можно сделать и с user level, так как на время выполнения вызова внутри system service, система переводит вызвавшую нить в ring 1, а на выходе из service назад в ting 3.
PS
Учите мат. часть. NT это вам не юникс :)
И ваще микроядра это утопия. Хотя NT гораздо к ней ближечем любой Unix.
LOLx3!!!
Ссылки на столь «авторитетные» истоники не гарантируют того, что все на самом деле так. ВСЕГДА.
В куда более серьезных системах не все столь благополучно.
Видишь ли. Более авторитетного источника в природе не существует. Во всех известных мне компаниях используют именно эту книгу для разработки драйверов и библиотек для windows nt. Я канешка понимаю, что анархисту не положено верить бумагомаракам всяким, но больше ничего нету. Если канешна дамп асемблера желаемых бинарей больше устроит.. ;)
Для справки, авторы : Copyright © 2005 by David Solomon, Mark Russinovich. Можно у гугла спросить кто это такие :)
Ну или предложи более авторитетный источник :))
Нда… Ну вот, напрмиер, уже во вступлении к «User-Mode Interactions: Guidelines for Kernel-Mode Drivers» написано следующее:
The operating system and most drivers run in kernel mode and have access to operating system structures, to all system memory, and to all processor instructions. Kernel-mode components implicitly trust each other—that is, they assume that addresses and parameters they receive from other kernel-mode components are valid.
(http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/KM-UMGuide.doc)
Кто из вас глючит?
Блин. Они receive их, а не сами читают из чужого адресного пространства, они же не чилды одного папы:). Если ты сказал NtGetЧтоНитьИзЯдра(..) и в ответ получил const PVOID, то это по твоему разделяемое ядресное пространство? ;)
значит, что компоненты будут пытаться этот PVOID приводить к каким-то структурам, веря что это они на самом деле и есть. И ессно упадут если после каста, там будет что-нить типа 0xcdcdcdcd
ланн, это я понял.
А можно всё-таки, запустить винду без gdi, и под ней, например, ftp сервер? Судя по предыдущим постам можно, но как? Я собственно, не настаиваю на подробном объяснении, меня вполне устроит ссылка.
А то, чего-то насколько я помню свой период программирования в win32: system:windows, либо system:console — третьего не дано, но ведь даже для консоли нужен gdi, чтоб окошко нарисовать. Или я где-то неправ/плохо-помню/мало-маны-читал?
на самом деле их гораздо больше. например win16 или dos.
можно. линк не знаю. а «носитель информации» далеко. сегодня я до него так и не дошел. но как-нить дойду и запостю в этот тред.
Ладно, попробую подойти с другой стороны. Руссинович и Соломон, говоришь, авторитетные для тебя авторы. Ну вот цитата из их книги «Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000», 4-е издание, Питер, 2005, стр. 18:
Хотя каждый Windows-процесс имеет свою (закрытую) память, код операционной системы и драйверы устройств, работающие в режиме ядра, делят единое виртуальное адресное пространство…
… Windows не предусматривает никакой защиты системной памяти от компонентов, работающих в режиме ядра. Иначе говоря, код операционной системы и драйверов устройств в режиме ядра получает полный доступ к системной памяти и может обходить средства защиты Windows для обращения к любым объектам. Поскольку основная часть кода Windows выполняется в режиме ядра, крайне важно, чтобы компоненты, работающие в этом режиме, были тщательно продуманы и протестированы.
«Учите мат. часть» ;).
Это таже самая книга, что я приводил до этого, только перевод;)
Ну дык может. Еще бы не мог, ты же в ring 1:) Это не значит что так нужно делать.
Как известно адресное пространство ядра имеет несколько секций(сегментов), которые предназначены для разных целей. Не мог бы ты посмотреть в этой книге(в переводе) какие именно сегменты доступны другим процессам?
Без условно получают доступ, потому что работают в одном ring. Без этого они не могли бы работать вообще.
Только этот доступ заключается в дергание функций системного сервиса, буфера между ядром и драйвером. Даже если где-нить непосредственно в ядре есть
Это не значит, что ты сможешь сказать где-нить в драйвере
и получить до нее доступ.
А возможность получить указатель на какую-нить кернельную структуру, через какой-нить syscall не являеться признаком того, что вызывающий код — часть ядра.
Т.е. не настаиваешь на том, что если ядро и драйвер работают в одном ring-е, общаються через syscall-ы, то драйвер автоматически является частью ядра, syscall-ы которого(ntdll.dll например) он дергает?
Да, я знаю ;)
В ring 0, если быть точным ;).
Но и не говорит о том, что так делать нельзя ;).
Эммм.. каким другим процессам? А зачем это вообще? ;)
Думаю, не потому, что работают в одном ring, а именно потому, что все работают в ring 0. Вон, user mode процессы тоже работают все в одном кольце (ring 3), но при этом доступ к ресурсам друг друга не имеют.
Наверное, это не из-за того, что оно в принципе не может получить до неё доступ, а просто потому что так реализовано в виндовс <font size=«-2»>(чтоб ты не думал, что эти противные линуксоиды опять ни по чём гнобят винду — нет, я не на кривость намекаю ;))</font>.
Нет, не настаиваю. Вот, нашёл статью Соломона об архитектуре ядра NT 5.0:
http://khpi-iip.mipk.kharkiv.edu/library/extent/os/os/nt5.html
Да, судя по ней, модули (драйверы) в NT не являются частью ядра. Аналогия с Linux неуместна.
Итак, резюмирую своё участие в дискуссии по части виндового ядра:
Ядро NT — это действительно лишь некоторый набор функций в ntoskrnl.exe. Однако модули работают в режиме ядра и всё равно имеют единое виртуальное адресное пространство с ntoskrnl.exe.
Тут к консенсонсу, вроде, пришли ;).
пришли. за мною инструкция как забутить nt без графики.
на сколько я знаю, часть в ring 1, а часть в ring 0. Хотя для нас это и не важно. Ибо смертным из ring 3 без разници.
Не потому что не могут, а потому что выделением памяти занимаеться ОС, а она не даст:) Соответственно, как ты верно подметил, выше по уровням можно, так как нету средств защиты кусков ядра друг от друга.
Так или иначе, драйвер должен вызывать методы ядра, хотя бы чтобы дать понять ядру, что он готов и его можно зарегистрировать.
А теперь я попытаюсь объяснить враждующим сторонам, как устроены Windows и UNIX, чтобы они (стороны) друг-друга не поубивали.
Уважаемые господа, идём <font color=«green»>сюда</font> и читаем чем отличаются monolithic- (Unix), micro- (QNX) и hybrid- (NT) ядра.
Та ну, ты брось «враждующие» ;)
Моей ошибкой было считать ядро NT макроядром (monolithic, если будет угодно) и сравнивать его с линуксовым.
Однако принципиальным моментом в этой дискуссии было то, что драйвера и в линуксовом (монолитном), и в виндовом (как оказалось, гибридном) ядрах работают в режиме ядра (kernel mode). А также то, что все компоненты, работающие в kernel mode, используют единое виртуальное адресное пространство. Это значит, что если йопнется один компонент, то может потащить за собой все остальные, в том числе и ядро ОС (с этой стороны всё одинаково для обеих систем). Откуда следует, что всю графическую подсистему (как что-то громоздкое, а посему непростое в отладке и отловке всевозможных глюков) лучше выносить из режима ядра в пользовательский. К чему и стремится MS в новой версии своей ОС. Ну а с неправильной трактовки этого факта и начался весь флейм. Всего-то ;). Никто никого убивать, вроде, не собирался ;).
В остальном я с decvar’ом уже согласился. Считать win32k.sys да и вообще графическую подсистему виндовса частью NT-ядра — ошибка.
ядра — да.
но так как простые пользователи само ядро мало когда замечают, то им важнее то, что GUI у Win — всё ещё неотъемлемая часть системы…
для теста: вынимаем видеокарточку из компа вообще.
как заставить win семейства nt грузиться в такой конфигурации?
Будешь третьим, кто ждёт от decvar’а той самой инструкции ;)
мдаа. и тогда уж и «сообразим на троих», что говорится.. :D
вообще, мне достаточно того, что описанный мною тест — не проходит в системе, установленной стандартно (с использованием штатного инструментария).
таким образом, «инструкция» будет ни чем иным, как описанием использования некоторого набора дополнительных (и, скорее всего, сторонних) утилит.
Не, сообразить decvar’у надо, а мы просто выпьем, поболтаем за жисть… ;)
Если в этой «инструкции» будет использовано штатное ядро (это принципиально), то использование сторонних утилит будет означать, что виндовс без графики всё-таки может существовать. А если удастся в этом катсрате ещё и запустить нечто большее, чем «девственно чистый чёрный экран» — будет означать, что в нём можно ещё и работать.
Другими словами, если всё упрётся в штатные утилиты, то это дело маленькое. Их отсутствие будет означать, что оно просто напросто пока никому не нужно ;).