The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"OpenNews: Надёжность Linux, Unix и Windows серверов в цифрах"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"OpenNews: Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от opennews (ok) on 17-Апр-08, 11:17 
По сравнению с 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
Новость: https://www.opennet.ru/opennews/art.shtml?num=15359

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от antares email(ok) on 17-Апр-08, 11:17 
маловато 700 человек для таких выводов..
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от IIapa3uT on 17-Апр-08, 11:21 
С чего это Linux стал Unix'ом?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Michael Shigorin email(ok) on 17-Апр-08, 13:52 
>С чего это Linux стал Unix'ом?

С чего это Вы сделали такой вывод?  Даже янкитруп пишут, что Unix -- это AIX/HPUX/Solaris :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от amity on 17-Апр-08, 11:26 
"Время простоя"? Всмысле, "uptime"?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от vadiml on 17-Апр-08, 11:36 
> "Время простоя"? Всмысле, "uptime"?

это скорее сумма "stoptime"-ов

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от amity on 17-Апр-08, 11:27 
Ааа.. понял.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Michael Shigorin email(ok) on 17-Апр-08, 13:53 
Строго говоря, "сумма downtime".
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Аноним (??) on 17-Апр-08, 11:34 
прочитал название новости и подумал что гетзэфактс, больно часто их видел =))
А вообще так, нормально, но 700 человек думаю не так уж и много...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от dmitry.kuzmenko email(ok) on 17-Апр-08, 11:54 
Скока линуксоидов нашли знакомых столько и опросили =))
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Bit email on 17-Апр-08, 12:31 
У нас Gentoo Linux, 50 серверов - real time кластер.
Время простоя несколько минут в год на ВСЕ сервера, если считать, что причина простоя была связана с ОС. Гораздо больше времени простоя связано с электропитанием и перебоями доступа в интернет
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Michael Shigorin email(ok) on 17-Апр-08, 13:57 
Пользователям, как правило, без разницы.  У меня один из серверов на ALT Linux 2.4 Master с несколькими минутами простоя (ядро) несколько лет работает, если так считать... другое дело, что однажды полгорода вырубило -- тогда падало питание, и пару раз с маршрутизацией чудеса творились.  В сумме с сутки будет, а за пределами корпуса интересна как раз сумма.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от pavlinux email(ok) on 17-Апр-08, 14:02 
А у меня сервак на MSDOS,
запустил спец-секретную утиль,

int i;
while(1) {
          i++;
          i--;  
}

постой 2 нано-секунды.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Надёжностъ"  
Сообщение от _Nick_ email(??) on 17-Апр-08, 16:08 
>постой 2 нано-секунды.

постоял, видимо, намного дольше...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от sa10 (??) on 17-Апр-08, 13:10 
Однако все это реклама и оценивать здесь можно только качество рекламы :)
Если я не считаю себя специалистом по рекламе, то читать это и вникать в детали незачем....
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Аноним (??) on 17-Апр-08, 13:26 
Да какая нафиг реклама - в Windows 2003 установка заплаток на браузер требует перезагрузки сервера! Это-ж караул просто!
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от demo (??) on 17-Апр-08, 13:55 
>Да какая нафиг реклама - в Windows 2003 установка заплаток на браузер
>требует перезагрузки сервера! Это-ж караул просто!

Браузер на сервере? на варезники ходить? для windows update дыры не критичны.
Другой вопрос - обновление называется "заплатка для браузера" а что в нём на самом деле лежит только MS знает.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Аноним (??) on 17-Апр-08, 14:04 
>Браузер на сервере? на варезники ходить? для windows update дыры не критичны.

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

>Другой вопрос - обновление называется "заплатка для браузера" а что в нём
>на самом деле лежит только MS знает.

+пицотыщмильёноу

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Fantomas email(??) on 17-Апр-08, 15:35 
> Браузер на сервере? на варезники ходить?

