LINUX.ORG.RU

Проект X.org уходит с HAL

 , ,


0

0

В качестве ответа на постоянно возникающие вопросы по поводу отказа от использования HAL проектом X.org, работник SUN Алан Куперсмит (Alan Coopersmith), создал соответствующую wiki страницу

В этой вики Алан сообщает, как задействован HAL в проекте X.org, как HAL обнаруживает устройства ввода, обеспечивает мапирование и настройку. X.Org использует HAL начиная с X Server 1.4 и будет продолжать использовать до версии X Server 1.7 включительно, но миграция с HAL будет закончена к выходу X Server 1.8, релиз которого намечен на март.

Так как ни одна другая библиотека не предоставляет нужной функциональности, то в X Server появится много ОС специфичного кода, для Linux это означает очень много прямых подключений непосредственно к libudev. Для хранения настроек устройств будет использована директория xorg.conf.d и пока новая функциональность будет добавляться, также сохранится поддержка xorg.conf в полном объёме.

>>> Подробности

★★★★★

Проверено: svu ()
Последнее исправление: Deleted (всего исправлений: 1)

Цытата из линка выше.

For other subsystems, such as Firewire, audio and input my answer for
this is to, for notifications and enumeration, rely on the core
DeviceKit daemon and values exported by the OS kernel (e.g. sysfs on
Linux). In effect, this is not any different from using HAL today.

Читаем вот это «this is not any different from using HAL today»

Теперь вопрос, а почему автор hal/devicekit считает что с уходом HAL ВООБЩЕ НАХРЕН ничего не поменяется ?

А постеры в треде рассказывают про impending immanent doom, уничтожение достижений в области десктопа, падение X в пучину мрака и забвения, конец золотого века 2005 года(крон73), полный развал линукса и невозможность даже прийти соседке с фотоаппаратом(О УЖАС!).

А автор говорит что вообще «ничего не поменяется от современного состояния использования HAL»

kernel ★★☆
()

О чём базар?
Всегда юзал xorg.conf

tim4dev
()
Ответ на: комментарий от jackill

>Скорость настройки + сжатие трафика.

А что надо настраивать в X-ах для удалённой работы? А то я что-то не знаю, без настройки работаю.

Траффик сжимать мого кто умеет.

gena2x ★★★
()
Ответ на: комментарий от NIR

>А для неосиливших команду mount существует udev. И неплохо так существует.

Ты ещё поделись анти-udev'ом, который бы умел делать umount. Но не после выдирания флешки или дискетки, а _до_ этого.

morbo
()
Ответ на: комментарий от kernel

> Вообще все эти крики об «убожестве» X это кричат люди с виндовсом головного мозга. Их сознание сформировалось в убогих условиях подворотен компьютерных клубов с ворованой халвой, фолаутом и половиной компутеров в клубе.

Вообще все эти крики об «идеальности» X это кричат люди с иксами головного мозга. Их сознание сформировалось в убогих условиях советских ВЦ с вороваными писюками, передранными агатами и половиной программ в институте.

Вот как кернел - сразу вспомнил ламерка. )))

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

LamerOk ★★★★★
()
Ответ на: комментарий от kernel

>Вообще все эти крики об «убожестве» X это кричат люди с виндовсом головного мозга. Их сознание сформировалось в убогих условиях подворотен компьютерных клубов с ворованой халвой, фолаутом и половиной компутеров в клубе.

Да? http://linuxwacom.sourceforge.net/index.php/faq#HOTPLUG

Is hot plug supported for X intput devices?

X Intput Device Hotplug is not fullly supported at Xorg yet. But, Wacom X driver has implemented a workaround for those who have to unplug/replug the tablet while X is running.

То-то девелоперам всякие workaround'ы городить приходится.

Leron ★★
()
Ответ на: комментарий от Sylvia

>kdeшную переключалку?

она 20 Mb RSS кушает, жалко как-то...


% ps -eo rss,cmd | grep kxkb
7780 kdeinit4: kxkb [kdeinit]

AX ★★★★★
()
Ответ на: комментарий от morbo

>Ты ещё поделись анти-udev'ом, который бы умел делать umount. Но не после выдирания флешки или дискетки, а _до_ этого.

pumount?

AX ★★★★★
()

> HAL is not used by Xorg for output devices or any other devices, only input.

Ну и правильно, что на udev переходят. для БСД свои костыли придумают, если в этом вообще есть необходимость. Системные устройства и методы вводы - в xorg.conf, пользовательские домыслы - в пользовательские стартовые скрипты. Это работает! Более того, подключаемые на лету юсб мыши и клавы подхватываются иксами и без хала.

offtopic: hal - идея здравая, реализация ужасна (во всяком случае с точки зрения её администрирования.. может, с точки зрения кодинга там все обстоит лучше).

azure ★★
()
Ответ на: комментарий от blind

+5410

а то я в слаке не мог добавить русскую раскладку из-за этого г-на.

cetjs2 ★★★★★
()
Ответ на: комментарий от Leron

> То-то девелоперам всякие workaround'ы городить приходится.

И че, собственно? Че сказать то хотел ? Что хотплагов нету ?

Девелоперов мало, задача сложная., много архитектур, операционных систем,специфических условий. Если бы больше было девелоперов типа вакомсовских давно бы уже из воркараундов собрали бы хотплаг. Как это и должно быть в опенсорс..

kernel ★★☆
()
Ответ на: комментарий от azure

>для БСД свои костыли придумают, если в этом вообще есть необходимость.

Вообще-то, на FreeBSD есть devd.

Сёдня я вернулся на HAL, отключив правила автомонтирования devd для флэшек.

Пересобрал libexo из Xfce и всё от неё зависящее (в том числе Thunar) с поддержкой HAL'а. Проблема с монтированием флэшектолько одна: нужно как-то сделать поддержку кодировки CP1251 для файловой системы FAT32.
Пока не знаю как это сделать — менять /etc/fstab (он у меня пустой из-за ZFS), да этого вроде как не надо делать.

Кто знает какой способ применения кодировки для автомонтирования носителей через HAL правильный и что почитать об этом?

iZEN ★★★★★
()
Ответ на: комментарий от LamerOk

> Вообще все эти крики об «идеальности» X это кричат люди с иксами

головного мозга. Их сознание сформировалось в убогих условиях

советских ВЦ с вороваными писюками, передранными агатами и половиной


программ в институте.



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

Всё познается в сравнении. Нервные подёргивания в конке при

джикверевоском слайдапдауне и мелькающий посреди страницы чёрный


квадрат малевича какбе намекают мне, что не всё так идеально в датском


королевстве, как это видится тем, кто ничего, кроме датского


королевства и не видел.



Да,да еще и вендузятник^WКДЕшник. Мы много чего видели. Просто у нас мозг сформировался не на ущербной системе на ущербных задачах. И по этому мы по умолчанию молча не считаем что надо «как в венде»/«макосе». А вы именно так и думаете. Вы видете «тормоза» потом не вииете «тормозов» на венде и кричите «хачу как на венде^wнужно заменить X». И таких долбоебов ЛОР уже перевидел реально толпы. НЕ вы первый, не вы последний.

Помню, бродили давно такие же как ты малолетние эксперты. Рассказывали что X устарели, и по сети никому не надо так как клиент-сервер на дельфях и «вообще зачем жтио надо». И чо? Когда венда доросла до соотвествующего спектра задач тут же начались эти решения под одинэс на терминалках. И цитриксы возникли и прочая х-ня. Выяснилось что без этого никак и надо таки сетевую прозрачность. И для всех приложений. И эти малолетки тихо слились. Наверное ставят терминальные решения под венду, за ненужность которых агитировали.

Сначала вопили что это все ненадо а теперь стало надо. Прикрутили костыль , и теперь убеждают что с костылем, типа vnc/rdp типа ПРАВИЛЬНЕЙ. Это же бугага полнейший. vnc/rdp это КОСТЫЛЬ. который возник потому что его кодили ТУПЫЕ ВЕНДОКОДЕРЫ которые захотели удаленный доступ венда-линукс,а X ТУПО НИАСИЛИЛИ.

То что у ВАС конк ублюдоный с чорным квадратом это вообще жалобы какието невнятные. Ну кодеры конка ниасиляторы. Бывает. Опенсорс. Иногда чорные квадратики.

Более умная опера честно рендерит всё в свой внутренний буфер и

проблемы не имеет. Вопрос - должна ли каждая программа заниматься


рендерингом сама в себя или у нас всё же будет когда-нибудь


_графическая система_?



Слушайте, вам с вашим кде,«конком» и оперой только фрибсд нехватает.

У X основной недостаток это небольшое число разработчиков и больщой про%$%б проекта до создания xorg. Который и был создан потому что был обьективный затык с конфликтами вокруг Xfree. И не меньший про%$%б по вине SGI с их закрытием доступа к OpenGL X серверу, вызвавший охрененную потерю времени. Если бы не эти потери времени все было бы гораздо лучше.

Что касается X протокола и API то нет ничего что бы не решил выход новой мажор версии X12. Там даже сокеты будут по именованию разные. А для не требующих скорости операций типа инициализации ничем сокет не хуже. Все остальное можно будет например гонять через аналог MIT-SHM для команд, сразу из памяти клиента, в случае соотвествующей конфигурации.
В случае если же запускать X сервер прямо на видеокарте текущая архитектура даже гораздо правильней.

kernel ★★☆
()
Ответ на: комментарий от kernel

>В случае если же запускать X сервер прямо на видеокарте текущая архитектура даже гораздо правильней.

А сколько кода из ядра выкинуть можно за ненадобностью! Только вот что-то nvidia и amd не торопятся. С amd понятно, драйвера скинули на плечи комьюнити и умыли руки, а nvidia до сих пор и спеки не открывает, цепляя за какие-то секреты, и дрова сама пишет, нет чтобы рубануть гордиев узел и хотя-бы в дорогих видеокартах «вшить» свой X-cервер с казино и куртизанками.

Attila ★★
()
Ответ на: комментарий от Attila

> А сколько кода из ядра выкинуть можно за ненадобностью! Только вот

что-то nvidia и amd не торопятся. С amd понятно, драйвера скинули на

плечи комьюнити и умыли руки, а nvidia до сих пор и спеки не


открывает, цепляя за какие-то секреты, и дрова сама пишет, нет чтобы


рубануть гордиев узел и хотя-бы в дорогих видеокартах «вшить» свой


X-cервер с казино и куртизанками.



За время существования X поменялось столько всего и столько еще поменяется что хрен с ними. Когда будет тогда и будет :)

kernel ★★☆
()
Ответ на: комментарий от kernel

> vnc/rdp это КОСТЫЛЬ. который возник потому что его кодили ТУПЫЕ ВЕНДОКОДЕРЫ которые захотели удаленный доступ венда-линукс,а X ТУПО НИАСИЛИЛИ

У X основной недостаток это небольшое число разработчиков и больщой про%$%б проекта до создания xorg.


Все остальное можно будет например гонять через аналог MIT-SHM для команд,


запускать X сервер прямо на видеокарте


Чувак, ты нереально доставил! )))

LamerOk ★★★★★
()
Ответ на: комментарий от kernel

> Что касается X протокола и API то нет ничего что бы не решил выход новой мажор версии X12. Там даже сокеты будут по именованию разные. А для не требующих скорости операций типа инициализации ничем сокет не хуже. Все остальное можно будет например гонять через аналог MIT-SHM для команд, сразу из памяти клиента, в случае соотвествующей конфигурации.

Чего-чего??? Это после X_11_ (!) R_7_(!) dot 6(!) делать X12? откуда дрова?

gena2x ★★★
()
Ответ на: комментарий от AX

>>Ты ещё поделись анти-udev'ом, который бы умел делать umount. Но не после выдирания флешки или дискетки, а _до_ этого.

pumount?


Техника - на грани фантастики. Точно так же можно использовать обычные mount и umount через sudo. Автоматизация через использование врапперов вроде p[u]mount и псевдоавтоматики от udev - это костыли, а не правильное решение задачи.

Мне, пожалуйста, программулину, основанную не на HAL'е, которая бы автоматически размонтировала носители по прошествии определённого времени, в течение которого к носителю не было обращений, и автоматически монтировала бы его, если обращение вновь произошло.

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

morbo
()
Ответ на: комментарий от morbo

>автоматически размонтировала носители по прошествии определённого времени, в течение которого к носителю не было обращений, и автоматически монтировала бы его, если обращение вновь произошло.

Поздравляю, ты изобрёл autofs. :)

чтобы можно было отключить автомонтирование отдельно от авторазмонтирования


udev rules + (p)umount - только автомонтирование.
autofs с опцией noauto в auto.misc - только авторазмонтирование.

нужно монтировать только вручную, а размонтировать можно и автоматически

что более интересно, монтировать вручную, а размонтировать можно автоматически



Это одно и то же, не? :)

Предлагаю свой вариант: настройка прав юзеров на отдельные действия (mount, umount, eject) с вариантами запретить/разрешить/разрешить при вводе правильного пароля рута/итд. Тут hal + polkit действительно трудно заменить.

AX ★★★★★
()
Ответ на: комментарий от AX

>Поздравляю, ты изобрёл autofs. :)

Я его не изобрёл, а описал. Только autofs не работает толком.

нужно монтировать только вручную, а размонтировать можно и автоматически

что более интересно, монтировать вручную, а размонтировать можно автоматически



Это одно и то же, не? :)


Описался, исправляюсь:

нужно монтировать только вручную, а размонтировать можно и автоматически

что более интересно, монтировать автоматически, а размонтировать вручную

Предлагаю свой вариант: настройка прав юзеров на отдельные действия (mount, umount, eject) с вариантами запретить/разрешить/разрешить при вводе правильного пароля рута/итд. Тут hal + polkit действительно трудно заменить.


У hal есть один небольшой такой недостаток - он не умеет монтировать, он только сообщает программам о имеющихся носителях. Те программы, которые общаться с ним не умеют, о появлении носителя ничего не узнают. Проще говоря, я не могу воткнуть флешку, перейти в командной строке в точку монтирования и пользоваться привычными cat/ls/rm/mv/less/rsync. Тут нужно либо добавлять в них интеграцию с HAL, либо изобретать дополнительные демоны для настоящего монтирования. Для хомячков, пользующихся гномом, HAL наверное хорош, но для тех у кого нет гнома или кде - уже не годится.

Есть ещё одна проблема которая вытекает из всего сказанного - система атоматического монтирования/размонтирования и разделения прав не продумана. Есть местячковые решения, которые решают какую-то одну часть задачи, но не решают другую. При этом ни одна система не предоставляет удобного способа взаимодействия с дополнительными компонентами, так чтобы можно было собрать из компонентов полноценную систему, которая будет работать везде.

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

morbo
()
Ответ на: комментарий от morbo

>У hal есть один небольшой такой недостаток - он не умеет монтировать

Вернее, _авто_монтировать.

но для тех у кого нет гнома или кде


..есть ivman?

AX ★★★★★
()
Ответ на: комментарий от morbo

> У hal есть один небольшой такой недостаток - он не умеет монтировать

А он и не должен уметь это делать. И цели такой у него не было - обучаться файловым системам и монтировать их. Все для чего он создан - он делает, а именно - трекинг появления новых устройств через dbus. lshal, вставь влешку, lshal. - вот для этого он и нужен

rx8620
()
Ответ на: комментарий от gena2x

> Чего-чего??? Это после X_11_ (!) R_7_(!) dot 6(!) делать X12? откуда дрова?

Это чисто спекуляции :)

Если объективно, то часть разумной критики X протокола сводится к тому что core часть протокола заметно устарела, там много ненужного, а все(тулкиты современные) все равно юзают расширения. Гоняя по сети битмапы, делая AA на клиенте и тп вместо того чтобы гонять строки

Соотвественно многое из того что есть в ядре протокола сейчас в ядре не нужно. Нужно более модульный протокол наверное. А изменение этого самого ядра протокола это и будет X12, когда дозреют.
То есть можно конечно поменять просто это самое ядро и доработать до существующих реалий, но как бы уже понятно что делать это не очень разумно - опять изменится, выпускать X13 ? Ну да , только учитывая современные темпы это будет слишком часто.

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

kernel ★★☆
()
Ответ на: комментарий от LamerOk

> Чувак, ты нереально доставил! )))

Это сейчас невозможно. И ? какие у вас гарантии что с ростом наворотов в видюхе там постепенно не появяться процессоры способные гонять урезанные версии X сервера. Тем более что если посмотреть историю - аппаратные X терминалы это тот еще девайс с точки зрения хардваре. А X например даже без MMU/FPU могли работать не так давно.

kernel ★★☆
()
Ответ на: комментарий от kernel

Бггг. Ты хоть понимаешь, что раскатываешь губу на далёкое будущее, в то время как нет даже далекого прошлого? Есть только _очень_ далёкое. )) Фришные иксы даже автоматическую развертку для аналогового сигнала осилить так и не смогли, а ты тут про икс сервер в видеокарте фантазируешь )))

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> Бггг. Ты хоть понимаешь, что раскатываешь губу на далёкое будущее, в

то время как нет даже далекого прошлого?


Эх вьюноша, вьюноша. Тголль вы, врунишка и .... Впрочем не будем. А чем это я ? А ! Да !

Это ваше «далекое будущие» «далекое» только для людей совсем молодых да ранних, которые народились, как «знатоки», всего год-два назад. На моей памяти развитие линукса и технологий вокруг него характеризовалось как и всякими «долгостроями» так и «внезапностью».

Более того, для тех кто, как вы, не сидит уткнувшись в эти самые изменения с целью троллинга, все это «далекое прошлое» вообще прошло мимо. Вроде тех изменений которые отслеживают задроты.

Есть только _очень_ далёкое. )) Фришные иксы даже автоматическую

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



Вот я и говорю - задроты. Сколько админю, никогда мне не было нужно думать про какие то «автоматические развертки для аналогового сигнала». Разве что году в 96 в связи с написанием моделайнов, не по необходимости а в связи с тягой к разным изврашениям, вроде тех которыми вы сейчас наслаждаетесь, вычитывая ченьнджлоги Хсов и флеймя по результатам на ЛОРе.

Плохо что тут из треда ушли вменяемые люди(вам большого доверия нету) , а то хотелось бы спросить что же это такое «автоматические развертки»!?! А то если сигнал развертки каждую долю секунды не подавать, автоматически, никакой картинки вообще не будет.

Если же вы имеете в виду «автоматичское определение параметров сигнала развертки на уровне X сервера», то во первых так и пишите, во вторых, опять же, это все ваш обычный троллинг.

Так как во первых параметры для моделайна научились снимать довольно давно, хотя и в 2000-х имхо с видеокарты, во вторых это все к драйверу видеокарыты какового могло не быть и долго, драйвера всего этого не держали и сейчас многие не держат, и в третьих, всякие визарды настройщики дисплея позволяли на эту проблему в принципе забить. Как все кто не «перекомпилирует Хы на любимой гентушечке» и делали.

Не все как вы фапают на «выжимание из техники» что она там вам должна. Это делается на уровне визардов/утилит настройки и зачем это в X автоматически кроме как для понтов и крутизны непонятно. То есть понятно что так лучше для некоторых ситуаций, но ваши дебильные ололоканья по этому вопросу свидетельствуют не о состоянии X а о состоянии вас. Причем свидетельствую однозначно.

а ты тут про икс сервер в видеокарте фантазируешь )))


Технически если с нуля, за бабло, с правильными спецами, сделать такой сервер для конкретной видеокарты сейчас займет времени в районе года. А то и меньше. Если есть заготовки - как у коммерческих Хсостроителей которые пишут X сервера для всякой аппаратной Xдряни без mmu.
Сервер конечно будет Х-уевый , да и скорее всего более тормознутый чем современные решения, так как надо думать как все эти расширения теперь гонять новым способом удобно. Но он будет.

Сдерживается это все не отсутсвием технической возможности, а отсутствием технико-экономической потребности. Ну и тем что текущая архитектура вроде mesa/DRI для этого не приспособлена - что стоимость увеличивает. Но все это реально может изменится «за один день» - технически ничего не поменяется но экономически окажется что решение выгодней с X сервером. И все.

Тем не менее чем больше будет расти мощность видеокарты, тем больше код который сейчас в драйвере гоняет центральный процессор будет переезжать на видеокарту. Безовсякого решения в виде Xов, чисто в рамках решения от конкретных вендоров в их коде. И наступить чисто технически, момент, когда код который

PS
А насчет производительности, можно делать пропатченную xlib для локальных приложений. И написать под нее соотвествующую «оптимальную111» остальную часть. «Потерь» вообще не будет. Приложения все сохранятся.

