По сравнению с Unix, за последний год основные серверные Linux дистрибутивы значительно улучшили свои показатели надёжности, в то время как простой Windows 2003 увеличился на примерно 25%. Эта информация была собрана в результате опроса (http://www.iaps.com/2008-server-reliability-survey.html) компанией Yankee Group.
Опрос также показал значительный рост интереса к Ubuntu в корпоративном секторе, хотя раньше этот дистрибутив был в основном известен в качестве ОС для рабочих станций.
Глобальное исследование надёжности серверных ОС 2007-2008 показало результаты, значительно отличающиеся от данных 2006 года, когда администраторы Windows серверов сообщали о меньшем времени простоя, по сравнению с Linux серверами - что вызвало значительные споры и разногласия.
Респонденты заявили, что в течение 2007 и 2008 годов Линукс дистрибутивы от Red Hat и Novell увеличили свою надёжность в среднем на 75%. Исследование показало, что время простоя Windows 2003, тем временем, увеличилось на 2...URL: http://news.zdnet.co.uk/software/0,1000000121,39386041,00.htm?r=2
Новость: http://www.opennet.me/opennews/art.shtml?num=15359
маловато 700 человек для таких выводов..
С чего это Linux стал Unix'ом?
>С чего это Linux стал Unix'ом?С чего это Вы сделали такой вывод? Даже янкитруп пишут, что Unix -- это AIX/HPUX/Solaris :)
"Время простоя"? Всмысле, "uptime"?
> "Время простоя"? Всмысле, "uptime"?это скорее сумма "stoptime"-ов
Ааа.. понял.
Строго говоря, "сумма downtime".
прочитал название новости и подумал что гетзэфактс, больно часто их видел =))
А вообще так, нормально, но 700 человек думаю не так уж и много...
Скока линуксоидов нашли знакомых столько и опросили =))
У нас Gentoo Linux, 50 серверов - real time кластер.
Время простоя несколько минут в год на ВСЕ сервера, если считать, что причина простоя была связана с ОС. Гораздо больше времени простоя связано с электропитанием и перебоями доступа в интернет
Пользователям, как правило, без разницы. У меня один из серверов на ALT Linux 2.4 Master с несколькими минутами простоя (ядро) несколько лет работает, если так считать... другое дело, что однажды полгорода вырубило -- тогда падало питание, и пару раз с маршрутизацией чудеса творились. В сумме с сутки будет, а за пределами корпуса интересна как раз сумма.
А у меня сервак на MSDOS,
запустил спец-секретную утиль,int i;
while(1) {
i++;
i--;
}постой 2 нано-секунды.
>постой 2 нано-секунды.постоял, видимо, намного дольше...
Однако все это реклама и оценивать здесь можно только качество рекламы :)
Если я не считаю себя специалистом по рекламе, то читать это и вникать в детали незачем....
Да какая нафиг реклама - в Windows 2003 установка заплаток на браузер требует перезагрузки сервера! Это-ж караул просто!
>Да какая нафиг реклама - в Windows 2003 установка заплаток на браузер
>требует перезагрузки сервера! Это-ж караул просто!Браузер на сервере? на варезники ходить? для windows update дыры не критичны.
Другой вопрос - обновление называется "заплатка для браузера" а что в нём на самом деле лежит только MS знает.
>Браузер на сервере? на варезники ходить? для windows update дыры не критичны.скажете может как его удалить? только без извращений, а то потом говорят что юникс системы сложные, а вин-системы легки в администрировании =))
>Другой вопрос - обновление называется "заплатка для браузера" а что в нём
>на самом деле лежит только MS знает.+пицотыщмильёноу
> Браузер на сервере? на варезники ходить?Зачем, лучше осла на сервант поставить круглосуточно работать. Кучу полезных прог можно закачать и фильмов.
>Да какая нафиг реклама - в Windows 2003 установка заплаток на браузер
>требует перезагрузки сервера! Это-ж караул просто!А если там Exchange Server стоял - это не караул, это 0.5 .. 2 часа отдыха от корпоративной почты.Круто, yeah.
Во. 2.6.25 вышло, пойду компилять.... А то от вас тут простой один.
>Во. 2.6.25 вышло, пойду компилять.... А то от вас тут простой один.И сказал он даун тайму:
экой ты простойКазнить нельзя-помиловать :)
>Во. 2.6.25 вышло, пойду компилять.... А то от вас тут простой один.ты уже опоздал.... ;)
i can wait
Да все что пишут про стабильность винды это фуфло !!! Хотя 2003 тянет лучше :-)
Ферма из десятка терминальных серверов (напялен цитрикс), в течении рабочего дня приложения пользователей так винду замучивают, что если они ночью не перезагрузятся, то на следующий день их так раскорячивает, в ступор просто! (вот и приходится ребут ставить на ночь). Линуксовые серваки (внутренние сервисные и брэндмауэр) работают годами !!! как верно подмечено если б не перебои питания.
Это мне напоминает про среднюю температуру в больнице. А может это просто опыт и знания админов выросли а не надёжность систем?
>Это мне напоминает про среднюю температуру в больнице. А может это просто
>опыт и знания админов выросли а не надёжность систем?А если поговорить о надежности - в Windows как ни крути, а заменить выполняемое в данный момент файло без ребута проблематично.Особенно весело с DLL - они загружены кучей программ вплоть до процессов системы.Как ни крути а просто выгрузить и заменить - не выйдет.
и все это связано с виртуальным адресным пространством. dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее.
>и все это связано с виртуальным адресным пространствомне более чем с тупорылой политикой мягкотелой конторы.
В нормальных системах заюзанную шареную либу без проблем можно переписать,
а если она не полностью зачитана (и в таком случае не может быть переписана,
равно как и любой бинарь в подобном случае) - то уж переименовать ее и создать новую
с оригинальным именем - нет проблем.
Последующий рестарт ПРОГРАММ, использующих сию либу - уже будут с ее новой версией.Так работают системы, от которых нужна работа, а не уровень продаж.
>dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее.где таритесь?? ;)
>[оверквотинг удален]
>не более чем с тупорылой политикой мягкотелой конторы.
>
>В нормальных системах заюзанную шареную либу без проблем можно переписать,
>а если она не полностью зачитана (и в таком случае не может
>быть переписана,
>равно как и любой бинарь в подобном случае) - то уж переименовать
>ее и создать новую
>с оригинальным именем - нет проблем.
>Последующий рестарт ПРОГРАММ, использующих сию либу - уже будут с ее новой
>версией.Че? Каша какая-то в голове. В нормальных системах - это отделение файлового объекта от его имени в слое VFS, в результате чего имя файла отделено от него самого, и его можно удалять, vnode же останется, пока используется. А в винде жесткая привязка по имени, поэтому файл намертво залочен.
>>dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее.
>
>где таритесь?? ;)В учебнике по операционным системам. Любая современная ось это использует - text-страницы бинарника мапятся непосредственно из его файла, данные процесса swap-backed. Text-страницы - file-backed, но механизм подкачки тот же самый.
>Че? Каша какая-то в голове. В нормальных системах - это отделение файлового
>объекта от его имени в слое VFS, в результате чего имя
>файла отделено от него самого, и его можно удалять, vnode же
>останется, пока используется. А в винде жесткая привязка по имени, поэтому
>файл намертво залочен.и в каком же месте я противоречу вашим светлым мыслям, о великий?
кашки вы где-то в другом месте хлебнули.>В учебнике по операционным системам. Любая современная ось это использует - text-страницы
>бинарника мапятся непосредственно из его файла, данные процесса swap-backed.
>Text-страницы - file-backed, но механизм подкачки тот же самый.У кого еще каша...
своппинг и маппинг перепутать и обозвать одним и тем же...
Своппинг использует маппинг, но не наоборот. А раз не наоборот - то называть одно
другим во всех случаях нельзя. А именно этим товарисч и отметился:"dll-ки являются swap'ом для себя"
не swap'ом они для себя являются, а мапятся в процесс.
>>Че? Каша какая-то в голове. В нормальных системах - это отделение файлового
>>объекта от его имени в слое VFS, в результате чего имя
>>файла отделено от него самого, и его можно удалять, vnode же
>>останется, пока используется. А в винде жесткая привязка по имени, поэтому
>>файл намертво залочен.
>
>и в каком же месте я противоречу вашим светлым мыслям, о великий?
>кашки вы где-то в другом месте хлебнули.Каша и противоречие в том, что открывать исполняемый бинарник на запись для его замены - грзяный хак. Правильный способ апдейта - его unlink() и создание нового, что опирается на вышеуказанное отделение имени файла от самого файла. И, следовательно, это отделение в *nix, коли уж шло сравнение с виндой, должно было быть четко и ясно описано.
>[оверквотинг удален]
>
>У кого еще каша...
>своппинг и маппинг перепутать и обозвать одним и тем же...
>Своппинг использует маппинг, но не наоборот. А раз не наоборот - то
>называть одно
>другим во всех случаях нельзя. А именно этим товарисч и отметился:
>
>"dll-ки являются swap'ом для себя"
>
>не swap'ом они для себя являются, а мапятся в процесс.Марш в учебник - все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш для дисковых объектов. У операционной системы метод един - paging. Будет ли это anonymous backing свопа или вполне себе именованный файл - без разницы. В обоих случаях ось может спокойно выкинуть страницы файла из ОЗУ и потом подгрузить их обратно при надобности.
>Каша и противоречие в том, что открывать исполняемый бинарник на запись для
>его замены - грзяный хак.разговор был возможно или нет.
Кста, об исполнимых бинарях я действительно перегнул. Они блокирутся при exec()е.
Но либы - нет (хотя тут вопрос доступа и желаний самой программы).
Посему даже используемые либы можно открыть на запись и переписать.
Другое дело, что проги такого не ожидают и просто падают как только управление
доходит до подмененного объекта. Ессьно, это нельзя рассматривать как метод обновления,
а мы этого и не делаем.
>Правильный способ апдейта - его unlink()
>и создание нового, что опирается на вышеуказанное отделение имени файла от
>самого файла. И, следовательно, это отделение в *nix, коли уж шло
>сравнение с виндой, должно было быть четко и ясно описано.эт все понятно.
>Марш в учебникТак и добавляй же сразу, что в учебник по бздям.
>- все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>для дисковых объектов.Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз дом родной, т.к. это самая быстрая
память в системе (после кешей проца).
>У операционной системы метод един - paging. Будет
>ли это anonymous backing свопа или вполне себе именованный файл -
>без разницы. В обоих случаях ось может спокойно выкинуть страницы файла
>из ОЗУ и потом подгрузить их обратно при надобности.Ну вот и славно. И ты прав - и я прав. Нужно было лишь изначально оговориться о чем речь.
У Линуха нет такой любви к свопингу. Работа с файлами и девайсами (даже тем же свопиком)
идет через буфера ОЗУ. Свопик (кстати, тоже буферизированный) используется лишь при нехватке ОЗУ. Если же ее хватает - своппинг не будет иметь место.
>Посему даже используемые либы можно открыть на запись и переписать.
>Другое дело, что проги такого не ожидают и просто падают как только
>управление
>доходит до подмененного объекта. Ессьно, это нельзя рассматривать как метод обновления,
>а мы этого и не делаем.Хехе. Вон, человек ниже доказывает, что так переписывать - и есть самый правильный способ :)
>Так и добавляй же сразу, что в учебник по бздям.
>>- все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>>для дисковых объектов.
>Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз
>дом родной, т.к. это самая быстрая
>память в системе (после кешей проца).В учебник по операционным системам. Архитектурные принципы те же (ОЗУ лишь кэш для диска), и разница лишь в константах тюнинга (политиках замещения кэша).
>[оверквотинг удален]
>>ли это anonymous backing свопа или вполне себе именованный файл -
>>без разницы. В обоих случаях ось может спокойно выкинуть страницы файла
>>из ОЗУ и потом подгрузить их обратно при надобности.
>
>Ну вот и славно. И ты прав - и я прав. Нужно
>было лишь изначально оговориться о чем речь.
>У Линуха нет такой любви к свопингу. Работа с файлами и девайсами
>(даже тем же свопиком)
>идет через буфера ОЗУ. Свопик (кстати, тоже буферизированный) используется лишь при нехватке
>ОЗУ. Если же ее хватает - своппинг не будет иметь место.Да есть, см. выше...
>Хехе. Вон, человек ниже доказывает, что так переписывать - и есть самый
>правильный способ :)видать, он ни разу не пробовал даже жалкую сошку находу переписать :)
>>Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз
>>дом родной, т.к. это самая быстрая
>>память в системе (после кешей проца).
>
>В учебник по операционным системам.учебники - хорошо :) но учебники далеко и серьезно отстают от _текущего_ ядра Линукс.
Ну что поделаешь, если его пишут/оптимизируют, не особо взирая на классические стандарты (с POSIX он тоже не полностью совместим), но с обратной совместимостью для user-level'a? :)
За сим, учебники стоит читать лишь по началу. Потом уже нужно читать только ядро.
Иначе, адекватность будет лишь мнимой.
>Архитектурные принципы те же (ОЗУ лишь кэш для диска)нет. В корне не согласен :)
Это внешне невооруженным глазом так кажется, что ОЗУ лишь кеш.
И не вдаваясь в подробности можно так думать и все будет замечательно.
На работу системы такое расхождение мнения админа с работой ядра никак не скажется.
Но дело как раз в том, что архитектура рассматривает загрузку с диска как ситуацию,
когда нужного блока во внутренних структурах VFS нет.
Так он написано.
Чем оно кажется со стороны - дело десятое :)
>и разница лишь в константах тюнинга (политиках замещения кэша).Ну, эти константы в Линухе и BSD разные, и их назначение разное.
Посему, не буду никак столь разные множества рулей коментировать :)
>[оверквотинг удален]
>>В учебник по операционным системам.
>
>учебники - хорошо :) но учебники далеко и серьезно отстают от _текущего_
>ядра Линукс.
>Ну что поделаешь, если его пишут/оптимизируют, не особо взирая на классические стандарты
>(с POSIX он тоже не полностью совместим), но с обратной совместимостью
>для user-level'a? :)
>За сим, учебники стоит читать лишь по началу. Потом уже нужно читать
>только ядро.
>Иначе, адекватность будет лишь мнимой.Вы путаете учебники с книгами по ядру конкретной ОСи или стандартами. Они да, устаревают. А фундаментальные архитектурные принципы, излагаемые в общих учебниках по операционным системам, они не меняются.
>[оверквотинг удален]
>Это внешне невооруженным глазом так кажется, что ОЗУ лишь кеш.
>И не вдаваясь в подробности можно так думать и все будет замечательно.
>
>На работу системы такое расхождение мнения админа с работой ядра никак не
>скажется.
>Но дело как раз в том, что архитектура рассматривает загрузку с диска
>как ситуацию,
>когда нужного блока во внутренних структурах VFS нет.
>Так он написано.
>Чем оно кажется со стороны - дело десятое :)Это вам так со стороны кажется. Но архитектурно - это именно кэш, я выше по треду названия упоминал, куда смотреть.
Если так не доходит, можете по аналогии посмотреть на кэш любого современного процессора - у него прямого доступа к памяти точно так же нет, все проходит через кэш.
>Вы путаете учебники с книгами по ядру конкретной ОСи или стандартами. Они
>да, устаревают. А фундаментальные архитектурные принципы, излагаемые в общих учебниках по
>операционным системам, они не меняются.извиняюсь, но "уморил" :)
Если будет обнаружено, что нечто "вот это" если его сделать "вот так" и
все нечнет летать быстрее - то никто из разработчиков и ухом не моргнет заюзать
этот метод для внутриядерных делов, подходит сей метод к "фундаментальным архитектурным принципам" или нет и будет прав. Админу/клиенту/пользователю нужна производительность,
а не абстрактные науки.
Более того, я не берусь утверждать, что такого не было уже в истории Линукса.
Скорее наоборот, было (хотя бы потому, что он не полностью POSIX совместим).
И можете меня посылать в любые книги за любыми названиями, но работа Линукс ядра (которое есть авторити де-факто по архитектуре самого себя %) никуда не денется.
>Это вам так со стороны кажется. Но архитектурно - это именно кэш,
>я выше по треду названия упоминал, куда смотреть.да все понятно. Сути это не меняет. Размер внутренних стурктур VFS даже считаются
в глобальный "Cache".
Вобщем, "называй меня как хочешь, мой господин" %)
Просто код Линуха построен на том, что все живет в памяти, а если чего нет - подгружается.
Это следует как минимум из названий функций и коменариев.
Остальное - кому как нравиться :)Понимаете, у Линкса очень специфичный отец ;)
Ему главное - технологии, а не кто где что как назвал и какие права на это заимел.
И - как мы видим - это работает :)
>Если так не доходит, можете по аналогии посмотреть на кэш любого современного
>процессора - у него прямого доступа к памяти точно так же
>нет, все проходит через кэш.1. я не утверждал, что данные файлов проходят НЕ через ОЗУ
2. вы ищете аналогию в архитектуре процессора и ядра. В данном случае оно совпало лишь по одной причине: буферизация - это путь ускорить работу. Это справедливо в очень многих системах. И, вообще, к данному спору никак не относится. Я не оспаривал пользу кеширования.Может как раз в том и проблема, что непонятно ЧТО я оспаривал :)
Возможно, просто названия функций ядра Линуха :)
>Каша и противоречие в том, что открывать исполняемый бинарник на запись для
>его замены - грзяный хак.О, писец, дожили.Просто запись в файл - это уже, оказывается, грязный хак называется!А костыльные методы - это оказывается правильно.А исполняемый он там или нет в принципе дело десятое.А что, от этого оно перестает быть файлом???
>Правильный способ апдейта - его unlink()
>и создание нового, что опирается на вышеуказанное отделение имени файла от
>самого файла.Ага, конечно, хитрожопо прикрученый костыль теперь называется правильным решением.А все потому что это называется "двойные стандарты".Если в любомой системе, архитектуре и т.п. сделано через попу - надо сказать что на самом деле это рулез а через попу у всех кто не согласен.Гениальная логика в полном согласии с "каждый кулик хвалит свое болото".Лично я не вижу зачем плодить лишние сущности и все усложнять.Ничего кроме геморроя и глюков от этого не бывает.Что может быть проще обычной записи в файл без всякого траходрома???
>И, следовательно, это отделение в *nix, коли уж шло
>сравнение с виндой, должно было быть четко и ясно описано.А в винде вообще нет нормального метода замены загруженного в данный момент файла без ребута.Особенно системных DLL касается.Как максимум, можно переименовать файло, передвинув его в другое место (при том только в пределах одного диска, между дисками двигать такие файлы нельзя - привет от нелинейной файловой системы) и положить на его место новый файл.Который однако никто кроме вновь запущенных программ юзать не будет до ребута.В итоге получается что ребут необходим чтобы все программы юзали новую версию ДЛЛ и чтобы завершить удаление файла (стереть переиенованный файл до ребуте ессно нельзя, он используется).
>>"dll-ки являются swap'ом для себя"
И exe-файлы тоже являются свопом для себя.
>>не swap'ом они для себя являются, а мапятся в процесс.
С целью замены своп-файла.Страницы вместо выгрузки в своп просто отбрасываются.Потом при нужде догружаются из образа EXE или DLL с диска.Потому и лочится намертво, собственно.А если б не лочилось - при удалении или замене такого файла все бы крашилось нафиг да и все дела.Довольно дурная затея в целом - получается очень фрагментированный фариант свопа, а экономия на сбросе страниц в своп не столь уж велика, а вот трах с апдейтами - знатный.Просто сие тупорыльство было придумано в те давние поры когда никто еще не собирался заменять системные файлы for security reasons на ходу.
>Марш в учебник - все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>для дисковых объектов.Не знаю, винда и т.п. скорее рассматривают диск как оперативку.Пусть и медленную.Собственно идея свопа проста как топор - если возникло исключение "страницы нет", попытаться ее в свопе накопать.А если уже и там нету - ой, приехали.Получается такая вот безразмерная оперативка в итоге которую при нужде можно расширить куда-то.Ну там на диск или еще в какое-то хранилище не адресуемое напрямую.
>ли это anonymous backing свопа или вполне себе именованный файл -
>без разницы.Смотря с какой стороны смотреть.Незаменяемость большого своп-файла всем до балды.Незаменяемость бинарника создает траходром с апдейтами.Ы?
>О, писец, дожили.Просто запись в файл - это уже, оказывается, грязный хак
>называется!А костыльные методы - это оказывается правильно.А[...]
>Ага, конечно, хитрожопо прикрученый костыль теперь называется правильным решением.А все потому что
>это называется "двойные стандарты".Если в любомой системе, архитектуре и т.п. сделано
>через попу - надо сказать что на самом деле это рулез
>а через попу у всех кто не согласен.Гениальная логика в полном
>согласии с "каждый кулик хвалит свое болото".Лично я не вижу зачем
>плодить лишние сущности и все усложнять.Ничего кроме геморроя и глюков от
>этого не бывает.Что может быть проще обычной записи в файл без
>всякого траходрома???Сколько эмоций и ни единого обоснования - почему же атомарная замена костыль, а открытие файла на запись не костыль, скажите мне? или почему на всех платформах существуют редакторы (обычных, не исполняемых) файлов, которые организуют бэкапы переименованием старого файла и записью нового с изменениями?
>[оверквотинг удален]
>А в винде вообще нет нормального метода замены загруженного в данный момент
>файла без ребута.Особенно системных DLL касается.Как максимум, можно переименовать файло, передвинув
>его в другое место (при том только в пределах одного диска,
>между дисками двигать такие файлы нельзя - привет от нелинейной файловой
>системы)
> и положить на его место новый файл.Который однако никто кроме
>вновь запущенных программ юзать не будет до ребута.В итоге получается что
>ребут необходим чтобы все программы юзали новую версию ДЛЛ и чтобы
>завершить удаление файла (стереть переиенованный файл до ребуте ессно нельзя, он
>используется).Сколько умных слов, да вот только это уже было рассказано выше по треду. Лучше объясните-ка, что такое "нелинейная файловая система" ? Вы где такой термин нашли?
>>>"dll-ки являются swap'ом для себя"
>
>И exe-файлы тоже являются свопом для себя.
>
>>>не swap'ом они для себя являются, а мапятся в процесс.
>
>С целью замены своп-файла.Страницы вместо выгрузки в своп просто отбрасываются.Потом при нужде
>догружаются из образа EXE или DLL с диска.Потому и лочится намертво,
>собственно.А если б не лочилось - при удалении или замене такого
>файла все бы крашилось нафиг да и все дела.И снова вы рассказываете банальности, которые и так известны либо были рассказаны выше по треду. Зачем? Хотите казаться умнее?..
> Довольно дурная затея
>в целом - получается очень фрагментированный фариант свопа, а экономия на
>сбросе страниц в своп не столь уж велика, а вот трах
>с апдейтами - знатный.Просто сие тупорыльство было придумано в те давние
>поры когда никто еще не собирался заменять системные файлы for security
>reasons на ходу.Вещаете глупости с умным видом, да еще и без конкретных замеров в руках. Это не тупорыльство, а единая схема работы для всех видов отображения данных в память, будь то исполняемый код или просто mmap() фа
>[оверквотинг удален]
>попытаться ее в свопе накопать.А если уже и там нету -
>ой, приехали.Получается такая вот безразмерная оперативка в итоге которую при нужде
>можно расширить куда-то.Ну там на диск или еще в какое-то хранилище
>не адресуемое напрямую.
>
>>ли это anonymous backing свопа или вполне себе именованный файл -
>>без разницы.
>
>Смотря с какой стороны смотреть.Незаменяемость большого своп-файла всем до балды.Незаменяемость бинарника создает
>траходром с апдейтами.Ы?
>О, писец, дожили.Просто запись в файл - это уже, оказывается, грязный хак
>называется!А костыльные методы - это оказывается правильно.А[...]
>Ага, конечно, хитрожопо прикрученый костыль теперь называется правильным решением.А все потому что
>это называется "двойные стандарты".Если в любомой системе, архитектуре и т.п. сделано
>через попу - надо сказать что на самом деле это рулез
>а через попу у всех кто не согласен.Гениальная логика в полном
>согласии с "каждый кулик хвалит свое болото".Лично я не вижу зачем
>плодить лишние сущности и все усложнять.Ничего кроме геморроя и глюков от
>этого не бывает.Что может быть проще обычной записи в файл без
>всякого траходрома???Сколько эмоций и ни единого обоснования - почему же атомарная замена костыль, а открытие файла на запись не костыль, скажите мне? или почему на всех платформах существуют редакторы (обычных, не исполняемых) файлов, которые организуют бэкапы переименованием старого файла и записью нового с изменениями?
>[оверквотинг удален]
>А в винде вообще нет нормального метода замены загруженного в данный момент
>файла без ребута.Особенно системных DLL касается.Как максимум, можно переименовать файло, передвинув
>его в другое место (при том только в пределах одного диска,
>между дисками двигать такие файлы нельзя - привет от нелинейной файловой
>системы)
> и положить на его место новый файл.Который однако никто кроме
>вновь запущенных программ юзать не будет до ребута.В итоге получается что
>ребут необходим чтобы все программы юзали новую версию ДЛЛ и чтобы
>завершить удаление файла (стереть переиенованный файл до ребуте ессно нельзя, он
>используется).Сколько умных слов, да вот только это уже было рассказано выше по треду. Лучше объясните-ка, что такое "нелинейная файловая система" ? Вы где такой термин нашли?
>>>"dll-ки являются swap'ом для себя"
>
>И exe-файлы тоже являются свопом для себя.
>
>>>не swap'ом они для себя являются, а мапятся в процесс.
>
>С целью замены своп-файла.Страницы вместо выгрузки в своп просто отбрасываются.Потом при нужде
>догружаются из образа EXE или DLL с диска.Потому и лочится намертво,
>собственно.А если б не лочилось - при удалении или замене такого
>файла все бы крашилось нафиг да и все дела.И снова вы рассказываете банальности, которые и так известны либо были рассказаны выше по треду. Зачем? Хотите казаться умнее?..
> Довольно дурная затея
>в целом - получается очень фрагментированный фариант свопа, а экономия на
>сбросе страниц в своп не столь уж велика, а вот трах
>с апдейтами - знатный.Просто сие тупорыльство было придумано в те давние
>поры когда никто еще не собирался заменять системные файлы for security
>reasons на ходу.Вещаете глупости с умным видом, да еще и без конкретных замеров в руках. Это не тупорыльство, а единая схема работы для всех видов отображения данных в память, будь то исполняемый код или просто mmap() файлов с данными.
>>Марш в учебник - все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>>для дисковых объектов.
>
>Не знаю, винда и т.п. скорее рассматривают диск как оперативку.Пусть и медленную.Собственно
>идея свопа проста как топор - если возникло исключение "страницы нет",
>попытаться ее в свопе накопать.А если уже и там нету -
>ой, приехали.Получается такая вот безразмерная оперативка в итоге которую при нужде
>можно расширить куда-то.Ну там на диск или еще в какое-то хранилище
>не адресуемое напрямую.Вот не знаете, а говорите, причем пытаетесь на пальцах объяснить, зачем нужна подкачка, как будто здесь люди, в первый раз видящие компьютер, собрались.
>>ли это anonymous backing свопа или вполне себе именованный файл -
>>без разницы.
>
>Смотря с какой стороны смотреть.Незаменяемость большого своп-файла всем до балды.Незаменяемость бинарника создает
>траходром с апдейтами.Ы?Кому создает? Винде? Так это только винды проблема, в нормальных системах все просто.
>В учебнике по операционным системамкста, смотрю человек грамотный, книжки читает...
А не скажет ли сей грамотный гражданин всегда ли можно открыть бинарник,
исполняющегося из него процесса на запись? :) Речь будем вести о 2.6 линухе
(относительно свежем: >=2.6.9)
>>В учебнике по операционным системам
>
>кста, смотрю человек грамотный, книжки читает...
>
>А не скажет ли сей грамотный гражданин всегда ли можно открыть бинарник,
>
>исполняющегося из него процесса на запись? :) Речь будем вести о 2.6
>линухе
>(относительно свежем: >=2.6.9)Не знаю, как у вас в линухе, а системы на базе 4.4BSD возвращают ETXTBSY в таких случаях от рождения (т.е. более 13 лет).
>Не знаю, как у вас в линухе, а системы на базе 4.4BSD
>возвращают ETXTBSY в таких случаях от рождения (т.е. более 13 лет).чем больше тем лучше? ;)
не баись, Линух тоже самое делает ;) уже более 15 лет!! :D
> Результаты исследования собраны в результате опроса 700 человек из 27 стран.Зашибись.
- Алло, у вас хоть один сервер с Убунтой стоит?
- Дык канешно стаит! Работает!
- А сколько простаивал за год?
- Дык примерно часа два, когда мы пиво на него пролили на прошлый Новый Год.
- Спасибо, запишем....> Yankee Group заявила
Маркетологи раскручивают Линукс? Хоть бы гуглом поискали, что такое UNIX, засранцы ленивые
>Маркетологи раскручивают Линукс? Хоть бы гуглом поискали, что такое UNIX, засранцы ленивыезачем если есть Линукс? :))