Зачем, лучше осла на сервант поставить круглосуточно работать. Кучу полезных прог можно закачать и фильмов.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от User294 (ok) on 18-Апр-08, 13:33 
>Да какая нафиг реклама - в Windows 2003 установка заплаток на браузер
>требует перезагрузки сервера! Это-ж караул просто!

А если там Exchange Server стоял - это не караул, это 0.5 .. 2 часа отдыха от корпоративной почты.Круто, yeah.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от pavlinux email(ok) on 17-Апр-08, 14:05 
Во. 2.6.25 вышло, пойду компилять.... А то от вас тут простой один.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Michael Shigorin email(ok) on 17-Апр-08, 15:20 
>Во. 2.6.25 вышло, пойду компилять.... А то от вас тут простой один.

И сказал он даун тайму:
экой ты простой

Казнить нельзя-помиловать :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от _Nick_ email(??) on 17-Апр-08, 16:09 
>Во. 2.6.25 вышло, пойду компилять.... А то от вас тут простой один.

ты уже опоздал.... ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Аноним (??) on 18-Апр-08, 16:40 
i can wait
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Дима email(??) on 18-Апр-08, 17:17 
Да все что пишут про стабильность винды это фуфло !!! Хотя 2003 тянет лучше :-)
Ферма из десятка терминальных серверов (напялен цитрикс), в течении рабочего дня приложения пользователей так винду замучивают, что если они ночью не перезагрузятся, то на следующий день их так раскорячивает, в ступор просто! (вот и приходится ребут ставить на ночь). Линуксовые серваки (внутренние сервисные и брэндмауэр) работают годами !!! как верно подмечено если б не перебои питания.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "глупость"  
Сообщение от don_oles email(??) on 18-Апр-08, 18:15 
Это мне напоминает про среднюю температуру в больнице. А может это просто опыт и знания админов выросли а не надёжность систем?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "глупость"  
Сообщение от Luke (??) on 18-Апр-08, 23:50 
>Это мне напоминает про среднюю температуру в больнице. А может это просто
>опыт и знания админов выросли а не надёжность систем?

А если поговорить о надежности - в Windows как ни крути, а заменить выполняемое в данный момент файло без ребута проблематично.Особенно весело с DLL - они загружены кучей программ вплоть до процессов системы.Как ни крути а просто выгрузить и заменить - не выйдет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "глупость"  
Сообщение от vitek (??) on 19-Апр-08, 13:55 
и все это связано с виртуальным адресным пространством. dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "глупость"  
Сообщение от Nick email(??) on 19-Апр-08, 13:59 
>и все это связано с виртуальным адресным пространством

не более чем с тупорылой политикой мягкотелой конторы.

В нормальных системах заюзанную шареную либу без проблем можно переписать,
а если она не полностью зачитана (и в таком случае не может быть переписана,
равно как и любой бинарь в подобном случае) - то уж переименовать ее и создать новую
с оригинальным именем - нет проблем.
Последующий рестарт ПРОГРАММ, использующих сию либу - уже будут с ее новой версией.

Так работают системы, от которых нужна работа, а не уровень продаж.


>dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее.

где таритесь?? ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "глупость"  
Сообщение от nuclight email(ok) on 20-Апр-08, 00:25 
>[оверквотинг удален]
>не более чем с тупорылой политикой мягкотелой конторы.
>
>В нормальных системах заюзанную шареную либу без проблем можно переписать,
>а если она не полностью зачитана (и в таком случае не может
>быть переписана,
>равно как и любой бинарь в подобном случае) - то уж переименовать
>ее и создать новую
>с оригинальным именем - нет проблем.
>Последующий рестарт ПРОГРАММ, использующих сию либу - уже будут с ее новой
>версией.

Че? Каша какая-то в голове. В нормальных системах - это отделение файлового объекта от его имени в слое VFS, в результате чего имя файла отделено от него самого, и его можно удалять, vnode же останется, пока используется. А в винде жесткая привязка по имени, поэтому файл намертво залочен.

>>dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее.
>
>где таритесь?? ;)

В учебнике по операционным системам. Любая современная ось это использует - text-страницы бинарника мапятся непосредственно из его файла, данные процесса swap-backed. Text-страницы - file-backed, но механизм подкачки тот же самый.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

30. "глупость"  
Сообщение от _Nick_ email(??) on 20-Апр-08, 00:43 
>Че? Каша какая-то в голове. В нормальных системах - это отделение файлового
>объекта от его имени в слое VFS, в результате чего имя
>файла отделено от него самого, и его можно удалять, vnode же
>останется, пока используется. А в винде жесткая привязка по имени, поэтому
>файл намертво залочен.

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

>В учебнике по операционным системам. Любая современная ось это использует - text-страницы
>бинарника мапятся непосредственно из его файла, данные процесса swap-backed.
>Text-страницы - file-backed, но механизм подкачки тот же самый.

У кого еще каша...
своппинг и маппинг перепутать и обозвать одним и тем же...
Своппинг использует маппинг, но не наоборот. А раз не наоборот - то называть одно
другим во всех случаях нельзя. А именно этим товарисч и отметился:

"dll-ки являются swap'ом для себя"

не swap'ом они для себя являются, а мапятся в процесс.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

33. "глупость"  
Сообщение от nuclight email(ok) on 20-Апр-08, 13:29 
>>Че? Каша какая-то в голове. В нормальных системах - это отделение файлового
>>объекта от его имени в слое VFS, в результате чего имя
>>файла отделено от него самого, и его можно удалять, vnode же
>>останется, пока используется. А в винде жесткая привязка по имени, поэтому
>>файл намертво залочен.
>
>и в каком же месте я противоречу вашим светлым мыслям, о великий?
>кашки вы где-то в другом месте хлебнули.

Каша и противоречие в том, что открывать исполняемый бинарник на запись для его замены - грзяный хак. Правильный способ апдейта - его unlink() и создание нового, что опирается на вышеуказанное отделение имени файла от самого файла. И, следовательно, это отделение в *nix, коли уж шло сравнение с виндой, должно было быть четко и ясно описано.

>[оверквотинг удален]
>
>У кого еще каша...
>своппинг и маппинг перепутать и обозвать одним и тем же...
>Своппинг использует маппинг, но не наоборот. А раз не наоборот - то
>называть одно
>другим во всех случаях нельзя. А именно этим товарисч и отметился:
>
>"dll-ки являются swap'ом для себя"
>
>не swap'ом они для себя являются, а мапятся в процесс.

Марш в учебник - все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш для дисковых объектов. У операционной системы метод един - paging. Будет ли это anonymous backing свопа или вполне себе именованный файл - без разницы. В обоих случаях ось может спокойно выкинуть страницы файла из ОЗУ и потом подгрузить их обратно при надобности.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

35. "глупость"  
Сообщение от _Nick_ email(??) on 20-Апр-08, 14:56 
>Каша и противоречие в том, что открывать исполняемый бинарник на запись для
>его замены - грзяный хак.

разговор был возможно или нет.
Кста, об исполнимых бинарях я действительно перегнул. Они блокирутся при exec()е.
Но либы - нет (хотя тут вопрос доступа и желаний самой программы).
Посему даже используемые либы можно открыть на запись и переписать.
Другое дело, что проги такого не ожидают и просто падают как только управление
доходит до подмененного объекта. Ессьно, это нельзя рассматривать как метод обновления,
а мы этого и не делаем.


>Правильный способ апдейта - его unlink()
>и создание нового, что опирается на вышеуказанное отделение имени файла от
>самого файла. И, следовательно, это отделение в *nix, коли уж шло
>сравнение с виндой, должно было быть четко и ясно описано.

эт все понятно.


>Марш в учебник

Так и добавляй же сразу, что в учебник по бздям.

