Здравствуйте, AndrewJD, Вы писали:
AJD>WolfHound привел пример, как он видит счастье. Пройди по пунктам и напиши почему он не прав, с аргументами
Эээммм ты вообще внимательно за ветками следишь? Всё что сказал WolfHound так это то что синглтоны плохие, потому что любая сущность нужная сейчас в одном экземпляре может потом понадобиться в нескольких и переделки обойдутся дорого. Я в принципе согласен с тем, что переделки обойдутся дорого, я не согласен что любая сущность может потребоваться в нескольких экземплярах. Далее какие-то смутные рассказы о двух логгерах с его стороны и примеры конкретных систем (сорцы, архитектура) с моей. Как раз конкретного примера счастья (архитектура его логгера) со стороны WolfHound я так и не добился. Только пространные размышления о чужом плохом коде который надо обрачивать в свой хороший и негодяях-мегаархитекторах написавших чужой плохой код. Все пидарасты и только WolfHound — д'Артаньян.
Объяснить почему один логгер — хорошо в кратце достаточно просто: удобство (читай дешевизна) поддержки ПО. Это отражено, например, в программе презентации группы Universal Logging Protocol (ULP по идее должен заменить SysLog).
In other words, ULP configuration would not be available at the 'user' level, it would be a system service.
Обобщая, синглтоновость не надо сводить исключительно к синхронизации доступа к аппаратным ресурсам, как это имеет место в спулере принтера, TCP/IP стеке (уверен WolfHound захочет иметь два параллельно работающих стека) или ещё чем-то. Даже аппаратно-независимые сущности вполне могут по чисто идеологическим сображениям быть реализованы в единственном экземпляре. И не надо давить авторитетом умных книжем, мощью IoC уменьшающего связность и кучей других не имеющих отношения к сути вопроса паттернов, потому что паттерн сам по себе это всего лишь инструмент, который надо уметь применять адекватно, а не всегда когда удаётся. Нельзя паять молотком, даже если он самый расчудесный. Да, его можно накалить, да к нему даже прилипнет олово, но вот не надо им паять, он для другого. Так что комрад WolfHound вместе с другими искателями панацей и серебрянных пуль, конечно, может заблуждаться дальше, но есть объективно проверенные, проверенные многолетним использованием в множестве приложений на разных языках и платформах, архитектурные решения и оспаривать их у него пока аргументации не хватает, да впрочем и авторитета.
Я не хочу наезжать лично на WolfHound, общий уровень бескультурия проявился в голосовании 1912
16 из 24 проголосовавших либо не пользуются стандартными библиотеками журналирования ("Вручную пишу в файл, OutputDebugString и т. п. по мере необходимости"), либо пользуюся велосипедами, что не лучше ("Пользуюсь библиотекой собственной разработки"). log4net или syslog используют только 6 проголосовавших, другие бибиотеки даже не упомянуты. Нет, подобное бескультурие вне всякого сомнения беда системная и массовая, удивляться что кто-то не знаком с тем "как это вообще правильно делается" не надо. А вот огорчиться что некто не хочет взглянуть на уже накопленный опыт размахивая флажком IoC как индульгенцией, конечно стоит. Печально это.
Здравствуйте, adontz, Вы писали:
A>Я в принципе согласен с тем, что переделки обойдутся дорого, я не согласен что любая сущность может потребоваться в нескольких экземплярах.
Практика показывает что таки бывает нужно.
A>Далее какие-то смутные рассказы о двух логгерах с его стороны и примеры конкретных систем (сорцы, архитектура) с моей.
Ни разу не аргумент.
Ибо столько фигни понаписали...
A>Как раз конкретного примера счастья (архитектура его логгера) со стороны WolfHound я так и не добился.
Писать статьи мне мягко говоря лень.
A>Только пространные размышления о чужом плохом коде который надо обрачивать в свой хороший и негодяях-мегаархитекторах написавших чужой плохой код.
Есть 3 варианта:
1)Все переписать.
Это не наш путь.
Хотя иногда нет выхода.(существующие решения не работают) Например я так и не нашол ни одной библиотеки которая бы масштабировала картинки без артефактов. Про качество болие сложных алгоритмов и говорить не приходится.
2)Мучаться с уродским API.
Лично мне мягко говоря не хочется постоянно писать setjump/jongjump при работе с LibJPEG.
3)Взять дурацкое API и обернуть.
A>Все пидарасты и только WolfHound — д'Артаньян.
В бан захотел?
В прочем тебе не пивыкать.
A>Объяснить почему один логгер — хорошо в кратце достаточно просто: удобство (читай дешевизна) поддержки ПО.
Откуда это следует?
A>Это отражено, например, в программе презентации группы Universal Logging Protocol (ULP по идее должен заменить SysLog).
Бу-га-га. >- A lightweight client implementation must be easy to achieve.
Это правильно.
>- Is the model that each (client) host has one ULP server? In other words, ULP configuration would not be available at the 'user' level, it would be a system service.
Ага. Щаз.
Сервис которым я не могу толком управлять идет в лес сразу.
>- Should ULP use TCP or UDP?
А почему не оба?
Иногда мне хватит UDP, а иногда мне нужно TCP.
>- It should be a String based protocol.
Ой не факт.
Строковое представление имеет смысл только при выводе в файл. И то не всегда.
А гонять внутри либы строки это мягко говоря не разумно.
>- Security (bidirectional authentication? encryption? overcoming risks of denial of service attacks?)
Это нужно рещать на уровне транспорта.
>- Management: Should a ULP server be configurable via SNMP? An ULP client? How does ULP tie in with RMON2?
Да как угодно.
При нормальном проектирование можно сделать все сразу и болие того дать пользователю возможность легко прикрутить свои методы управления.
Скажем по http.
...
A>Обобщая, синглтоновость не надо сводить исключительно к синхронизации доступа к аппаратным ресурсам, как это имеет место в спулере принтера, TCP/IP стеке (уверен WolfHound захочет иметь два параллельно работающих стека) или ещё чем-то.
Обязательно захочу.
A>Даже аппаратно-независимые сущности вполне могут по чисто идеологическим сображениям быть реализованы в единственном экземпляре.
Что за идеология такая?
A>И не надо давить авторитетом умных книжем,
Так это ты тут чужим "авторитетом" давить пытаешься...
A>мощью IoC уменьшающего связность и кучей других не имеющих отношения к сути вопроса паттернов, потому что паттерн сам по себе это всего лишь инструмент, который надо уметь применять адекватно, а не всегда когда удаётся.
Где я сказал что я пытаюсь применять IoC везде? Опять придумываешь?
Я просто синглетоны не применяю.
Ибо они никогда ничего не дают и почти всегда создают проблемы.
A>Нельзя паять молотком, даже если он самый расчудесный.
А каменный топор при наличии современных инструментов вобще не имеет смысла.
A>Да, его можно накалить, да к нему даже прилипнет олово, но вот не надо им паять, он для другого. Так что комрад WolfHound вместе с другими искателями панацей и серебрянных пуль, конечно, может заблуждаться дальше, но есть объективно проверенные, проверенные многолетним использованием в множестве приложений на разных языках и платформах, архитектурные решения
Опять прячишся за чужим авторитетом... аргументов кроме "так делают крутые дядьки" опять нет...
Проблема ПО в том что тут могут работать такие ужастики что...
Скажем если ты сделаешь квадратные колеса из стекла то первый же выезд на дорогу покажет полную бредовость этой идеи.
Но ПО гораздо прочнее. И постоянно находятся некие несознательные личности которые показывают пальцем на очередную поделку на квадратных колесах и говорят ездит же...
A>и оспаривать их у него пока аргументации не хватает, да впрочем и авторитета.
Ессно не хватает. Ты же их игнорируешь.
A>Я не хочу наезжать лично на WolfHound,
Да ты постоянно этим занимаешься.
A>общий уровень бескультурия проявился
A>А вот огорчиться что некто не хочет взглянуть на уже накопленный опыт размахивая флажком IoC как индульгенцией, конечно стоит. Печально это.
Взглянул.
Понял что накопили мягко говоря не то что нужно копить и пошол дальше.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Я хотел сказать что толстые обёртки неотражающие структуру оборачиваемой сущности зачастую (да чего уж там, практически всегда) приводят к перерасходу ресурсов.
Правда?
Вот уж не замечал.
А если ты про пару лишних вызовов на обработку здорой картинки то это вобще ничто.
A>В примере выше, представь себе что функция StartJpeg очень долго выполняется или инициализирует внутренние структуры потребляющие много ресурсов.
Представил.
В моем случае она будет вызвана один раз при создании ImageProviderJpeg.
A>Разделили идеологически на Reader и Writer (типа так правильно)
Откуда следует что это правильно?
Опять придумаешь всякие глупости с которыми сам споришь?
A>или просто сперва написали Reader потому что надо было только читать, а когда захотелось писать не стали везде переименовывать и просто сделали Writer поимев проблемы с производительностью на ровном месте.
Хватит придумывать.
A>Отсюда следует, что надо хорошо понимать суть оборачиваемой сущности.
А с этим никто не спорит.
A>А как только это понимание настанет, желание обрачивать кривую архитектуру сразу отпадёт,
Как правило усиливается.
A>потому что нельзя вот так бесплатно поменять принципы работы построив новый фасад к старому дому.
ПО штука очень прочная... так что можно. И нужно ибо потом экономит кучу времени.
A>log4net общедоступен,
Nabu.Logging — библиотечка журналирования, родилась ещё на 1.1 когда я понял, что log4net это глюк.
(С) adontz
A>Nabu.Logging общедоступна.
Что-то svn://svn.subversion.ru/usr/local/svn/nabu не работает.
A>Представить свой правильный вариант ты отказался.
Делать мне больше нечего чем статьи по проектирования писать.
A>Ну и кто сливает?
Ты конечно.
Аргументов 0.
За том много демагогии. Из серии придумать глупость и потом ее долго опровергать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>log4net общедоступен, WH>
Nabu.Logging — библиотечка журналирования, родилась ещё на 1.1 когда я понял, что log4net это глюк.
WH>(С) adontz
Nabu.Logging родилась когда log4net ещё не было для .Net 2.0, а писать логи было надо. Можно было конечно портировать log4net, но это и так сделали бы без меня, а время и желание поковыряться были. Глючным, а точнее официально неработающим тогда был только DebugOutputAppender. Откуда ты взял эту "цитату" я не знаю.
A>>Nabu.Logging общедоступна. WH>Что-то svn://svn.subversion.ru/usr/local/svn/nabu не работает.
Здравствуйте, adontz, Вы писали:
A>Nabu.Logging родилась когда log4net ещё не было для .Net 2.0, а писать логи было надо. Можно было конечно портировать log4net, но это и так сделали бы без меня, а время и желание поковыряться были.
Так и запишем: Увеличивал стоимость проекта но ровном месте.
A>Глючным, а точнее официально неработающим тогда был только DebugOutputAppender.
Так и починил бы.
Всяко быстрее чем новою либу написать.
A>Откуда ты взял эту "цитату" я не знаю.
Хочешь сказать я ее придумал?
A>А у тебя не ноль, но показать их ты отказываешься. Существенная разница
Может и изложу если у меня будет несколько свободных дней и графоманское настроение.
A>Мой самый важный аргумент это ссылка на многолетний опыт.
Если это самый важный твой аргумент то слив себе можешь засчитывать автоматически.
ЗЫ Что касается оборачивания кривого API я так понимаю ты признаешь что слил?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Далее какие-то смутные рассказы о двух логгерах с его стороны и примеры конкретных систем (сорцы, архитектура) с моей. WH>Ни разу не аргумент. WH>Ибо столько фигни понаписали...
Семейство библиотек log4* используется в огромном количестве проектов. А хотя да, все ошибаются...
A>>Как раз конкретного примера счастья (архитектура его логгера) со стороны WolfHound я так и не добился. WH>Писать статьи мне мягко говоря лень.
Ну да, ну да. Тайное знание унесёшь с собой в могилу. Прямо Gреорат Сиона
A>>Все пидарастыи только WolfHound — д'Артаньян. WH>В бан захотел? WH>В прочем тебе не пивыкать.
Ты это, без перехода на личности и грязных приёмчиков. А то если поиском по РСДН воспользоваться то пол команды РСДн придётся за этот словестный оборот посадить в бан
A>>Объяснить почему один логгер — хорошо в кратце достаточно просто: удобство (читай дешевизна) поддержки ПО. WH>Откуда это следует?
Из практики. На самом деле нужен вообще один глобальный системный логгер, в который будут писать все приложения и службы. чтоб там и пингуется ли DNS было и какая температура у материнской платы и сколько свободного места на винчестере. потому что на самом деле интересуют не сообщения некоторого модуля, а реконструкция состояния в некоторый промежуток времени. Может в почтовом сервере баг, а может интернет сдох. Как понять если там только сообщения почтового сервера, но нет диагностики сети?
>>- Is the model that each (client) host has one ULP server? In other words, ULP configuration would not be available at the 'user' level, it would be a system service. WH>Ага. Щаз. WH>Сервис которым я не могу толком управлять идет в лес сразу.
Ну да-да, IETF дураки. Чу-дес-но, так и запишем.
>>- Should ULP use TCP or UDP? WH>А почему не оба? WH>Иногда мне хватит UDP, а иногда мне нужно TCP.
Это оглавление презентации, обсуждаись преимущества и недостатки. Типа TCP потребляет много ресурсов (по сравнению с UDP), TCP сложно реализовать на embedded системах где мало памяти и процессорной мощности, UDP нифига не гаратирует. Обсуждалось важно ли знать что свзь между устройством и коллектором есть, даже если сообщения не шлются и т.д.
>>- It should be a String based protocol. WH>Ой не факт. WH>Строковое представление имеет смысл только при выводе в файл. И то не всегда. WH>А гонять внутри либы строки это мягко говоря не разумно.
Тут надо уточнить, речь больше о том чтобы использовать printable ASCII characters, потому что другие символы могут попросту отсутствовать или быть не стандартизированны.
>>- Security (bidirectional authentication? encryption? overcoming risks of denial of service attacks?) WH>Это нужно рещать на уровне транспорта.
Как ты на уровне TCP это решишь? Будешь к девайсу за 50 баксов ставить Цсику с ВПНом за 450 баксов?
A>>Даже аппаратно-независимые сущности вполне могут по чисто идеологическим сображениям быть реализованы в единственном экземпляре. WH>Что за идеология такая?
IETF'ная (configuration would not be available at the 'user' level, it would be a system service). Вестимо неправильная. Правда как правильно ты рассказать ленишься, но я верю в светлое будущее и надеюсь всем сердцем.
WH>Так это ты тут чужим "авторитетом" давить пытаешься...
В том то и дело что тото авторитет которым я давлю людской и без кавычек
WH>Где я сказал что я пытаюсь применять IoC везде? Опять придумываешь? WH>Я просто синглетоны не применяю. WH>Ибо они никогда ничего не дают и почти всегда создают проблемы.
Ты применяшь IoC вместо синглтона.
WH>Опять прячишся за чужим авторитетом... аргументов кроме "так делают крутые дядьки" опять нет...
Есть, так удобнее обслуживать, я уже написал об этом выше.
WH>Взглянул. WH>Понял что накопили мягко говоря не то что нужно копить и пошол дальше.
Здравствуйте, WolfHound, Вы писали:
A>>Nabu.Logging родилась когда log4net ещё не было для .Net 2.0, а писать логи было надо. Можно было конечно портировать log4net, но это и так сделали бы без меня, а время и желание поковыряться были. WH>Так и запишем: Увеличивал стоимость проекта но ровном месте.
Делал в свободное время Open Source. Интересно как я этим увеличил стоимость проекта?
A>>Глючным, а точнее официально неработающим тогда был только DebugOutputAppender. WH>Так и починил бы. WH>Всяко быстрее чем новою либу написать.
Интересно было поковыряться и получить новый опыт. Еси угодно, для самообразования. Библиотека много раз переписывалась, иногда на основе собственных мыслей, чаще по образу и подобию чего-то там (учитывая LGPLность с лицензией проблем было мало). Скоро опять будет переписана
A>>Откуда ты взял эту "цитату" я не знаю. WH>Хочешь сказать я ее придумал?
я подробно расшифровал, что имел ввиду. Потом глюки конкретного раннего порта log4j на .Net к архитектуре вообще отношения не имеют.
A>>А у тебя не ноль, но показать их ты отказываешься. Существенная разница WH>Может и изложу если у меня будет несколько свободных дней и графоманское настроение.
Если это действительно что-то стоящее, думаю тебе многие будут благодарны. Главное чтобы ты не обманывался.
WH>ЗЫ Что касается оборачивания кривого API я так понимаю ты признаешь что слил?
Слил в чём? Ты отрицаешь, что координально разные архитектуры обёртки и оборачиваемой сущности не могут не повлечь нерационального использования ресурсов?
Здравствуйте, adontz, Вы писали:
A>Семейство библиотек log4* используется в огромном количестве проектов. А хотя да, все ошибаются...
Ты даже не представляешь сколько и какого Г используется в огромном колличестве проектов...
Одно то что я не нашол ни одной библиотеки (ни бесплатной ни за деньги. Не считая варианта купить Adobe) которая бы работала с растровыми изображениями не убивая качество говорит о многом.
A>Из практики. На самом деле нужен вообще один глобальный системный логгер, в который будут писать все приложения и службы.
Ты не понимаешь о чем говоришь... у меня в спокойные дни логи гигами измеряются...
А что начинается когда приходит какойнибудь ботнет
A>Ну да-да, IETF дураки. Чу-дес-но, так и запишем.
Как я понял это очередной комитет.
Комитет умным не бывает.
A>Это оглавление презентации, обсуждаись преимущества и недостатки. Типа TCP потребляет много ресурсов (по сравнению с UDP), TCP сложно реализовать на embedded системах где мало памяти и процессорной мощности, UDP нифига не гаратирует. Обсуждалось важно ли знать что свзь между устройством и коллектором есть, даже если сообщения не шлются и т.д.
Так я о том и говорю.
Я должен иметь возможность конфигурировать систему так как я захочу.
В плоть до того что сообщения из одного и тогоже логгера отправлять разными путями.
Напримет все ошибки по TCP, а всякую ерунду типа отладочных сообщений по UDP.
A>Тут надо уточнить, речь больше о том чтобы использовать printable ASCII characters, потому что другие символы могут попросту отсутствовать или быть не стандартизированны.
А мне реально нужно в лог UTF8 писать.
Те из-за этого я уже не могу использовать эту поделку.
A>Как ты на уровне TCP это решишь? Будешь к девайсу за 50 баксов ставить Цсику с ВПНом за 450 баксов?
Не знаешь тривиальных приемов проектирования, а еще лезешь учить других...
Я просто между кодом который сериализует сообщения и кодом который пишет в сокет воткну код который шифрует данные.
Ну или как вариант сжимает их.
Или и то и другое последовательно.
И это будет легко конфигурироваться.
Причем пользовыатель сможет писать свои фильтры.
A>В том то и дело что тото авторитет которым я давлю людской и без кавычек
Чтоб ты знал: Авторитет аргументам не является и являтся не может.
A>Ты применяшь IoC вместо синглтона.
Не всегда.
A>Есть, так удобнее обслуживать, я уже написал об этом выше.
Да ничего подобного.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Интересно было поковыряться и получить новый опыт. Еси угодно, для самообразования. Библиотека много раз переписывалась, иногда на основе собственных мыслей, чаще по образу и подобию чего-то там (учитывая LGPLность с лицензией проблем было мало). Скоро опять будет переписана
И эти люди говорят о том что велосипедостроение это плохо...
A>Если это действительно что-то стоящее, думаю тебе многие будут благодарны.
Проблема в том что графоманское настроение у меня бывает редко. А свободное время еще реже.
A>Главное чтобы ты не обманывался.
Ты за меня не переживай.
A>Слил в чём? Ты отрицаешь, что координально разные архитектуры обёртки и оборачиваемой сущности не могут не повлечь нерационального использования ресурсов?
Если делать правильно то перерасход ресурсов будет (если вобще будет) пренебрежимо мал.
А ты всетки попробуй с LibJPEG напрямую поработать...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ты даже не представляешь сколько и какого Г используется в огромном колличестве проектов...
Знаю. Тут какое дело, зачем заведомое Г официально портировать на несколько языков? Да и комьюнити Apache у меня вызывает некоторое доверие.
A>>Из практики. На самом деле нужен вообще один глобальный системный логгер, в который будут писать все приложения и службы. WH>Ты не понимаешь о чем говоришь... у меня в спокойные дни логи гигами измеряются... WH>А что начинается когда приходит какойнибудь ботнет
Понимаю, в БД пиши логи. Хранилище надо соответствующее выбирать и всё будет хорошо
У меня был проект где логи писались на 250Гб рейд (иначе просто не успеют записаться) и раз в неделю бекапировались куда-то на кассеты. ИМХО маразм, потому что практической пользы от этого никакой не было, но 5-10Гб логов в сутки я видел. А вот как в них потом что-то найти, это целая наука, data mining называется.
WH>Как я понял это очередной комитет. WH>Комитет умным не бывает.
IETF это Internet Engineering Task Force (честно говоря я искрене удивлён, что ты не знаешь что такие IETF). Придумывают и утверждают всякие никому не нужные RFC, занимаются другими малополезными глупостями. Единного коммитета там нет, есть независимые рабочие группы занимающиеся конкретными вопросами. Такая структура, абсолютно неэффектина, но чего ещё ждать от дилетантов и безделиников.
A>>Это оглавление презентации, обсуждаись преимущества и недостатки. Типа TCP потребляет много ресурсов (по сравнению с UDP), TCP сложно реализовать на embedded системах где мало памяти и процессорной мощности, UDP нифига не гаратирует. Обсуждалось важно ли знать что свзь между устройством и коллектором есть, даже если сообщения не шлются и т.д. WH>Так я о том и говорю. WH>Я должен иметь возможность конфигурировать систему так как я захочу. WH>В плоть до того что сообщения из одного и тогоже логгера отправлять разными путями. WH>Напримет все ошибки по TCP, а всякую ерунду типа отладочных сообщений по UDP.
Вот это и обсуждалось. Никто и не говорит об однозначном выборе в пользу TCP или UDP. SysLog и большая часть реализаций SNMP работают по UDP. Так что действительно ли необходимо использовать TCP вопрос не очень простой.
WH>А мне реально нужно в лог UTF8 писать. WH>Те из-за этого я уже не могу использовать эту поделку.
SysLog тоже выкинь, там по стандарту тоже только Printable ASCII, да ещё и размер датаграмы не больше 1024 байт. Вообще-то base64/uue/UTF7 никто не отменял.
WH>Я просто между кодом который сериализует сообщения и кодом который пишет в сокет воткну код который шифрует данные. WH>Ну или как вариант сжимает их. WH>Или и то и другое последовательно. WH>И это будет легко конфигурироваться.
И не работать, потому что Printable ASCII...
A>>Ты применяшь IoC вместо синглтона. WH>Не всегда.
Вовремя ты признался...
A>>Есть, так удобнее обслуживать, я уже написал об этом выше. WH>Да ничего подобного.
Вообще-то это не моё мнение, а системных администраторов. Примером единого лога и единого хранилища может, например, служить NT Event Log, где ты сперва пишешь всё подрял а потом уже фильтруешь View. Под линукс практически всегда все серверы и рабочие станции пишут в единый SysLog сервер. Так что единый лог для всего — это общепринятая практика. Я не очень понимаю что ты тут собираешься оспаривать
Здравствуйте, WolfHound, Вы писали:
A>>Интересно было поковыряться и получить новый опыт. Еси угодно, для самообразования. Библиотека много раз переписывалась, иногда на основе собственных мыслей, чаще по образу и подобию чего-то там (учитывая LGPLность с лицензией проблем было мало). Скоро опять будет переписана WH>И эти люди говорят о том что велосипедостроение это плохо...
Зависит от преследуемой цели. Абсолютного зла нет.
A>>Слил в чём? Ты отрицаешь, что координально разные архитектуры обёртки и оборачиваемой сущности не могут не повлечь нерационального использования ресурсов? WH>Если делать правильно то перерасход ресурсов будет (если вобще будет) пренебрежимо мал. WH>А ты всетки попробуй с LibJPEG напрямую поработать...
Увы это не так. Например, если ты посмотришь на Ruby обёртку HTMLayout то увидишь не только перерасход объектов, но и (если хорошенько задуматься), его неизбежность. У .Net обёртки тоже свои проблемы вызванные исключительно архитектурными различиями. В частности, приходится хранить данные обо всех DOM-элементах на события которых подписывались, чтобы отписаться перед удалением. В зависимости от приложения это может быть как несущественно, так и очень заметно. Увы, далеко не всегда удаётся написать действительно эффективную обёртку с красивым интерфейсом. При этом, что самое смешное, с точки зрения Си интерфейс HTMLayout довольно толковый. У меня нарекания вызывают только названия некоторых функций и порядок следования параметров, что вобщем-то сущие пустяки.
Здравствуйте, adontz, Вы писали:
A>Знаю. Тут какое дело, зачем заведомое Г официально портировать на несколько языков?
А я откуда знаю.
A>Да и комьюнити Apache у меня вызывает некоторое доверие.
А у меня нет. Начем с того что апач плохой сервер... Всякие там lighttpd рвут его как тузик грелку.
A>Понимаю, в БД пиши логи. Хранилище надо соответствующее выбирать и всё будет хорошо
Какая нафиг БД?
От такого колличества логов оракл раком встанет.
Тут только плоские файлики выживают.
A>У меня был проект где логи писались на 250Гб рейд (иначе просто не успеют записаться) и раз в неделю бекапировались куда-то на кассеты.
А налету gzip'ить не догадался?
Логи ведь от gzip'а сильно меньше становятся...
И как следствие на винт гораздо быстрее записываются.
Ах да... Я же забыл... у тебя же логгер правильный... Printable ASCII и все такое...
A>А вот как в них потом что-то найти, это целая наука, data mining называется.
Это мелочи. Главное чтобы было в чем искать.
A>IETF это Internet Engineering Task Force хъ
Рад что ты это понимаешь.
A>Вот это и обсуждалось. Никто и не говорит об однозначном выборе в пользу TCP или UDP. SysLog и большая часть реализаций SNMP работают по UDP. Так что действительно ли необходимо использовать TCP вопрос не очень простой.
Он очень простой.
Нужно просто позволить конфигурить систему так как надо.
И все.
Нужна гарантированная доставка используем TCP не нужна UDP.
A>SysLog тоже выкинь, там по стандарту тоже только Printable ASCII, да ещё и размер датаграмы не больше 1024 байт.
Я вобще считаю UNIX и всех его потомков ошибкой природы.
A>Вообще-то base64/uue/UTF7 никто не отменял.
И как я тебе это буду глазками читать?
A>И не работать, потому что Printable ASCII...
Да маразм требовать это.
В любом случае я могу воткнуть преобразователь в base64 если транспорт будет этого требовать.
В прочем насколько я помню ни UDP ни TCP этого не требуют.
A>Вовремя ты признался...
А где я говорил что всегда буду использовать IoC в тех местах куда ты воткнешь синглетон?
И говорил и говорю что не использую синглетон.
A>Вообще-то это не моё мнение, а системных администраторов.
Ну значит у нас разные админы...
A>Под линукс практически всегда все серверы и рабочие станции пишут в единый SysLog сервер.
У нас тоже коечто так пишут.
Админы говорят ~30% записей до общего лога не доходят... Ибо UDP.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Знаю. Тут какое дело, зачем заведомое Г официально портировать на несколько языков? WH>А я откуда знаю.
Потому что не Г
A>>Да и комьюнити Apache у меня вызывает некоторое доверие. WH>А у меня нет. Начем с того что апач плохой сервер... Всякие там lighttpd рвут его как тузик грелку.
О_о. Мнда, интересные ты делаешь заявления.
WH>Какая нафиг БД? WH>От такого колличества логов оракл раком встанет. WH>Тут только плоские файлики выживают.
Помимо оракла есть другие БД. На нём свет клином не сошёлся и Оракл далеко не сама производительная БД. А вообще мы в MySQL/MyISAM писали.
WH>А налету gzip'ить не догадался?
А NTFS compression не проще включить? Вот об том я и говорю, нет чтоб исследовать текущую функциональность, всё тебя норовит написать что-то....
A>>IETF это Internet Engineering Task Force хъ WH>Рад что ты это понимаешь.
Вообще то это ты не знал что такое IETF, я то как раз давно знаю. Ещё есть IEEE и ISO Тоже бездельники.
WH>Он очень простой. WH>Нужно просто позволить конфигурить систему так как надо. WH>И все.
Совместимость, совместимость и ещё раз совместимость. На двухядерных атлонах свет клином не сошёлся и даже не на х86.
A>>SysLog тоже выкинь, там по стандарту тоже только Printable ASCII, да ещё и размер датаграмы не больше 1024 байт. WH>Я вобще считаю UNIX и всех его потомков ошибкой природы.
Смеялся. Шеридана что ли позвать... хотя нет, лучше сразу на башорг.
A>>Вообще-то base64/uue/UTF7 никто не отменял. WH>И как я тебе это буду глазками читать?
Вьювером. Почту ты как читаешь, она тоже base64 по TCP/IP гоняется. Ах да, это всё происки злодеев...
A>>И не работать, потому что Printable ASCII... WH>Да маразм требовать это.
Как я уже писал, х86 далеко не единственная платформа.
A>>Вовремя ты признался... WH>А где я говорил что всегда буду использовать IoC в тех местах куда ты воткнешь синглетон?
Ты приводил контрпримеры только с IoC чем и ввёл в заблуждение.
A>>Вообще-то это не моё мнение, а системных администраторов. WH>Ну значит у нас разные админы... A>>Под линукс практически всегда все серверы и рабочие станции пишут в единый SysLog сервер. WH>У нас тоже коечто так пишут. WH>Админы говорят ~30% записей до общего лога не доходят... Ибо UDP.
Ну не такие уж у нас и разные админы, если при потере 30% патеков всё равно пишут всё в один лог А идея, видимо, настолько хороша, что даже 30% потерь недостаточный стимул отказаться. А ты говоришь разные...
Здравствуйте, adontz, Вы писали:
WH>>А налету gzip'ить не догадался? A>А NTFS compression не проще включить? Вот об том я и говорю, нет чтоб исследовать текущую функциональность, всё тебя норовит написать что-то....
А потом этот файл его ручками зиповать, чтобы скачать или отправить по почте?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, adontz, Вы писали:
WH>>>А налету gzip'ить не догадался? A>>А NTFS compression не проще включить? Вот об том я и говорю, нет чтоб исследовать текущую функциональность, всё тебя норовит написать что-то....
AJD>А потом этот файл его ручками зиповать, чтобы скачать или отправить по почте?
100Гб по почте?! AndrewJD, вы опять контекст потеряли. Я уже говорил, бекапилось на кассету стриммера. Откуда вдруг взялась почта? И ведь кто-то, я искрене верю, не подумав, сделает GZip сжатие на тот случай если захотят отправить по почте 100Гб, чтоб всего 13Гб пришлось отправлять. Мнда... В страшное время живём.
Здравствуйте, adontz, Вы писали:
WH>>А у меня нет. Начем с того что апач плохой сервер... Всякие там lighttpd рвут его как тузик грелку. A>О_о. Мнда, интересные ты делаешь заявления.
А ты что не знал?
A>Помимо оракла есть другие БД. На нём свет клином не сошёлся и Оракл далеко не сама производительная БД. А вообще мы в MySQL/MyISAM писали.
В любом случае по производительности последовательной записи ничто не может сравниятся с плоским файлом.
Разве что запись прямо на неразмеченный раздел винта.
A>А NTFS compression не проще включить? Вот об том я и говорю, нет чтоб исследовать текущую функциональность, всё тебя норовит написать что-то....
Не везде есть NTFS.
И вобще закладыватся на особенности реализации конкретной платформы плохая идея.
Кстати если руки прямые то данная функциональность реализуется строк в 30... портабельно...
A>Совместимость, совместимость и ещё раз совместимость. На двухядерных атлонах свет клином не сошёлся и даже не на х86.
Какая еще нафиг совместимость?
Решение абсолютно портабельно.
A>Смеялся. Шеридана что ли позвать...
Зави.
A>хотя нет, лучше сразу на башорг.
Давай.
Только еще никто ниразу не смог объяснить почему аритектура UNIX это хорошо.
Да вобщем и не смогут ибо обосновать логически этот маразм нельзя.
A>Как я уже писал, х86 далеко не единственная платформа.
На каких платформах я немогу отослать пачку байт?
Просвети плиз.
A>Ну не такие уж у нас и разные админы, если при потере 30% патеков всё равно пишут всё в один лог А идея, видимо, настолько хороша, что даже 30% потерь недостаточный стимул отказаться. А ты говоришь разные...
То-то когда я хотел посмотреть как система вела себя и спросил где лежит этот общий лог админы послали мня анализировать локальные копии логов ибо там все данные...
А этот общий лог используется исключительно для того чтобы посмотреть как система работает прямо сейчас.
Для разбора полетов его не используют.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>А у меня нет. Начем с того что апач плохой сервер... Всякие там lighttpd рвут его как тузик грелку. A>>О_о. Мнда, интересные ты делаешь заявления. WH>А ты что не знал?
Да я как погляжу есть очень много "очевидных" истин известных только тебе.
A>>Помимо оракла есть другие БД. На нём свет клином не сошёлся и Оракл далеко не сама производительная БД. А вообще мы в MySQL/MyISAM писали. WH>В любом случае по производительности последовательной записи ничто не может сравниятся с плоским файлом. WH>Разве что запись прямо на неразмеченный раздел винта.
Лог потом надо читать. БД удобнее.
A>>А NTFS compression не проще включить? Вот об том я и говорю, нет чтоб исследовать текущую функциональность, всё тебя норовит написать что-то.... WH>Не везде есть NTFS. WH>И вобще закладыватся на особенности реализации конкретной платформы плохая идея. WH>Кстати если руки прямые то данная функциональность реализуется строк в 30... портабельно...
Сервер уже представлял собой ASP.Net веб-сервис, так что область применения сужена не была. А если на Windows Server нет NTFS, это неправильный Windows Server. Да и на рабочих станциях FAT32 делать нечего.
A>>Совместимость, совместимость и ещё раз совместимость. На двухядерных атлонах свет клином не сошёлся и даже не на х86. WH>Какая еще нафиг совместимость? WH>Решение абсолютно портабельно.
Это твое неправильное мнение. Почему, см. ниже.
A>>хотя нет, лучше сразу на башорг. WH>Давай. WH>Только еще никто ниразу не смог объяснить почему аритектура UNIX это хорошо. Да вобщем и не смогут ибо обосновать логически этот маразм нельзя.
Видишь ли, никто вобщем-то и не объязан объяснять тебе, предубеждённой личности, а, вернее, перебарывать уже сложившееся мнение, почему хороша та или иная архитектура ОС. Такие вещи вообще нельзя убедительно объяснить. До них надо дорости путём работы со многими ОС. Если не ошибаюсь, ты был большим поклонником Синерджи или как там эта управляемая ОС называлась со смешной сетевой производительностью? Ну вот тебе ещё рости и рости значит. Не обижайся, но заявление о плохости архитектуры Юникса при том что ты явно не входишь в число людей разбирающихся в Unix Kernel и пишущих дравера выглядит крайне по-дилетантски. Отвечать на него что либо нет абсолютно никакого желания, даже если бы была возможность.
A>>Как я уже писал, х86 далеко не единственная платформа. WH>На каких платформах я немогу отослать пачку байт? WH>Просвети плиз.
Embedded. Ты вообще абсолютно не в теме. Например, во всех почтовых RFC (скорее всего не только там, просто говорю о том, что сам читал) используется термин не байт, а октет. Знаешь почему? Есть платформы где байт не 8битовый. Вобщем ты бы сперва изучил вопрос, оторвался от PC-compatible, посмотрел что люди делают, задумался почему, а потом уже учил всех жить.
WH>А этот общий лог используется исключительно для того чтобы посмотреть как система работает прямо сейчас. WH>Для разбора полетов его не используют.
Здравствуйте, adontz, Вы писали:
A>Да я как погляжу есть очень много "очевидных" истин известных только тебе.
Это не известно только тебе.
А то что lighttpd под нагрузкой живет намного лучше чем апач является фактом.
lighttpd иногда даже ставят перед апачем для того чтобы система написанная под апач не задыхалась.
И это тоже факт.
Отрицать его бесполезно.
A>Лог потом надо читать. БД удобнее.
Дело в том что у меня сильно нагруженная система.
И втыкать туда лишнюю БД это самоубийство.
Пусть лучше анализ займет немного больше времени чем система сдохнет в продакшене.
A>Сервер уже представлял собой ASP.Net веб-сервис, так что область применения сужена не была. А если на Windows Server нет NTFS, это неправильный Windows Server. Да и на рабочих станциях FAT32 делать нечего.
Mono...
В любом случае при правильной архитектуре нужно былобы прописать одну строчку в конфиге...
A>Это твое неправильное мнение. Почему, см. ниже.
Нет там ничего.
A>Видишь ли, никто вобщем-то и не объязан объяснять тебе, предубеждённой личности, а, вернее, перебарывать уже сложившееся мнение, почему хороша та или иная архитектура ОС.
Да не обязан.
Но ведь жилающие есть... но только аргументов у них нет.
A>Такие вещи вообще нельзя убедительно объяснить.
Можно.
Нужно лишь перечислить плюсы и минусы того или иного решения.
И чтобы плюсов оказалось больше.
A>До них надо дорости путём работы со многими ОС.
Я работал и изучал архитектуры не одной ОС.
A>Если не ошибаюсь, ты был большим поклонником Синерджи или как там эта управляемая ОС называлась со смешной сетевой производительностью?
Вобще говоря это исследовательсякая ОС производительностью которой не занимались.
A>Ну вот тебе ещё рости и рости значит. Не обижайся, но заявление о плохости архитектуры Юникса при том что ты явно не входишь в число людей разбирающихся в Unix Kernel и пишущих дравера выглядит крайне по-дилетантски.
Я пишу под эту хрень системы живущие под огромной нагрузкой.
На RSDN по сравнению с ними вобще никто не ходит.
A>Отвечать на него что либо нет абсолютно никакого желания, даже если бы была возможность.
В том то и дело что никто не может ответить.
Ибо обосновать очевидные маразмы типа необходимости склонировать текущий процесс (клонирование процессов само по собе маразм) для того чтобы запустить новый нререально.
A>Embedded. Ты вообще абсолютно не в теме. Например, во всех почтовых RFC (скорее всего не только там, просто говорю о том, что сам читал) используется термин не байт, а октет. Знаешь почему? Есть платформы где байт не 8битовый. Вобщем ты бы сперва изучил вопрос, оторвался от PC-compatible, посмотрел что люди делают, задумался почему, а потом уже учил всех жить.
Про различные архитектуры я знаю не хуже тебя.
Вот только сколько процентов железок работают с чемто отличным от 8ми битового байта?
A>Мои используюст 100%. Я сам нередко использую.
Значит у тебя нагрузки никакие.
При больших нагрузках по побитым логам ничего не понять.
А при перегрузках (ботнет пришол) данных до общего лога доходит еще меньше.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Да я как погляжу есть очень много "очевидных" истин известных только тебе. WH>Это не известно только тебе. WH>А то что lighttpd под нагрузкой живет намного лучше чем апач является фактом. WH>lighttpd иногда даже ставят перед апачем для того чтобы система написанная под апач не задыхалась. WH>И это тоже факт. WH>Отрицать его бесполезно.
Ну если производительность это тот единственный фактор по которому ты так резво делишь веб-сервера на хорошие и плохие, да ещё и фыркаешь на сообщество Apache, то остаётся тебе только посочувствовать потому что в веб-серверах ты не понимаешь нихрена.
WH>Да не обязан. WH>Но ведь жилающие есть... но только аргументов у них нет.
А те у кого есть, не хотят с тобой связываться так как у них, как людей знающих, а следовательно занятых, нет времени на обучение упёртых личностей. Не думал об этом? Просто как вариант. Ты ведь не просишь сравнительный анализ, не просишь что-то объяснить, ты говришь "Unix — говно. А ну ка кто докажет, что нет?".
WH>Я пишу под эту хрень системы живущие под огромной нагрузкой. WH>На RSDN по сравнению с ними вобще никто не ходит.
Можешь назвать хоть одну? Просто интересно оценить огромность нагрузки. Без технических подробностей, конечно, которые ты, наверняка, всё равно не имеешь права разглашать. Кстати RSDN с его блокировками вообще не аргумент. Я когда с веб-интерфейса отправляю сообщения и тут же в другом окне делаю рефреш, у меня пока сообщение не отправиться, ветка не загружается. С такими подходами делать РСДН точкой отсчёта явно не стоит.
WH>Ибо обосновать очевидные маразмы типа необходимости склонировать текущий процесс (клонирование процессов само по собе маразм) для того чтобы запустить новый нререально.
fork'ом надо просто правильно пользоваться чтобы новый дочерний процесс всё из родительского использовал в режиме read-only иначе COW тебя поимеет. Вообще в Unix и Windows понятия процесса слишком уж различны.
WH>Про различные архитектуры я знаю не хуже тебя. WH>Вот только сколько процентов железок работают с чемто отличным от 8ми битового байта?
Даже если меньше 1%, универсальный стандарт должен это учесть.
WH>При больших нагрузках по побитым логам ничего не понять. WH>А при перегрузках (ботнет пришол) данных до общего лога доходит еще меньше.
Это старвейшен подкрался. Я бы приём сообщения из сети и запись разделил на две независимые асинхронно работающие системы. Ещё можно промежуточные релеи делать, которыу будут балансировать нагрузку, да и без них через NLB или его аналог работать. Вобщем было бы желание.
Здравствуйте, adontz, Вы писали:
A>Ну если производительность это тот единственный фактор по которому ты так резво делишь веб-сервера на хорошие и плохие, да ещё и фыркаешь на сообщество Apache,
Кроме производительности есть еще стабильность и функциональность.
Со стабильностью у лайти все в порядке.
С функцилональностью вобщемто тоже.
A>то остаётся тебе только посочувствовать потому что в веб-серверах ты не понимаешь нихрена.
О великий гуру раскажи мне про вебсерверы.
A>А те у кого есть, не хотят с тобой связываться так как у них, как людей знающих, а следовательно занятых, нет времени на обучение упёртых личностей.
Ктобы говорил про упертых личностей...
A>Не думал об этом? Просто как вариант. Ты ведь не просишь сравнительный анализ, не просишь что-то объяснить, ты говришь "Unix — говно. А ну ка кто докажет, что нет?".
Я не просто говорю что UNIX говно. Я говорю почему он говно.
И никто не смог опровргнуть мои аргументы.
A>Можешь назвать хоть одну? Просто интересно оценить огромность нагрузки. Без технических подробностей, конечно, которые ты, наверняка, всё равно не имеешь права разглашать.
Сотни миллионов запросов в сутки. Объем данных на сервере приближается к 10ТБ и будет рости дальше.
Кластер масштабируется линейно. Просто ставишь машины, наливаешь софт и вперед.
Плюс всякие там failover'ы, балансировка нагрузки, оптимизация трафика и прочие бла-бла-бла
A> Кстати RSDN с его блокировками вообще не аргумент. Я когда с веб-интерфейса отправляю сообщения и тут же в другом окне делаю рефреш, у меня пока сообщение не отправиться, ветка не загружается. С такими подходами делать РСДН точкой отсчёта явно не стоит.
У меня скорости нехватает чтобы это повторить.
A>fork'ом надо просто правильно пользоваться чтобы новый дочерний процесс всё из родительского использовал в режиме read-only иначе COW тебя поимеет. Вообще в Unix и Windows понятия процесса слишком уж различны.
Раскажи мне как правильно пользоваться форком.
Я думаю авторы апача тоже с удовольствием послушают...
Кстати задумайся над тем почему появился второй апач...
Ведь первый использовал супер пупер мегафичу fork!
A>Даже если меньше 1%, универсальный стандарт должен это учесть.
Printable ASCII то тут причем?
A>Это старвейшен подкрался. Я бы приём сообщения из сети и запись разделил на две независимые асинхронно работающие системы. Ещё можно промежуточные релеи делать, которыу будут балансировать нагрузку, да и без них через NLB или его аналог работать. Вобщем было бы желание.
А тебе не приходило в голову что из-за перегрузки сети просто напросто теряются пакеты и многие датаграммы просто недоходят?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Мой самый важный аргумент это ссылка на многолетний опыт.
AndrewJD, вы опять контекст потеряли. Я уже говорил, бекапилось на кассету стриммера. Откуда вдруг взялась почта? И ведь кто-то, я искрене верю, не подумав, сделает GZip сжатие на тот случай если захотят отправить по почте 100Гб, чтоб всего 13Гб пришлось отправлять. Мнда... В страшное время живём.
