LINUX.ORG.RU

Ответ на: комментарий от anonymous

> вы уже записали на винт новую либу lib1.so, у которой inode=70...
> и новый процесс захочет открыть lib1.so по ее имени, естественно...
> но ведь В ПАМЯТИ для ядра ВСЕ ЕЩЕ СУЩЕСТВУЕТ АССОЦИАЦИЯ inode50=lib1.so
> (старая либа)

В ядре нет ассоциаций inode->имя. Ассоциация имя->inode возможна, обратное неверно. Файл открывают по имени, получают иноду. Список открытых фалов (открытых инодов) лежит в памяти (для того, чтобы считать какой файл сколько раз открыли), но на имена эти иноды не явно не ссылаются :-) При открытии файла по имени выбирается тот инод, который записан на это имя на файловой системе.

> это хорошее техническое решение под лин :)
> но насколько это актуально для вин? а тем более на десктопе?

Насколько это актуально на десктопе? На десктопе не актуально, а на Terminal Server'е (тоже вроде бы десктоп, не находите?) - очень даже актуально. Да вдобавок ко всему, винду старательно пихают на сервер.

А вот как отпачить RPC locator на сервере, на который подключено 5 сотен клиентов? Можно его (локатор) остановить, но... Честное слово, у вас две трети системы наебнется при этом прежде, чем вы успеете апдейтер запустить :-) А уж что касается апгрейда mfc*.dll - это вообще сказка :-) Между прочим, их патчили чуть не каждые полгода... И также часто (и даже чаще) будут патчить CLR. Хреновая картина, верно?

Еще одна потрясающая "фича" виндов - это т.н. "сервисы" - это вообще песня :-) Ну и фирмовая притча - "объектно-ориентированность": Brush - объект. Thread - объект. Socket - объект. Service handle - объект. Для удаления каждого из этих объектов нужно применять свой собственный метод (впрочем, непрограммисты "кайфа" не поймут :-)).

> а насколько актуальна возможность горячей замены видеодрайвера?
> пусть вин в этом случае обязана делать перезагрузку, но ведь
> замена видеодрайвера - это редкая операция :)

Вы будете смеяться, но на юниксовых/линуксовых серверах "видеодрайвер" вообще не загружается :-) В принципе :-)

> glibc, glib, libc - это разные библиотеки или это просто сокращение одного и то же названия?

libc - основная библиотека практически всех функций
glibc == GNU libc
glib никакого касательства к ним не имеет :-)

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

>В ядре нет ассоциаций inode->имя. Ассоциация имя->inode возможна, обратное неверно. Файл открывают по имени, получают иноду. Список открытых фалов (открытых инодов) лежит в памяти (для того, чтобы считать какой файл сколько раз открыли), но на имена эти иноды не явно не ссылаются :-) При открытии файла по имени выбирается тот инод, который записан на это имя на файловой системе

плиз, проясните такой момент:

вот на винт уже записана новая либа lib1.so с inode=70... иноды, они ведь И НА ВИНТЕ(в файловой системе), И В ПАМЯТИ... а _в памяти_ все еще есть ассоциация lib1.so -> inode=50, но в этом иноде в памяти УЖЕ установлена пометка на удаление (и пометка на удаление установлена также в этом же иноде, но уже на винте?)... вот вы перезапускаете процесс, который снова отображает либу lib1.so... т.е. процесс по имени либы обращается к ядру... а что, ядро разве прежде всего будет искать инод либы на винте? а разве сначала ядро не просмотрит список ассоциаций имен и открытых инодов в памяти? и найдет там имя lib1.so, ассоциированное не с инодом 70, а с инодом 50 (старая либа)... вот почему я у Вас уточняю, не должно ли ядро В ЭТОТ МОМЕНТ ПРИНЯТЬ ВО ВНИМАНИЕ ПОМЕТКУ К УДАЛЕНИЮ, установленную в иноде 50 в памяти (и возможно на винте тоже?), чтобы решить: ВСЕ, ЭТУ ЛИБУ УЖЕ МОЖНО СЧИТАТЬ НЕСУЩЕСТВУЮЩЕЙ... и после этого ядро ищет по имени lib1.so в файловой системе новый инод 70, и грузит его в память

>Насколько это актуально на десктопе? На десктопе не актуально, а на Terminal Server'е (тоже вроде бы десктоп, не находите?) - очень даже актуально. Да вдобавок ко всему, винду старательно пихают на сервер

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

>Вы будете смеяться, но на юниксовых/линуксовых серверах "видеодрайвер" вообще не загружается :-) В принципе :-)