>- все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>для дисковых объектов.

Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз дом родной, т.к. это самая быстрая
память в системе (после кешей проца).


>У операционной системы метод един - paging. Будет
>ли это anonymous backing свопа или вполне себе именованный файл -
>без разницы. В обоих случаях ось может спокойно выкинуть страницы файла
>из ОЗУ и потом подгрузить их обратно при надобности.

Ну вот и славно. И ты прав - и я прав. Нужно было лишь изначально оговориться о чем речь.
У Линуха нет такой любви к свопингу. Работа с файлами и девайсами (даже тем же свопиком)
идет через буфера ОЗУ. Свопик (кстати, тоже буферизированный) используется лишь при нехватке ОЗУ. Если же ее хватает - своппинг не будет иметь место.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

39. "глупость"  
Сообщение от nuclight email(ok) on 23-Апр-08, 16:27 
>Посему даже используемые либы можно открыть на запись и переписать.
>Другое дело, что проги такого не ожидают и просто падают как только
>управление
>доходит до подмененного объекта. Ессьно, это нельзя рассматривать как метод обновления,
>а мы этого и не делаем.

Хехе. Вон, человек ниже доказывает, что так переписывать - и есть самый правильный способ :)

>Так и добавляй же сразу, что в учебник по бздям.
>>- все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>>для дисковых объектов.
>Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз
>дом родной, т.к. это самая быстрая
>память в системе (после кешей проца).

В учебник по операционным системам. Архитектурные принципы те же (ОЗУ лишь кэш для диска), и разница лишь в константах тюнинга (политиках замещения кэша).

>[оверквотинг удален]
>>ли это anonymous backing свопа или вполне себе именованный файл -
>>без разницы. В обоих случаях ось может спокойно выкинуть страницы файла
>>из ОЗУ и потом подгрузить их обратно при надобности.
>
>Ну вот и славно. И ты прав - и я прав. Нужно
>было лишь изначально оговориться о чем речь.
>У Линуха нет такой любви к свопингу. Работа с файлами и девайсами
>(даже тем же свопиком)
>идет через буфера ОЗУ. Свопик (кстати, тоже буферизированный) используется лишь при нехватке
>ОЗУ. Если же ее хватает - своппинг не будет иметь место.

Да есть, см. выше...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

40. "глупость"  
Сообщение от Nick email(??) on 24-Апр-08, 20:53 
>Хехе. Вон, человек ниже доказывает, что так переписывать - и есть самый
>правильный способ :)

видать, он ни разу не пробовал даже жалкую сошку находу переписать :)


>>Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз
>>дом родной, т.к. это самая быстрая
>>память в системе (после кешей проца).
>
>В учебник по операционным системам.

учебники - хорошо :) но учебники далеко и серьезно отстают от _текущего_ ядра Линукс.
Ну что поделаешь, если его пишут/оптимизируют, не особо взирая на классические стандарты (с POSIX он тоже не полностью совместим), но с обратной совместимостью для user-level'a? :)
За сим, учебники стоит читать лишь по началу. Потом уже нужно читать только ядро.
Иначе, адекватность будет лишь мнимой.


>Архитектурные принципы те же (ОЗУ лишь кэш для диска)

нет. В корне не согласен :)
Это внешне невооруженным глазом так кажется, что ОЗУ лишь кеш.
И не вдаваясь в подробности можно так думать и все будет замечательно.
На работу системы такое расхождение мнения админа с работой ядра никак не скажется.
Но дело как раз в том, что архитектура рассматривает загрузку с диска как ситуацию,
когда нужного блока во внутренних структурах VFS нет.
Так он написано.
Чем оно кажется со стороны - дело десятое :)


>и разница лишь в константах тюнинга (политиках замещения кэша).

Ну, эти константы в Линухе и BSD разные, и их назначение разное.
Посему, не буду никак столь разные множества рулей коментировать :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

