информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsАтака на InternetГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ростелеком заподозрили в попытке... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Оно, действительно, есть, но пока в виде уродливых костылей... 29.09.05 14:17  Число просмотров: 1709
Автор: fly4life <Александр Кузнецов> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> > Согласен, что изначально в никсах не было ACL. За
> > ненадобностью. Но во-первых, реализация Posix ACL
> всё-таки
> > уже есть. Во-вторых, реально на своей практике я не
> > сталкивался с какой-то нехваткой функциональности при
> > раздаче прав триадами. А дать разрешение на доступ к
> файлу
> > лишь одному пользователю - это, наверное, вообще
> присуще
> > лишь домашним виндовс-пользователям ;).
>
> Если бы это было так, то не пытались бы терзать posix на
> тему acl.

Оно, действительно, есть, но пока в виде уродливых костылей =(.

> Я рад, что дыры таки латаются. Вот только есть
> отличия между изначально хорошей и продуманной архитектурой
> и постепенным накладыванием заплаток. Посмотри на
> intel-овский ассемблер (обратно совместимый с 8086) и ты
> поймешь в каком направлении движется юникс. Работать
> конечно будет, но хорошей архитектурой это не назовешь.

Какие ещё дыры? Отсутствие ACL - это не дыра. Их не было за ненадобность. Теперь кому-то надо, поэтому скоро реализуют в полном объёме.

> > Чего-то я не понял про devfs. Даже с ним оно всё равно
> в
> > виде файлов. Просто они создаются по указанному в
> конфиге
>
> При devfs они не валяются на винте.

А, точно, ты за inode боялся. Мне этого не понятно. Ты не волнуйся, с ними (inode) ничего не случится.

> > алгоритму при старте системы ;). Ну, а то, что ты
> согласен
> > с тем, что обобщенный доступ к устройствам в виде
> файлов
> > это хорошо, я только рад и поддерживаю тебя.
>
> Ты, наверное удивишься, но в винде все тоже сделано так
> (обобщение даже еще бОльшее - директория объектов
> называется).

И что? =). Я же говорю, что поддерживаю такой подход. Или это опять поптыка показать, как в виндах всё круто и причём давно? Дык, пожалуйста.

> > Кстати, devfs уже давно =). А, кстати, из линуксового
> ядра
> > уже даже убрали. Потому как появился более правильный
> udev
> > (если интересно, почитай в гугле. Довольно-таки
> удобная
> > штука этот udev).
>
> Еще одна заплатка на заплатку. См. мое замечание по поводу
> интеля.

Да причём тут заплатки?! Заплатка - это когда закрывают какую-то ошибку, devfs и udev, если хочешь, можешь не использовать, и при этом ты НИЧЕГО не потеряешь. Эти механизмы реализованы не для латания каких-то дыр, а для удобства некоторых пользователей.

> > > чтобы обеспечить совместимость своего драйвера со
> > всеми
> > > остальными мне нужно направлять куда то запрос на
> > выделение
> > > старшего номера. В конце концов этот ляп тоже
> придется
> > > латать чем нибудь типа IPv6 для инета.
>
> > Уже. udev =).
>
> Чтобы отказаться от старшего/младшего номеров надо во
> первых переделывать ядро, а во вторых переделывать
> стандарт. Но про udev я как нить на досуге почитаю
>
> > Реализовано. И даже по-человечески. Просто понятия о
> > человечности у тебя и разработчиков PnP для linux -
> разные
> > ;).
>
> То есть расширяемый с минимальными затратами (без
> переписывания всего, что уже есть) и нормально определяющий
> устройства на всех шинах (в том числе и тех, что еще не
> появились - для них просто дополнительный драйвер нужен)?

Уверен, что расширить можно как дописав, так и переписав ;).
А вот огласите, плз, критерии нормальности опеределения устройств. Если это виндовая, то помнится как-то была интересная ситуация с драйверами для какого-то устройства. Кажется двуковой платы. Так вот, винда её как-то определила по-своему, поставила свои драйвера. Оказалось, что с этими драверами звуковая карта работает некорректно. Ну ладно, думаю, фигня, бывает. Решил поставить драйвера с сайта производителя карты. Так что ты думаешь? На все попытки винда отвечала мне, что наиболее подходящий драйвер уже установлен. Удаляю вообще карту из устройств, перезагружаю, и.... втихую подключаются опять драйвера из виндов! Нет, я конечно поставил-таки нормальный драйвер, но если это нормальная реализация PnP, то извините. Я пешком постою.

> > Текстовые конфиги - это огромный плюс! Зря ты так.
>
> Чушь.
>
> > Нарисовать графическую конфигурялку к текстовому
> конфигу -
> > легко. Да и всегда можно в программе, которую ты
> напишешь
>
> Я не о графических конфигурялках, а об ЭФФЕКТИВНОСТИ. У
> реестра знаешь ли есть консольный клиент. Как раз наоборот,
> легко написать конфигурялку, которая будет выводить хоть в
> текстовом хоть в каком угодно виде, но ВНУТРЕННЕЕ
> представление должно быть ориентированным на ЭФФЕКТИВНОСТЬ.

Значит, это уже дело удобства. Я сторонник более противополжного мнения.

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

Видимо, им насрать на ТВОЁ удобство, потому как моему они отвечают полностью ;)

> > А реестр... ну это вообще нечто, что со временем
> > превращается в помойку и фиг протелепатируешь, что из
> неё
> > вычистить можно, а что нет.
>
> Ой ли. То ли дело текстовые конфиги. Разбросаны по всему
> диску, имеют кучу секций, но при этом ты всегда точно
> уверен, что за что отвечает. Это знание тебе
> устанавливается пакетным менеджером вместе с самим пакетом.

Ну да, а что? А вот кто мне в виндовсе расскажет, кому принадлежит rкакой-нибудь наугад тыкнутый ключ в реестре?

> > Гм. Чего-то я ни одного недочёта не увидел. Лукавлю,
> > конечно. Но и не так всё страшно, как это описываешь
> ты.
>
> Все гораздо хуже. Потому, что это только то, что на
> поверхности. На самом деле архитектура юникса вся такая.
> То, что не покрыто стандартом - еще с горем пополам могло
> развиваться, а то, что было стандартизировано - увы.

И при этом никсы раззвиваются семимильными шагами. Нда, действительно всё плохо.

> > Можно также обстроить недочётами всю винду. Начать с
> того,
> > что МНЕ не нравятся графические настройщики =).
>
> Пользуйся reg.exe и будет тебе щастье. Примерно тот же
> уровеь удобства, что и текстовые конфиги: сначала находишь
> в документации, где валяется нужный тебе ключ, потом
> вводишь длиннейшую строчку и вуаля - все настроено.

Ну уж нет. Глядя на него, я начинаю понимать, что виндовые графические конфигураторы - это хорошо. Понятно теперь, КАК людей отучают от текстовых конфигов ;). Хотя никакой он не текстовый и твоя аналогия притянута за уши.
<operating systems> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach