From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Led To: ALT Devel discussion list Date: Mon, 17 Apr 2006 17:53:15 +0300 User-Agent: KMail/1.9.1 References: <44439D25.30300@altlinux.com> <200604171727.23506.led@altlinux.ru> <4443ACCF.3050604@altlinux.com> In-Reply-To: <4443ACCF.3050604@altlinux.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200604171753.16252.led@altlinux.ru> Subject: Re: [devel] =?koi8-r?b?8M/XxcTFzsnFIGFwdC1jZHJvbSDXINPP19LFzcXOzs/N?= =?koi8-r?b?IM3J0sU=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2006 14:52:36 -0000 Archived-At: List-Archive: List-Post: В сообщении от 17 апреля 2006 17:57 Anton Farygin написал(a): > Led wrote: > > В сообщении от 17 апреля 2006 17:25 Anton Farygin написал(a): > >> Sergey Y. Afonin wrote: > >>> On Monday 17 April 2006 18:50, Anton Farygin wrote: > >>>> Т.к. ближайшие изменения навсегда и окончательно отменят наличие > >>>> /dev/cdrom и /media/cdrom, то соответственно возникает вопрос: > >>> > >>> Интересное решение... > >>> > >>>> В современном мире принято спрашивать про устройства у HAL. > >>> > >>> А в отрыве от apt-cdrom кто у него спрашивать будет ? Вот, допустим, > >>> я пару-тройку файлов хочу с CD скопировать. Вставляю диск, и... > >>> Где я его ищу ? > >> > >> ivman/pmount/KDE/Gnome - всё теперь завязано на этих службах > >> > >> Для себя я сделал вот так при монтировании CD: > >> CDROM=`hal-find-by-property --key storage.drive_type --string cdrom`; > >> DEVICE=`hal-get-property --udi $CDROM --key block.device`; > >> pmount $DEVICE cdrom > >> > >> монтируется в /media/cdrom > >> > >> Там можно ещё извратиться и спросить (например) volume label, но мне это > >> не нужно. > >> > >>>> При этом появляется возможность работы хоть с 10-ю приводами, но > >>>> появляется зависимость на запущенный hal. > >>> > >>> Для apt, может, и хорошо. А вот для всего остального - не уверен... > >> > >> Как минимум libxine придётся патчить, что бы он не искал /dev/dvd и > >> /dev/cdrom ;( > > > > час от часу не легче... :( > > > >> И это касается 90% софта, который у нас есть (и который не умеет > >> работать с hal'ом), но работает с устройствами, на которые обычно делали > >> симлинки. > > > > Если б меня спрашивали, то я бы сказал, что проще убить hal (или > > ограничить его нишей, где его место). А "весь софт не вногу - один hal > > вногу" - это в фортунки можно было бы... только несмешно почему-то... > > Может перечитаем классиков (на предмет "может в консерватории что-то > > подправить?")? > > Мы то можем перечитать.. а вот upstream считает ровно наоборот. upstream чего? Сорри, я просто не понял... :( > > И собственно правильно делает. Выпрямляет то, что криво изначально. Т.е. то, что флэшка с VFAT монтируется с codepage=utf8 (а есть ли вообще примеры vfat с utf8?) - это "выпрямление"? или то, что на флэшке оказывается раздел которого на самом деле нет, а те, что есть - всё равно монтировать вручную? -- Led.