41. "глупость"  
Сообщение от nuclight email(ok) on 25-Апр-08, 10:40 
>[оверквотинг удален]
>>В учебник по операционным системам.
>
>учебники - хорошо :) но учебники далеко и серьезно отстают от _текущего_
>ядра Линукс.
>Ну что поделаешь, если его пишут/оптимизируют, не особо взирая на классические стандарты
>(с POSIX он тоже не полностью совместим), но с обратной совместимостью
>для user-level'a? :)
>За сим, учебники стоит читать лишь по началу. Потом уже нужно читать
>только ядро.
>Иначе, адекватность будет лишь мнимой.

Вы путаете учебники с книгами по ядру конкретной ОСи или стандартами. Они да, устаревают. А фундаментальные архитектурные принципы, излагаемые в общих учебниках по операционным системам, они не меняются.

>[оверквотинг удален]
>Это внешне невооруженным глазом так кажется, что ОЗУ лишь кеш.
>И не вдаваясь в подробности можно так думать и все будет замечательно.
>
>На работу системы такое расхождение мнения админа с работой ядра никак не
>скажется.
>Но дело как раз в том, что архитектура рассматривает загрузку с диска
>как ситуацию,
>когда нужного блока во внутренних структурах VFS нет.
>Так он написано.
>Чем оно кажется со стороны - дело десятое :)

Это вам так со стороны кажется. Но архитектурно - это именно кэш, я выше по треду названия упоминал, куда смотреть.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

42. "глупость"  
Сообщение от Nick email(??) on 25-Апр-08, 10:54 
>Вы путаете учебники с книгами по ядру конкретной ОСи или стандартами. Они
>да, устаревают. А фундаментальные архитектурные принципы, излагаемые в общих учебниках по
>операционным системам, они не меняются.

извиняюсь, но "уморил" :)

Если будет обнаружено, что нечто "вот это" если его сделать "вот так" и
все нечнет летать быстрее - то никто из разработчиков и ухом не моргнет заюзать
этот метод для внутриядерных делов, подходит сей метод к "фундаментальным архитектурным принципам" или нет и будет прав. Админу/клиенту/пользователю нужна производительность,
а не абстрактные науки.
Более того, я не берусь утверждать, что такого не было уже в истории Линукса.
Скорее наоборот, было (хотя бы потому, что он не полностью POSIX совместим).
И можете меня посылать в любые книги за любыми названиями, но работа Линукс ядра (которое есть авторити де-факто по архитектуре самого себя %) никуда не денется.


>Это вам так со стороны кажется. Но архитектурно - это именно кэш,
>я выше по треду названия упоминал, куда смотреть.

да все понятно. Сути это не меняет. Размер внутренних стурктур VFS даже считаются
в глобальный "Cache".
Вобщем, "называй меня как хочешь, мой господин" %)
Просто код Линуха построен на том, что все живет в памяти, а если чего нет - подгружается.
Это следует как минимум из названий функций и коменариев.
Остальное - кому как нравиться :)

Понимаете, у Линкса очень специфичный отец ;)
Ему главное - технологии, а не кто где что как назвал и какие права на это заимел.
И - как мы видим - это работает :)


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

1. я не утверждал, что данные файлов проходят НЕ через ОЗУ
2. вы ищете аналогию в архитектуре процессора и ядра. В данном случае оно совпало лишь по одной причине: буферизация - это путь ускорить работу. Это справедливо в очень многих системах. И, вообще, к данному спору никак не относится. Я не оспаривал пользу кеширования.

Может как раз в том и проблема, что непонятно ЧТО я оспаривал :)
Возможно, просто названия функций ядра Линуха :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

36. "глупость"  
Сообщение от Luke (??) on 21-Апр-08, 16:20 
>Каша и противоречие в том, что открывать исполняемый бинарник на запись для
>его замены - грзяный хак.

О, писец, дожили.Просто запись в файл - это уже, оказывается, грязный хак называется!А костыльные методы - это оказывается правильно.А исполняемый он там или нет в принципе дело десятое.А что, от этого оно перестает быть файлом???