я действительно буду смеяться, ибо не кто иной как Вы сами в теме про генту сами опровергли ЭТОТ ЖЕ довод одного из гентушников :) и привели в пример Оракл :)

>glibc == GNU libc

т.е. glibc это синоним libc?

>glib никакого касательства к ним не имеет

а для чего она? что делает?

anonymous
()
Ответ на: комментарий от no-dashi

>В ядре нет ассоциаций inode->имя. Ассоциация имя->inode возможна, обратное неверно. Файл открывают по имени, получают иноду. Список открытых фалов (открытых инодов) лежит в памяти (для того, чтобы считать какой файл сколько раз открыли), но на имена эти иноды не явно не ссылаются :-) При открытии файла по имени выбирается тот инод, который записан на это имя на файловой системе.

Может в случае древнючих UNIX это и так, но в Linux при открытии файла создается file, который ссылается на dentry, которая ссылается на inode. Для любой inode, которая получена открытием файла из userspace всегда можно получить все т.н. алиасы через inode->i_dentry. Другое дело, что при удалении файла, dentry удаляется (unhash) из dcache.

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

> Может в случае древнючих UNIX это и так, но в Linux при открытии файла создается

Это уже некритично. Существенна только сама идея, как наиболее эффективным образом реализовать нормльную работу с файлами, и в особенности избежать "блокировки по открытию".

no-dashi ★★★★★
()

Господа, вы вы здесь спорите про то, кто сильнее - кит или слон! Я использую Linux с 1998 года и хочу рассказать след. историю: Мой коллега по работе ранее был ярым приверженцем Windows. Некоторое время назад он перешёл работать в другую контору (комм. банк). Недавно он с восторгом рассказал о своем опыте работы с Linux. Если кто знает систему IBSO (Новосибирской разработки), тот оценит преимущества связки Linux+ORACLE. Но более всего ему понравилась SAMBA. Эпитеты были не для печати и не в пользу Microsoft. Так что опыт показывает, что перевес в богатых конторах (типа УралСиб, Сбербанк и т.д.) идет в пользу Free xNIX. И аргументы любителей Выни детские - накладно оно это мелкософт.

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

Что то я ни про какого Юджина не слыхал, а вот про Митника и Линуса слыхал .... вот их мнение я послушал бы с удовольствием :)

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

ИМХО проблемы винды в том, что каждая 95, 98 ... это _новый_ продукт, с _новыми_ багами, в то же время Linux всегда один. Причина же, новая версия винды - новая покупка. Линукс же бесплатен. Кроме того, я считаю, модель развития ОС windows (новые возможности - новый продукт) показывает свою несостоятельность в плане безопасности. Работая майкрософт над одним продуктом, вероятно винда была бы более защищена. Мне кажется Longhorn это будет новая, более лучшеая и современная(из билютеней майкрософт) площадка для ..... вирусов.

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

1. ерунда 2. widnows (специально так написал) гораздо менее красива внутренне (у widnows её (внутреннеё красоты) вобще нет)

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

мне друг рассказывал про один случай...

в одном из универов (по-моему в Гарварде) ремонтники забетонировали (случайно) сервер с Linux (не важно какой)

когда сервер хотели про апгрейдить обнаружили что он забентован в стене...

перед этим прошло 4 года СТАБИЛЬНОЙ работы этого сервера....

anonymous
()

о чем он вообще говорит??? ОС - это прежде всего набор функций обеспечивающих доступ к устройствам

поэтому в Linux не может быть дыр больше чем в widnows,, дыры (которые быстро патчатся) есть в GNU Projects а не в Linux....

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

Линукс тоже здорово меняется. Но он меняется органично, потому что
изначально была заложена расширяемая как и у каждого линукса основа.
У мс была чудная nt и ужасные 95 без будущего + где-то в хвосте дос.
Когда они соединили все вместе, получилось как в анекдоте:
"Странно, если смешать килограмм варенья и килограмм говна, получится
два килограмма говна"...

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

Мммммм...... Странно слышать о том что одна ось сложнее другой...

Ребят, они не сложные. они просто РАЗНЫЕ. Дай челу который сидел на МАКе в руки винду - он ею плеватся будет, пока не привыкнет. То же самое с Виндой и Линухом.

А говорить, что какая-то ось сложнее другой - нуууу как говориться "Вам не нравятся кошки? Да вы просто не умеете их готовить."

Всему свое. Мне Линух. Кому-то фря кому-то еще что-то :)))

wanderlust
()

А не подскажут ли апологеты винды драйвер для ext2/ext3 под вин (rw), а то NTFS уже задрала своей производительностью. fat32 не предлагать, то еще повидло :-)

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