форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (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 Новость: http://www.opennet.me/opennews/art.shtml?num=15359

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

Сообщения по теме

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

1. "Надёжность Linux, Unix и Windows серверов в цифрах"

Сообщение от antares (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 (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 (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 (ok) on 17-Апр-08, 11:54
	Скока линуксоидов нашли знакомых столько и опросили =))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Надёжность Linux, Unix и Windows серверов в цифрах"

Сообщение от Bit on 17-Апр-08, 12:31

У нас Gentoo Linux, 50 серверов - real time кластер. Время простоя несколько минут в год на ВСЕ сервера, если считать, что причина простоя была связана с ОС. Гораздо больше времени простоя связано с электропитанием и перебоями доступа в интернет

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

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

	15. "Надёжность Linux, Unix и Windows серверов в цифрах"
	Сообщение от pavlinux (ok) on 17-Апр-08, 14:02
	А у меня сервак на MSDOS, запустил спец-секретную утиль, int i; while(1) {           i++;           i--;   } постой 2 нано-секунды.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Надёжностъ"
	Сообщение от _Nick_ (??) 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 (??) 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 (ok) on 17-Апр-08, 14:05

Во. 2.6.25 вышло, пойду компилять.... А то от вас тут простой один.

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

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

	21. "Надёжность Linux, Unix и Windows серверов в цифрах"
	Сообщение от _Nick_ (??) 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 серверов в цифрах"

Сообщение от Дима (??) on 18-Апр-08, 17:17

Да все что пишут про стабильность винды это фуфло !!! Хотя 2003 тянет лучше :-) Ферма из десятка терминальных серверов (напялен цитрикс), в течении рабочего дня приложения пользователей так винду замучивают, что если они ночью не перезагрузятся, то на следующий день их так раскорячивает, в ступор просто! (вот и приходится ребут ставить на ночь). Линуксовые серваки (внутренние сервисные и брэндмауэр) работают годами !!! как верно подмечено если б не перебои питания.

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

25. "глупость"

Сообщение от don_oles (??) 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 (??) on 19-Апр-08, 13:59
	>и все это связано с виртуальным адресным пространством не более чем с тупорылой политикой мягкотелой конторы. В нормальных системах заюзанную шареную либу без проблем можно переписать, а если она не полностью зачитана (и в таком случае не может быть переписана, равно как и любой бинарь в подобном случае) - то уж переименовать ее и создать новую с оригинальным именем - нет проблем. Последующий рестарт ПРОГРАММ, использующих сию либу - уже будут с ее новой версией. Так работают системы, от которых нужна работа, а не уровень продаж. >dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее. где таритесь?? ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "глупость"
	Сообщение от nuclight (ok) on 20-Апр-08, 00:25
	>[оверквотинг удален] >не более чем с тупорылой политикой мягкотелой конторы. > >В нормальных системах заюзанную шареную либу без проблем можно переписать, >а если она не полностью зачитана (и в таком случае не может >быть переписана, >равно как и любой бинарь в подобном случае) - то уж переименовать >ее и создать новую >с оригинальным именем - нет проблем. >Последующий рестарт ПРОГРАММ, использующих сию либу - уже будут с ее новой >версией. Че? Каша какая-то в голове. В нормальных системах - это отделение файлового объекта от его имени в слое VFS, в результате чего имя файла отделено от него самого, и его можно удалять, vnode же останется, пока используется. А в винде жесткая привязка по имени, поэтому файл намертво залочен. >>dll-ки являются swap'ом для себя. И при фрагментации все это работает все медленнее и медленнее. > >где таритесь?? ;) В учебнике по операционным системам. Любая современная ось это использует - text-страницы бинарника мапятся непосредственно из его файла, данные процесса swap-backed. Text-страницы - file-backed, но механизм подкачки тот же самый.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "глупость"
	Сообщение от _Nick_ (??) on 20-Апр-08, 00:43
	>Че? Каша какая-то в голове. В нормальных системах - это отделение файлового >объекта от его имени в слое VFS, в результате чего имя >файла отделено от него самого, и его можно удалять, vnode же >останется, пока используется. А в винде жесткая привязка по имени, поэтому >файл намертво залочен. и в каком же месте я противоречу вашим светлым мыслям, о великий? кашки вы где-то в другом месте хлебнули. >В учебнике по операционным системам. Любая современная ось это использует - text-страницы >бинарника мапятся непосредственно из его файла, данные процесса swap-backed. >Text-страницы - file-backed, но механизм подкачки тот же самый. У кого еще каша... своппинг и маппинг перепутать и обозвать одним и тем же... Своппинг использует маппинг, но не наоборот. А раз не наоборот - то называть одно другим во всех случаях нельзя. А именно этим товарисч и отметился: "dll-ки являются swap'ом для себя" не swap'ом они для себя являются, а мапятся в процесс.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "глупость"
	Сообщение от nuclight (ok) on 20-Апр-08, 13:29
	>>Че? Каша какая-то в голове. В нормальных системах - это отделение файлового >>объекта от его имени в слое VFS, в результате чего имя >>файла отделено от него самого, и его можно удалять, vnode же >>останется, пока используется. А в винде жесткая привязка по имени, поэтому >>файл намертво залочен. > >и в каком же месте я противоречу вашим светлым мыслям, о великий? >кашки вы где-то в другом месте хлебнули. Каша и противоречие в том, что открывать исполняемый бинарник на запись для его замены - грзяный хак. Правильный способ апдейта - его unlink() и создание нового, что опирается на вышеуказанное отделение имени файла от самого файла. И, следовательно, это отделение в *nix, коли уж шло сравнение с виндой, должно было быть четко и ясно описано. >[оверквотинг удален] > >У кого еще каша... >своппинг и маппинг перепутать и обозвать одним и тем же... >Своппинг использует маппинг, но не наоборот. А раз не наоборот - то >называть одно >другим во всех случаях нельзя. А именно этим товарисч и отметился: > >"dll-ки являются swap'ом для себя" > >не swap'ом они для себя являются, а мапятся в процесс. Марш в учебник - все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш для дисковых объектов. У операционной системы метод един - paging. Будет ли это anonymous backing свопа или вполне себе именованный файл - без разницы. В обоих случаях ось может спокойно выкинуть страницы файла из ОЗУ и потом подгрузить их обратно при надобности.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "глупость"
	Сообщение от _Nick_ (??) on 20-Апр-08, 14:56
	>Каша и противоречие в том, что открывать исполняемый бинарник на запись для >его замены - грзяный хак. разговор был возможно или нет. Кста, об исполнимых бинарях я действительно перегнул. Они блокирутся при exec()е. Но либы - нет (хотя тут вопрос доступа и желаний самой программы). Посему даже используемые либы можно открыть на запись и переписать. Другое дело, что проги такого не ожидают и просто падают как только управление доходит до подмененного объекта. Ессьно, это нельзя рассматривать как метод обновления, а мы этого и не делаем. >Правильный способ апдейта - его unlink() >и создание нового, что опирается на вышеуказанное отделение имени файла от >самого файла. И, следовательно, это отделение в *nix, коли уж шло >сравнение с виндой, должно было быть четко и ясно описано. эт все понятно. >Марш в учебник Так и добавляй же сразу, что в учебник по бздям. >- все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш >для дисковых объектов. Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз дом родной, т.к. это самая быстрая память в системе (после кешей проца). >У операционной системы метод един - paging. Будет >ли это anonymous backing свопа или вполне себе именованный файл - >без разницы. В обоих случаях ось может спокойно выкинуть страницы файла >из ОЗУ и потом подгрузить их обратно при надобности. Ну вот и славно. И ты прав - и я прав. Нужно было лишь изначально оговориться о чем речь. У Линуха нет такой любви к свопингу. Работа с файлами и девайсами (даже тем же свопиком) идет через буфера ОЗУ. Свопик (кстати, тоже буферизированный) используется лишь при нехватке ОЗУ. Если же ее хватает - своппинг не будет иметь место.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "глупость"
	Сообщение от nuclight (ok) on 23-Апр-08, 16:27
	>Посему даже используемые либы можно открыть на запись и переписать. >Другое дело, что проги такого не ожидают и просто падают как только >управление >доходит до подмененного объекта. Ессьно, это нельзя рассматривать как метод обновления, >а мы этого и не делаем. Хехе. Вон, человек ниже доказывает, что так переписывать - и есть самый правильный способ :) >Так и добавляй же сразу, что в учебник по бздям. >>- все Mach-derived VM-подсистемы рассматривают ОЗУ лишь как кэш >>для дисковых объектов. >Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз >дом родной, т.к. это самая быстрая >память в системе (после кешей проца). В учебник по операционным системам. Архитектурные принципы те же (ОЗУ лишь кэш для диска), и разница лишь в константах тюнинга (политиках замещения кэша). >[оверквотинг удален] >>ли это anonymous backing свопа или вполне себе именованный файл - >>без разницы. В обоих случаях ось может спокойно выкинуть страницы файла >>из ОЗУ и потом подгрузить их обратно при надобности. > >Ну вот и славно. И ты прав - и я прав. Нужно >было лишь изначально оговориться о чем речь. >У Линуха нет такой любви к свопингу. Работа с файлами и девайсами >(даже тем же свопиком) >идет через буфера ОЗУ. Свопик (кстати, тоже буферизированный) используется лишь при нехватке >ОЗУ. Если же ее хватает - своппинг не будет иметь место. Да есть, см. выше...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "глупость"
	Сообщение от Nick (??) on 24-Апр-08, 20:53
	>Хехе. Вон, человек ниже доказывает, что так переписывать - и есть самый >правильный способ :) видать, он ни разу не пробовал даже жалкую сошку находу переписать :) >>Ну вот и нашли разницу. Для Линуха ОЗУ - это как раз >>дом родной, т.к. это самая быстрая >>память в системе (после кешей проца). > >В учебник по операционным системам. учебники - хорошо :) но учебники далеко и серьезно отстают от _текущего_ ядра Линукс. Ну что поделаешь, если его пишут/оптимизируют, не особо взирая на классические стандарты (с POSIX он тоже не полностью совместим), но с обратной совместимостью для user-level'a? :) За сим, учебники стоит читать лишь по началу. Потом уже нужно читать только ядро. Иначе, адекватность будет лишь мнимой. >Архитектурные принципы те же (ОЗУ лишь кэш для диска) нет. В корне не согласен :) Это внешне невооруженным глазом так кажется, что ОЗУ лишь кеш. И не вдаваясь в подробности можно так думать и все будет замечательно. На работу системы такое расхождение мнения админа с работой ядра никак не скажется. Но дело как раз в том, что архитектура рассматривает загрузку с диска как ситуацию, когда нужного блока во внутренних структурах VFS нет. Так он написано. Чем оно кажется со стороны - дело десятое :) >и разница лишь в константах тюнинга (политиках замещения кэша). Ну, эти константы в Линухе и BSD разные, и их назначение разное. Посему, не буду никак столь разные множества рулей коментировать :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	42. "глупость"
	Сообщение от Nick (??) 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 (ok) on 23-Апр-08, 16:16
	>О, писец, дожили.Просто запись в файл - это уже, оказывается, грязный хак >называется!А костыльные методы - это оказывается правильно.А [...] >Ага, конечно, хитрожопо прикрученый костыль теперь называется правильным решением.А все потому что >это называется "двойные стандарты".Если в любомой системе, архитектуре и т.п. сделано >через попу - надо сказать что на самом деле это рулез >а через попу у всех кто не согласен.Гениальная логика в полном >согласии с "каждый кулик хвалит свое болото".Лично я не вижу зачем >плодить лишние сущности и все усложнять.Ничего кроме геморроя и глюков от >этого не бывает.Что может быть проще обычной записи в файл без >всякого траходрома??? Сколько эмоций и ни единого обоснования - почему же атомарная замена костыль, а открытие файла на запись не костыль, скажите мне? или почему на всех платформах существуют редакторы (обычных, не исполняемых) файлов, которые организуют бэкапы переименованием старого файла и записью нового с изменениями? >[оверквотинг удален] >А в винде вообще нет нормального метода замены загруженного в данный момент >файла без ребута.Особенно системных DLL касается.Как максимум, можно переименовать файло, передвинув >его в другое место (при том только в пределах одного диска, >между дисками двигать такие файлы нельзя - привет от нелинейной файловой >системы) > и положить на его место новый файл.Который однако никто кроме >вновь запущенных программ юзать не будет до ребута.В итоге получается что >ребут необходим чтобы все программы юзали новую версию ДЛЛ и чтобы >завершить удаление файла (стереть переиенованный файл до ребуте ессно нельзя, он >используется). Сколько умных слов, да вот только это уже было рассказано выше по треду. Лучше объясните-ка, что такое "нелинейная файловая система" ? Вы где такой термин нашли? >>>"dll-ки являются swap'ом для себя" > >И exe-файлы тоже являются свопом для себя. > >>>не swap'ом они для себя являются, а мапятся в процесс. > >С целью замены своп-файла.Страницы вместо выгрузки в своп просто отбрасываются.Потом при нужде >догружаются из образа EXE или DLL с диска.Потому и лочится намертво, >собственно.А если б не лочилось - при удалении или замене такого >файла все бы крашилось нафиг да и все дела. И снова вы рассказываете банальности, которые и так известны либо были рассказаны выше по треду. Зачем? Хотите казаться умнее?.. > Довольно дурная затея >в целом - получается очень фрагментированный фариант свопа, а экономия на >сбросе страниц в своп не столь уж велика, а вот трах >с апдейтами - знатный.Просто сие тупорыльство было придумано в те давние >поры когда никто еще не собирался заменять системные файлы for security >reasons на ходу. Вещаете глупости с умным видом, да еще и без конкретных замеров в руках. Это не тупорыльство, а единая схема работы для всех видов отображения данных в память, будь то исполняемый код или просто mmap() фа >[оверквотинг удален] >попытаться ее в свопе накопать.А если уже и там нету - >ой, приехали.Получается такая вот безразмерная оперативка в итоге которую при нужде >можно расширить куда-то.Ну там на диск или еще в какое-то хранилище >не адресуемое напрямую. > >>ли это anonymous backing свопа или вполне себе именованный файл - >>без разницы. > >Смотря с какой стороны смотреть.Незаменяемость большого своп-файла всем до балды.Незаменяемость бинарника создает >траходром с апдейтами.Ы?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "глупость"
	Сообщение от nuclight (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_ (??) on 20-Апр-08, 00:55
	>В учебнике по операционным системам кста, смотрю человек грамотный, книжки читает... А не скажет ли сей грамотный гражданин всегда ли можно открыть бинарник, исполняющегося из него процесса на запись? :) Речь будем вести о 2.6 линухе (относительно свежем: >=2.6.9)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

	34. "глупость"
	Сообщение от _Nick_ (??) 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 (??) on 02-Май-08, 10:37
	>Маркетологи раскручивают Линукс? Хоть бы гуглом поискали, что такое UNIX, засранцы ленивые зачем если есть Линукс? :))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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