>Правильный способ апдейта - его unlink()
>и создание нового, что опирается на вышеуказанное отделение имени файла от
>самого файла.

Ага, конечно, хитрожопо прикрученый костыль теперь называется правильным решением.А все потому что это называется "двойные стандарты".Если в любомой системе, архитектуре и т.п. сделано через попу - надо сказать что на самом деле это рулез а через попу у всех кто не согласен.Гениальная логика в полном согласии с "каждый кулик хвалит свое болото".Лично я не вижу зачем плодить лишние сущности и все усложнять.Ничего кроме геморроя и глюков от этого не бывает.Что может быть проще обычной записи в файл без всякого траходрома???


>И, следовательно, это отделение в *nix, коли уж шло
>сравнение с виндой, должно было быть четко и ясно описано.

А в винде вообще нет нормального метода замены загруженного в данный момент файла без ребута.Особенно системных DLL касается.Как максимум, можно переименовать файло, передвинув его в другое место (при том только в пределах одного диска, между дисками двигать такие файлы нельзя - привет от нелинейной файловой системы) и положить на его место новый файл.Который однако никто кроме вновь запущенных программ юзать не будет до ребута.В итоге получается что ребут необходим чтобы все программы юзали новую версию ДЛЛ и чтобы завершить удаление файла (стереть переиенованный файл до ребуте ессно нельзя, он используется).

>>"dll-ки являются swap'ом для себя"

И exe-файлы тоже являются свопом для себя.

>>не swap'ом они для себя являются, а мапятся в процесс.

С целью замены своп-файла.Страницы вместо выгрузки в своп просто отбрасываются.Потом при нужде догружаются из образа EXE или DLL с диска.Потому и лочится намертво, собственно.А если б не лочилось - при удалении или замене такого файла все бы крашилось нафиг да и все дела.Довольно дурная затея в целом - получается очень фрагментированный фариант свопа, а экономия на сбросе страниц в своп не столь уж велика, а вот трах с апдейтами - знатный.Просто сие тупорыльство было придумано в те давние поры когда никто еще не собирался заменять системные файлы for security reasons на ходу.

>Марш в учебник - все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>для дисковых объектов.

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

>ли это anonymous backing свопа или вполне себе именованный файл -
>без разницы.

Смотря с какой стороны смотреть.Незаменяемость большого своп-файла всем до балды.Незаменяемость бинарника создает траходром с апдейтами.Ы?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

37. "глупость"  
Сообщение от nuclight email(ok) on 23-Апр-08, 16:16 
>О, писец, дожили.Просто запись в файл - это уже, оказывается, грязный хак
>называется!А костыльные методы - это оказывается правильно.А

[...]
>Ага, конечно, хитрожопо прикрученый костыль теперь называется правильным решением.А все потому что
>это называется "двойные стандарты".Если в любомой системе, архитектуре и т.п. сделано
>через попу - надо сказать что на самом деле это рулез
>а через попу у всех кто не согласен.Гениальная логика в полном
>согласии с "каждый кулик хвалит свое болото".Лично я не вижу зачем
>плодить лишние сущности и все усложнять.Ничего кроме геморроя и глюков от
>этого не бывает.Что может быть проще обычной записи в файл без
>всякого траходрома???

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

>[оверквотинг удален]
>А в винде вообще нет нормального метода замены загруженного в данный момент
>файла без ребута.Особенно системных DLL касается.Как максимум, можно переименовать файло, передвинув
>его в другое место (при том только в пределах одного диска,
>между дисками двигать такие файлы нельзя - привет от нелинейной файловой
>системы)
> и положить на его место новый файл.Который однако никто кроме
>вновь запущенных программ юзать не будет до ребута.В итоге получается что
>ребут необходим чтобы все программы юзали новую версию ДЛЛ и чтобы
>завершить удаление файла (стереть переиенованный файл до ребуте ессно нельзя, он
>используется).

