Ну xdsl видимо считает, что в rpm-системах стандартный способ лишь один - установка rpm-пакета. |
А какже компиляция при каждом чихе? _________________ Ин дер гросен фамилие нихт клювен клац-клац ![]() |
andy ice писал(а): ну, видимо пройти все программы и библиотеки и составить дерево вызовов. т.е. кто какие библиотеки подгружает и потом найти те программы, которые используют требуемую.
Все-таки надо программировать, а последовательности действий нет? Ну и то ладно. Даже если считать, что это решение задачи, что неверно. Ибо не станет ясно, к какому программному продукту относится программа, загружающая библиотеку. Хотя предложенный вариант, на мой взгляд - нереален. "пройти все программы и библиотеки" ... А если это не .dll, а txt, ехе, doc и т.д.? andy ice писал(а):
а в линуксе как? про rpm и прочая можно не упоминать, ибо программы бывают ставятся не через rpm, apt и прочая Ключевое слово - "бывают". В виндовс тоже бывает программа ставится не через "Установка, удаление программ". Просто копируют, бывает. Поэтому остановимся на .rpm, как одном из стандартных способов установки. Найдите такой стандартный в виндовс, будем дискутировать дальше. |
Fakir писал(а): Ну xdsl видимо считает, что в rpm-системах стандартный способ лишь один - установка rpm-пакета.Неправда ваша, дяденька. Не считаю я так ![]() |
andy ice писал(а): А какже компиляция при каждом чихе?Об этом мы еще поговорим, но не уходите от темы. Вы хотели задачу, вы ее получили. |
xdsl писал(а): Какому прогр.продукту принадлежит файл c:\windows\system32\blablabla.dll? У меня 98. Решил попробовать. Воспользовался FAR'ом. Зашел в C:\WINDOWS\SYSTEM\, взял первую попавшуюся dll-ку, ей оказалась 3ivx.dll. Я не знал, какому пакету она принадлежит. Зашел в C:\Program Files\, нажал "Поиск", в "масках файлов" набрал *.exe;*.dll, в поле "содержит текст" набрал 3ivx.dll. Через 3 секунды я уже знал, какому пакету принадлежит 3ivx.dll - им оказался K-Lite Codec Pack. Может мне просто повезло? Выбрал из C:\WINDOWS\SYSTEM\ еще одну dll-ку: roboex32.dll. Тоже не знал, из какого она пакета. Проделал те же действия. Оказалось, она из PowerQuest Partition Magic. Опять повезло? Ну, не знаю, может быть. Взял еще одну dll-ку, о происхождении которой не в курсе - xenroll.dll. Снова проделал то же самое. Не найдено. Тогда, может быть она системная? Зашел в папку с дистрибутивом, в Поиске задал "маску файлов" xenroll.dll, текст поиска убрал, поставил флажок "искать в архивах". Так и есть, содержится в win98_42.cab. Значит она - часть системы. xdsl, я ответил на ваш вопрос? Я ничего не программировал, последовательность действий изложил. |
xdsl писал(а): Поэтому остановимся на .rpm, как одном из стандартных способов установки.да и вообще пример некорректный. к программированию отношение имеет весьма далекое, что и показал moishe _________________ Ин дер гросен фамилие нихт клювен клац-клац ![]() |
andy ice писал(а): во-вторых если бы так было нужно, то и под виндовс создали бы подобную рпм-у базу данных и прочая |
Ой, звиняйте! Не обратил внимания на первоначальную постановку задачи: xdsl писал(а): Найти, какому из установленных (стандартным образом) в системе программных продуктов принадлежит указанный файл.Кхе... Начнем с того, что Linux - это не ОС, это ядро. Соответственно, никаких "стандартных образов" установки продуктов в ядре быть не может. В некоторых ОС на базе ядра Linux действительно существует стандартный способ установки, в частности, для дистрибутива RedHat и его производных - это rpm. "Стандартным" он стал де-факто, просто потому, что это действительно удобно, и даже перекочевал в другие, не родственные РедХату дистрибутивы. Что касается Windows - это не только ядро, это полноценная ОС (точнее сказать, семейство ОС), и в ней могла бы быть стандартная процедура установки. На эту роль претендует msi. Но чаще всего каждый разработчик пишет свою процедуру установки. Для нее у Микрософта есть рекомендации, которые разработчик, впрочем, волен проигнорировть - тут Микрософт предоставляет полную свободу творчества. Однако, многие разработчики придерживаются хотя бы одной рекомендации: они вписывают в HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<имя_класса_продукта>\UninstallString командную строку для запуска деинсталлятора их продукта. При этом они могут воспользоваться одним из имеющихся в системе деинсталляторов (тогда они должны сформировать для него файл-параметр в нужном формате), могут написать чисто свой деинсталлятор (но все равно нужно будет передать ему список подлежащих деинсталляции файлов). Если выполнение этой минимальной рекомендации считать "стандартным образом" установки продукта, то этой информации вполне достаточно, чтобы ответить на ваш вопрос о принадлежности произвольного файла. Если я чего напутал в терминах, или не в курсе последних веяний - прошу прощения, невежествен. |
Предположим, тот факт, что программные продукты для любой оси можно устанавливать самопальным инсталлом и даже ручками, не учитываем (мне, кстати, непонятна нервная дрожь присутствующих по поводу неRPM-установки. Например, под виндовс тот-же far скопировать в любой каталог, и вуаля - установился!)
Т.е. можем принять в некотором приближении, что решение задачи для линукс можно строить на основе rpm, а для виндовс - на основе строгого следования рекомендациям майкрософт. Если по базовым положениям возражений нет, снова формулирую задачу, которая, на мой взгляд, в линуксе программируется быстрее и элегантнее, чем в виндовс: Найти, какому из установленных (стандартным образом) в системе программных продуктов принадлежит указанный файл. P.S. По возражениям типа "чего тут программировать, и так можно найти" хочу сказать, что, например, с распознаванием образов человек справляется гораздо точнее многих программ, что (почему-бы это?) не отбивает охоту разрабатывать алгоритмы распознавания образов. P.P.S. to moishe. Ваш алгоритм ручного поиска, имхо, обладает некоторыми недостатками: 1. файл может быть несвязан вызовами с другими файлами прогр.продукта (пример - файл документации, примеров, отдельный исполняемый и т.д.). 2. файл может иметь обращения к другим файлам прогр.продукта, но на него ссылок нет. 3. Как определяется, какой это программный продукт - по имени каталога в програмфайлес? А если ссылки имеются, но разбросаны по разным каталогам (не обязательно системным и не в програмфайлес)? В принципе, как ручной вариант его с некоторыми оговорками можно принять, причем для любой оси. Но как его запрограммировать для получения стопроцентного результата, лично я не представляю. |
xdsl писал(а): какому из установленных (стандартным образом) Хорошо, а теперь давайте выясним, какой же способ для линукса является стандартным? Система RPM - не в каждом дистрибутиве. Далее вопрос - а если устанавливается пакет из RPMS (то же ведь "стандарт"), будет ли в базе RPM сведения о том, какие файлы получаются из компилирования RPMS? Просто я так не делал и знать не знаю - будет или нет. Кстати есть пакет (и думаю не один такой), установка которого - компиляция из исходников. Иного варианта просто нет. Если есть какие-то проблемы, то высылают набор бинарников, скомпилированных наиболее близко к системе. Впрочем данный пример в теорию xdsl-я не вписывается, потому отбросим его. _________________ Ин дер гросен фамилие нихт клювен клац-клац ![]() |
А ведь правда. Для линукса установка путем компиляции из исходников - это один из стандартных способов установки, причем исторически первый и до сих пор широко используемый, и главное, что свидетельствует в пользу его стандартности - он применяется на всех без исключения дистрибутивах. Для производителей оборудования это фактически единственный способ. Если, например, к сетевушке производитель пожелал приложить линуксовый драйвер, как он выглядит? Несколько файлов *.с, *.h, configure, MAKEFILE, а в install.txt написано:
To install this product type: $ ./configure $ make $ make install Стандарт, однако. Я думаю, если отбросить несколько туманное уточнение "стандартным образом", поставленная задача неразрешима в общем случае. Единственный способ решать ее надежно и эффективно - это вести базу данных, в которую информация о принадлежности файлов будет вноситься на этапе установки, причем без ошибок и исключений. В виндовс такая база, вообще говоря, системой не предусмотрена, хотя вести ее можно, такие примочки от сторонних разработчиков реально существуют, сам видел. В линуксе есть RPM, но он не исчерпывает всех стандартных способов установки продуктов. Существует ли для линукса всеобъемлющая система контроля файлов, мне не известно. Раз уж тут речь идет о программировании, я бы поставил такую задачу: Написать для виндовс и линукса программу, которая, будучи системным сервисом (демоном) отслеживает процесс установки программных продуктов и ведет базу данных о принадлежности каждого файла тому или иному продукту. |
andy ice писал(а): xdsl писал(а): какому из установленных (стандартным образом) Никаких оговорок. Читайте исходную формулировку, задача не изменилась ни в одном слове. andy ice писал(а): Тем более что к программированию таки этот пример отношение имеет наислабейшее. Т.е. в виндовс эта задача программируется одним системным вызовом? не программируется вообще? Программу для виндовс составить элементарно, просто, сложно, невозможно, неохота (нужное подчеркнуть)? Поясните, плиз. andy ice писал(а): Хорошо, а теперь давайте выясним, какой же способ для линукса является стандартным?Давайте выясним, какой способ для виндовса является стандартным? Устанавливать можно где угодно и как угодно, как в виндовс, так и в линукс. Можно руками по каталогам файлы растолкать и конфиги (реестр) забить. Но все это - не стандарт. Поэтому предлагаю для линукса взять чистый rpm-дистрибутив, а для виндовса - скурпулезное следование рекомендациям макрософт по установке. Для чистоты эксперимента. Что не нравится? Вообще, меня поражает подход участников дискуссии. Не разобираться, как решить задачу, а искать причины, по которым ее решать не надо. Ну прям как американцы, чессслово ![]() |
moishe писал(а): Написать для виндовс и линукса программу, которая, будучи системным сервисом (демоном) отслеживает процесс установки программных продуктов и ведет базу данных о принадлежности каждого файла тому или иному продукту.Эта задача, на мой взгляд - неразрешима. Определить, что идет именно процесс установки, а не банальное копирование, имхо - невозможно. |
xdsl писал(а): Программу для виндовс составитьxdsl писал(а): для линукса взять чистый rpm-дистрибутивxdsl писал(а): Не разобираться, как решить задачу_________________ Ин дер гросен фамилие нихт клювен клац-клац ![]() |
Кстати, может даже наискурпулезнейшее следование инструкциям майкрософт не обеспечит наличие единой базы информации об установленных продуктах? Если так, задача в рамках виндовс действительно неразрешима и придется ее снять, т.к. сравнивать программный код с его отсутсвием бессмысленно. В рамках данной дискуссии, конечно.
Так-что, уважаемые оппоненты, либо признайте принципиальную неразрешимость задачи в рамках виндовс и тогда я сформулирую следующую, либо давайте ее решать и сравнивать полученный код. Пусть даже скриптовый, bash vs wsh. Или бинарный, мне - без разницы. |
andy ice писал(а): xdsl писал(а): Программу для виндовс составитьГде? andy ice писал(а): xdsl писал(а): для линукса взять чистый rpm-дистрибутивАга. А для виндовс - тоже ограничения, потому-что в общем случае задача там тоже не решается. andy ice писал(а): xdsl писал(а): Не разобираться, как решить задачуКакое? |
xdsl писал(а): Где? xdsl писал(а): Агаxdsl писал(а): Какое?тем более библиотеки лежат всего в двух местах. нее, РАЗДЕЛЯЕМЫЕ библиотеки. это prigram files\common files\ и windows\ _________________ Ин дер гросен фамилие нихт клювен клац-клац ![]() |
Снова очередные отговорки. Забавные такие. То, вишь, уже за нас все написали умные дяди (где программа, кстати? решает ли она поставленную задачу?), то банальным ручным поиском типа все можно сделать (определенный интеграл, кстати, тоже можно руками посчитать, даже быстрее выйдет, чем программу писать, правда - не всегда). Отнюдь не все ручками можно сделать, причем в любой оси. Примеры были мной приведены выше и успешно проигнорированы.
Тем не менее, надеюсь, что решение задачи для виндовс от виндовс-программистов все-таки дождусь, чтобы сравнить с ним функционал своей маленькой элементарной программы, решающей задачу на rpm-дистрибутиве. Напоминаю условие задачи: Найти, какому из установленных (стандартным образом) в системе программных продуктов принадлежит указанный файл. Для своего линукс-решения я выбрал стандартом rpm. Лично у меня 1607 rpm-пакетов на текущий момент в домашней системе, так-что программка получилась очень полезной. Для вашего виндовс решения сами выбирайте стандарт из общепринятых способов установки. Предлагаю просто побуквенно следовать рекомендациям майкрософт. Для апологетов виндовс, думаю, это то, что нужно. Не нравится - предлагайте свой стандарт для виндовс, мне без разницы, меня интересует только эффективность кода. Реагировать на возгласы Цитата А о чем говорить? xdsl не привел задач, где бы было показано преймущество программирования под линуксом перед виндовсом.
ЗЫ Ну пусть даже, 4) отказ решать задачу без объяснения всяких причин. Типа, "вот не буду и все, неахота и ляниво..." ![]() |
moishe писал(а): Начнем с того, что Linux - это не ОС, это ядроКак-то пропустил, но по моему, вы не правы. Операционная система и ядро - неравноположные вещи (вроде как стеклянный и зеленый). А линукс - это именно операционная система, т.е. "комплект программных изделий, которые совместно управляют ресурсами системы и процессами, использующими эти ресурсы при вычислениях" По крайней мере дедушка Таненбаум, при всей его нелюбви к линуксу, считает линукс, unix, солярис, bsd и виндовс - операционными системами. Он даже дос называет операционной системой. Извиняюсь за занудство, но просто не хотел-бы услышать "линукс - не ос" на каком-нибудь экзамене от своих студентов, часто тусующихся в форуме. Я им лебедя влеплю за это, а они не поймут - за что ![]() |
xdsl писал(а): Тем не менее, надеюсь, что решение задачи для виндовс от виндовс-программистов все-таки дождусь, чтобы сравнить с ним функционал своей маленькой элементарной программы, решающей задачу на rpm-дистрибутиве. У меня тоже есть такая программка! - rpm -f <file> ![]() xdsl писал(а): Извиняюсь за занудство, но просто не хотел-бы услышать "линукс - не ос" на каком-нибудь экзамене от своих студентов, часто тусующихся в форуме. Я им лебедя влеплю за это, а они не поймут - за чтоДискриминация по ОСевому признаку? ![]() Значит за "Windows не ОС, а оболочка дешовая" можно сразу 5 автоматом ![]() Последний раз редактировалось: Fakir (2006.06.07 08:29.37), всего редактировалось 1 раз |
Не, вы посмотрите какой зануда. "Я выбрал rpm" а остальные линуксы значит в топку. Надоело говорить с человеком, котрый кроме себя ничего не слышит _________________ Ин дер гросен фамилие нихт клювен клац-клац ![]() |
xdsl
вы имеете в виду под стандартным методом установки. в windows систему "установка удаление програм" в Linux систему rpm-пакетов, так? |
xdsl писал(а): не хотел-бы услышать "линукс - не ос" на каком-нибудь экзамене от своих студентов, часто тусующихся в форуме. Я им лебедя влеплю за это |
Касательно самой задачи. Если мы в линуксе ограничиваемся установкой _только_ через RPM, давайте в винвовс ограничиваться установкой _только_ через Microsoft Installer.
Я не знаю, есть ли в msi встроенная функция контроля файлов, надо будет почитать на досуге, но если есть - будем ей пользоваться, если нет - тогда действительно придется что-то допрограммировать. Но в таком варианте задача вполне разрешима. Вообще же эта задача ничего не говорит о преимуществах программирования под виндовс или линукс, она лишь говорит об удобстве использования RPM. Если на вашем линуксе нет RPM, или вы не считаете его стандартным способом установки, а предпочитаете все ставить через configure, make, make install, то преимущество линукса становится далеко не очевидным, хотя, возможно, оно и есть. |
moishe писал(а): Касательно самой задачи. Если мы в линуксе ограничиваемся установкой _только_ через RPM, давайте в винвовс ограничиваться установкой _только_ через Microsoft InstallerДавайте!!! Об этом твержу на протяжении кучи постов. Жду программу под виндовс. |
moishe писал(а): Будете не правы. Ведь это всего лишь терминологическая казуистика, не разбираться в ней - не значит не понимать сути. "Виндовс - не ос" - и это тоже правда.Вы правы и не правы одновременно, благодаря именно этой терминологической казуистике. Подобное понимание приходит с опытом и годами. К сожалению, господа студенты ни тем ни другим не обладают в достаточной степени, поэтому и получат лебедя. Не за то, что назвали линукс неосью, а за то, что не смогут это обосновать |
Fakir писал(а): Значит за "Windows не ОС, а оболочка дешовая" можно сразу 5 автоматом |
xdsl писал(а): Похоже, Fakir, вы меня основательно подзабыли. Уважаемый xdsl, Вас я никогда не забуду! Это типа юмор. Будем считать, что шутка не удалась ![]() |
xdsl писал(а): Жду программу под виндовс. |
|
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах Вы не можете вкладывать файлы Вы можете скачивать файлы |