Но чегото никто из вменяемых людей этого делать не спешит. А есть много криков людей с ником ламер :) на форумах.

kernel ★★☆
()
Ответ на: комментарий от kernel

> И наступить чисто технически, момент, когда код который

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

Кстати OpenGL вообще говор был придуман вот как раз для этого. Это в чем то естественная конфигурации для рабочей станции. И вообще говоря, мы видим что писюки, фактически, превращаются именно в рабочую станцию с юникс, архитектурно и идеологически.

Так как чем например вызвана нехарактерная для рабочей станции обработка графики центрированная на центральный процессор ? Правильно, дешевизной общего решения при дорогом отдельном железе. В мире где ВСЕ могут себе позволить сопроцессоры графики и бог знает чего еще, из-за относительной дешевизны чипов, получится что для роста производительности нужно пихать много чипов - как это и было во времена рабочих станций юникс. Когда по сравниению со стоимостью решений классом выше в рабочую станцию можно было напихать относительно столько чипов, сколько их вообще было.

kernel ★★☆
()
Ответ на: комментарий от kernel

Зря я тебя похвалил. Настрочил много, но смешного мало.

Не все как вы фапают на «выжимание из техники» что она там вам должна. Это делается на уровне визардов/утилит настройки и зачем это в X автоматически кроме как для понтов и крутизны непонятно.


Расслабься, я уже давно понял, что ты пустозвон-теоретик, в глаза не видевший какую картинку выдавали иксы на аналогвый не LCD монитор при живом-то EDIDe, но «состаявшийся как специалист» много-много-много лет тому назад, которому ни 85 герц на 20 дюймов, ни 100 на 19 никогда не были нужны, поскольку это «выжимание из теники последнего и никому ненужное задротство», которое делалось в венде двумя щелчками мышки по утилите в трее. )))

Надеюсь, ты не будешь сидеть до конца своих дней за аналоговым моником в веса-режиме. )))

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

> Расслабься, я уже давно понял, что ты пустозвон-теоретик,

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

в глаза не

видевший какую картинку выдавали иксы на аналогвый не LCD монитор при



Круто. «Купи не лцд извращенный мионитор и страдай». :):):)

живом-то EDIDe, но «состаявшийся как специалист» много-много-много

лет тому назад, которому ни 85 герц на 20 дюймов, ни 100 на 19



никогда не были нужны, поскольку это «выжимание из теники последнего

и никому ненужное задротство», которое делалось в венде двумя


щелчками мышки по утилите в трее. )))



В линуксе это делалось выбиранием монитора из списка в утилите настройки :):):):) Что сраный гентослакварщик - любишь онал с линупсом ? Любишь понты ? Ну вот и саночки люби водить.

Надеюсь, ты не будешь сидеть до конца своих дней за аналоговым

моником в веса-режиме. )))



У меня все такие монииторы давным давно настроены, олух царя небесного.

kernel ★★☆
()
Ответ на: комментарий от AX

>..есть ivman?

А ivman умеет размонтировать по тайм-ауту и содержит рычаги, позволяющие нарисовать менюшку для извлечения не авторазмонтируемых устройств?

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

morbo
()
Ответ на: комментарий от rx8620

>А он и не должен уметь это делать. И цели такой у него не было - обучаться файловым системам и монтировать их. Все для чего он создан - он делает, а именно - трекинг появления новых устройств через dbus. lshal, вставь влешку, lshal. - вот для этого он и нужен

Я не говрю, что HAL должен уметь монтировать. Просто тут, насколько я понял, некоторые считают HAL средством автомонтирования. Я говорю о том, что нет единой взаимно интегрированной на всех уровнях системы автомонтирования и размонтирования. Чтобы можно было пользоваться и cat/cp/rsync/mv, и гномьими/кдешными программами, и авторазмонтированием по таймауту и извлечением смонтированного диска/флешки через меню.

morbo
()
Ответ на: комментарий от rx8620

>Все для чего он создан - он делает, а именно - трекинг появления новых устройств через dbus. lshal, вставь влешку, lshal. - вот для этого он и нужен

Вставил флешку - мосмотрел события с помощью udevadm monitor, написал правило автомонтирования в udev. HAL тогда вообще не нужен.

morbo
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.