Сколько умных слов, да вот только это уже было рассказано выше по треду. Лучше объясните-ка, что такое "нелинейная файловая система" ? Вы где такой термин нашли?

>>>"dll-ки являются swap'ом для себя"
>
>И exe-файлы тоже являются свопом для себя.
>
>>>не swap'ом они для себя являются, а мапятся в процесс.
>
>С целью замены своп-файла.Страницы вместо выгрузки в своп просто отбрасываются.Потом при нужде
>догружаются из образа EXE или DLL с диска.Потому и лочится намертво,
>собственно.А если б не лочилось - при удалении или замене такого
>файла все бы крашилось нафиг да и все дела.

И снова вы рассказываете банальности, которые и так известны либо были рассказаны выше по треду. Зачем? Хотите казаться умнее?..

> Довольно дурная затея
>в целом - получается очень фрагментированный фариант свопа, а экономия на
>сбросе страниц в своп не столь уж велика, а вот трах
>с апдейтами - знатный.Просто сие тупорыльство было придумано в те давние
>поры когда никто еще не собирался заменять системные файлы for security
>reasons на ходу.

Вещаете глупости с умным видом, да еще и без конкретных замеров в руках. Это не тупорыльство, а единая схема работы для всех видов отображения данных в память, будь то исполняемый код или просто mmap() фа

>[оверквотинг удален]
>попытаться ее в свопе накопать.А если уже и там нету -
>ой, приехали.Получается такая вот безразмерная оперативка в итоге которую при нужде
>можно расширить куда-то.Ну там на диск или еще в какое-то хранилище
>не адресуемое напрямую.
>
>>ли это anonymous backing свопа или вполне себе именованный файл -
>>без разницы.
>
>Смотря с какой стороны смотреть.Незаменяемость большого своп-файла всем до балды.Незаменяемость бинарника создает
>траходром с апдейтами.Ы?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

38. "глупость"  
Сообщение от nuclight email(ok) on 23-Апр-08, 16:17 
>О, писец, дожили.Просто запись в файл - это уже, оказывается, грязный хак
>называется!А костыльные методы - это оказывается правильно.А

[...]
>Ага, конечно, хитрожопо прикрученый костыль теперь называется правильным решением.А все потому что
>это называется "двойные стандарты".Если в любомой системе, архитектуре и т.п. сделано
>через попу - надо сказать что на самом деле это рулез
>а через попу у всех кто не согласен.Гениальная логика в полном
>согласии с "каждый кулик хвалит свое болото".Лично я не вижу зачем
>плодить лишние сущности и все усложнять.Ничего кроме геморроя и глюков от
>этого не бывает.Что может быть проще обычной записи в файл без
>всякого траходрома???

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

>[оверквотинг удален]
>А в винде вообще нет нормального метода замены загруженного в данный момент
>файла без ребута.Особенно системных DLL касается.Как максимум, можно переименовать файло, передвинув
>его в другое место (при том только в пределах одного диска,
>между дисками двигать такие файлы нельзя - привет от нелинейной файловой
>системы)
> и положить на его место новый файл.Который однако никто кроме
>вновь запущенных программ юзать не будет до ребута.В итоге получается что
>ребут необходим чтобы все программы юзали новую версию ДЛЛ и чтобы
>завершить удаление файла (стереть переиенованный файл до ребуте ессно нельзя, он
>используется).

Сколько умных слов, да вот только это уже было рассказано выше по треду. Лучше объясните-ка, что такое "нелинейная файловая система" ? Вы где такой термин нашли?

>>>"dll-ки являются swap'ом для себя"
>
>И exe-файлы тоже являются свопом для себя.
>
>>>не swap'ом они для себя являются, а мапятся в процесс.
>
>С целью замены своп-файла.Страницы вместо выгрузки в своп просто отбрасываются.Потом при нужде
>догружаются из образа EXE или DLL с диска.Потому и лочится намертво,
>собственно.А если б не лочилось - при удалении или замене такого
>файла все бы крашилось нафиг да и все дела.

И снова вы рассказываете банальности, которые и так известны либо были рассказаны выше по треду. Зачем? Хотите казаться умнее?..

> Довольно дурная затея
>в целом - получается очень фрагментированный фариант свопа, а экономия на
>сбросе страниц в своп не столь уж велика, а вот трах
>с апдейтами - знатный.Просто сие тупорыльство было придумано в те давние
>поры когда никто еще не собирался заменять системные файлы for security
>reasons на ходу.

Вещаете глупости с умным видом, да еще и без конкретных замеров в руках. Это не тупорыльство, а единая схема работы для всех видов отображения данных в память, будь то исполняемый код или просто mmap() файлов с данными.

>>Марш в учебник - все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш
>>для дисковых объектов.
>
>Не знаю, винда и т.п. скорее рассматривают диск как оперативку.Пусть и медленную.Собственно
>идея свопа проста как топор - если возникло исключение "страницы нет",
>попытаться ее в свопе накопать.А если уже и там нету -
>ой, приехали.Получается такая вот безразмерная оперативка в итоге которую при нужде
>можно расширить куда-то.Ну там на диск или еще в какое-то хранилище
>не адресуемое напрямую.

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

>>ли это anonymous backing свопа или вполне себе именованный файл -
>>без разницы.
>
>Смотря с какой стороны смотреть.Незаменяемость большого своп-файла всем до балды.Незаменяемость бинарника создает
>траходром с апдейтами.Ы?

Кому создает? Винде? Так это только винды проблема, в нормальных системах все просто.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

31. "глупость"  
Сообщение от _Nick_ email(??) on 20-Апр-08, 00:55 
>В учебнике по операционным системам

кста, смотрю человек грамотный, книжки читает...

А не скажет ли сей грамотный гражданин всегда ли можно открыть бинарник,
исполняющегося из него процесса на запись? :) Речь будем вести о 2.6 линухе
(относительно свежем: >=2.6.9)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "глупость"  
Сообщение от nuclight email(ok) on 20-Апр-08, 13:15 
>>В учебнике по операционным системам
>
>кста, смотрю человек грамотный, книжки читает...
>
>А не скажет ли сей грамотный гражданин всегда ли можно открыть бинарник,
>
>исполняющегося из него процесса на запись? :) Речь будем вести о 2.6
>линухе
>(относительно свежем: >=2.6.9)

Не знаю, как у вас в линухе, а системы на базе 4.4BSD возвращают ETXTBSY в таких случаях от рождения (т.е. более 13 лет).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

34. "глупость"  
Сообщение от _Nick_ email(??) on 20-Апр-08, 14:41 
>Не знаю, как у вас в линухе, а системы на базе 4.4BSD
>возвращают ETXTBSY в таких случаях от рождения (т.е. более 13 лет).

чем больше тем лучше? ;)

не баись, Линух тоже самое делает ;)  уже более 15 лет!! :D

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

43. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от andr.mobi (??) on 02-Май-08, 02:09 
> Результаты исследования собраны в результате опроса 700 человек из 27 стран.

Зашибись.
- Алло, у вас хоть один сервер с Убунтой стоит?
- Дык канешно стаит! Работает!
- А сколько простаивал за год?
- Дык примерно часа два, когда мы пиво на него пролили на прошлый Новый Год.
- Спасибо, запишем....

> Yankee Group заявила

Маркетологи раскручивают Линукс? Хоть бы гуглом поискали, что такое UNIX, засранцы ленивые

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

44. "Надёжность Linux, Unix и Windows серверов в цифрах"  
Сообщение от Nick email(??) on 02-Май-08, 10:37 
>Маркетологи раскручивают Линукс? Хоть бы гуглом поискали, что такое UNIX, засранцы ленивые

зачем если есть Линукс? :))


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру