DEA>%Subj% чтобы забить топик
DEA>Впрочем, серьезно: DEA>(a) мой домашний контупер уже пятый год работает под Win2k и есть не просит. DEA>(б) мой рабочий контупер тоже немало работает под WinХР и тоже ничего особенного не просит.
DEA>Яжу понятно, что как только понадобятся усерам вистовые рюшечки да глюкальчики, мне придется ее ставить на рабочем компе чтобы глюкальчики эти отработать, но сие есть гемор моей канторы. А вот нафига это делать на компе домашнем?
Здравствуйте, Sheridan, Вы писали:
S>А зачем тебе линукс? Подумай сам. Там думать надо.
Я понял. Это новый виток истории про "нам думать некогда — нам трясти надо!". Теперь, когда трясут, считают, что не трясут, а думают. И гордятся этим! Кто вообще думать будет, если даже в словаре у этого слова теперь другое значение?
Потряс немного Linux — и ты уже можешь считать себя первостатейным мегамозгом, потряс C++ — считай, Дирак и Джойс в одном лице. Что еще для счастья надо?
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, ilya_ny, Вы писали:
_>>
S>А зачем тебе линукс? Подумай сам. Там думать надо. Оно тебе надо? Поставь висту. Там надо не думать. Там платить надо. Оно?
Sheridan, давно гением стал?
Вот очередной раз убеждаюсь, что большинство линуксоидов убогие какие-то. Им оскорбить человека как 2 байта отослать. "Гении", млин.
Сложность программы растет до тех пор, пока не превысит способности программиста
Здравствуйте, Menestrel, Вы писали:
M>Sheridan, давно гением стал?
Я дурак.
M>Вот очередной раз убеждаюсь, что большинство линуксоидов убогие какие-то. Им оскорбить человека как 2 байта отослать.
Виндузятники считают линукстологов этакими сумашедшими. Априори. Это как-бы считается нормой.
А потом обижаются.
Ну где там оскорбление? Сказать правду — уже оскорбление? То что в виндах думать не надо — плати только — не так все разве?
Я согласен что настрпоить надо и прочее. Дык тоже можно не вдумываться — звони в техподдержку. Не так? Windows поощряет лень. Где здесь оскорбления? Или правда глаза режет?
ps воспринимай этот текст как некий крик души в пустоту — легче понять будет.
[RSDN@Home][1.2.0][alpha][667]
[Кто не может взять лаской, тот не возьмет и строгостью. [А.П. Чехов]]
Здравствуйте, Menestrel, Вы писали:
M>Вот очередной раз убеждаюсь, что большинство линуксоидов убогие какие-то. Им оскорбить человека как 2 байта отослать. "Гении", млин.
Вам, судя по всему, тоже мало чего стоит...
Здравствуйте, Sheridan, Вы писали:
S>То что в виндах думать не надо — плати только — не так все разве? S>Я согласен что настрпоить надо и прочее. Дык тоже можно не вдумываться — звони в техподдержку. Не так? Windows поощряет лень.
насчет бесплатности линукса и "платности" хорошего софта под винды http://doci.nnm.ru/infoparazitizal/15.01.2006/freeware_opensource_soft_pod_windows/ вот по этому линку, внушительный список бесплатных программ под винду. Большинство из них юзается мной в качестве замены аналогичного платного софта. Причем, самого распространенного в плане потребностей "обычного пользователя".
Так что, в этом плане — преимуществ пока у линукса не вижу. Под винду есть кучи полнофункциональных бесплатных программ.
немного пофилософствуем...
насчет так называемой "лени".
Шеридан, есть жизнь и вне 4-ч стен оффиса или квартиры.
и она ЕСТЬ!
она СУЩЕСТВУЕТ!
считаю абсолютно глупым тратить кучу времени на то, чтобы изучать линукс,настраивать его, тратить время на попытки прикрутить через какие-нибудь эмуляторы возможность поиграть в игрушку какую-нибудь... лазить по форумам, читать многочисленные мануалы — и всё ради того ,чтобы оно заработало, и заработало примерно так, как оно работает по дефаулту в винде. И это всё вместо того, чтобы потратить это же время на встречи с друзьями, на живое непосредственное общение. чтобы сходить на интересную выставку или концерт, чтобы как можно чаще встречаться со своей девушкой ,чаще заходить к родителям в гости домой — они очень рады увидеть своего сына... Чаще сходить в бассейн, а по выходным покататься на лошадях, съездить на турбазу или просто "на шашлыки"...
я социально активный человек, я испытываю удовольствие от жизни и от общения с людьми, так какого хрена я должен тратить кучу времени и усилий на вобщем то вещи, которые должны быть рутинными и обыденными, если я могу потратить кучу времени на действительно приятные и значимые вещи?
есть ли жизнь вне компьюетрной железяки и линукса? ЕСТЬ — и это классная жизнь!
Профессиональная сфера... Появляются новые технологии, надо выделять время в течении недели и на изучение новых всяких фич в области девелопмента, а не только социально активную жизнь. Почитать о новых паттернах и практиках или о почитать о новых способах применения существующих паттернов и практик, почитать еще новую какую-нибудь доку по процессам девелопмента, о новых тулзах и тд и тп. Т.е. нужно себя поддерживать постоянно в "форме" и на должном уровне. На это тоже уходит время. И почему я это время потраченное, но которое делает меня еще более профессионально подкованным и востребованным на рынке труда и,соответственно, позволяет иметь по местным меркам очень неплохую зарплату — должен тратить на изучение линукса, на изучение того, как от компьютера получить ровно то же, но с геммором и кучей головняка, вместо того, чтобы аналогичные операции проделать в винде совершенно не задумываясь, ибо винда изначально рассчитана на простоту и удобство для пользователя
и если разобраться, стоит ли всего этого выше перечисленного — несчастная сотня-полторы баксов, которая будет к тому же "разнесена" на несколько лет (многие винду меняют раз в три года) — конечно,стоит. Про сопуствующий аналогичный бесплатный полнофункциональный софт — смотри линк выше.
И причем, если кто-то вопить будет, что сотня-полторы — это много
а) см. выше про кабак
б) у меня сча друг в Москве со старой хаты съезжал. Стал искать новую. Дешевле 6-ти сотен не нашел Получается, что стоимость винды разнесенная к тому же года на три юзания, составляет всего лишь одну шестую-одну пятую от стоимость МЕСЯЧНОГО съема хаты в Москве! Офигеть как дорого!
но даже без привязки к московским ценам — для нормально высококвалифицированного айтишника, сотня-полторы баксов и к тому же разнесенная на несколько лет (взять, даже три года — стока в среднем народ юзает одну операционку, 36 месяцев, поделим ну допустим накую нибудь 150 баксов где-то, итого получиться. что траты составляют где-то 4 бакса в месяц ) ну, возьмем, допустим, стоимость Ultimate, она там вроде где-то три сотни. Итого, получается, 8 баксов в месяц. Офигеть, какие сумашедшие деньги! ) на однократный обед народ зачастую больше тратит ) ) — не составляет абсолютно никакой проблемы.
вобщем, Шеридан, поэтому пока бесплодны твои попытки заманить людей на линукс. операционная система — это всего лишь инструмент, а не самоцель.
когда линукс-сообщество это поймет и "повернется лицом к людям", тогда и будет успех.
а сча...
пустые сотрясения воздуха....
не надо заставлять людей напрягатсья там, где напрягатсья то и не стоит
но, в тоже время можно предоставить возможность людям, которым надо покопаться во внутренностях — и такую возможность
"вудь проще, и люди к тебе потянуться" — старая народная мудрость
применима и для айти
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Menestrel, Вы писали:
S>Виндузятники считают линукстологов этакими сумашедшими. Априори. Это как-бы считается нормой. S>А потом обижаются. S>Ну где там оскорбление? Сказать правду — уже оскорбление? То что в виндах думать не надо — плати только — не так все разве? S>Я согласен что настрпоить надо и прочее. Дык тоже можно не вдумываться — звони в техподдержку. Не так? Windows поощряет лень. Где здесь оскорбления? Или правда глаза режет?
Слова, слова. Ну вот обясните мне, почему это в линухе надо думать, а в виндах нет? Потому что в линухе мегаконсоль (мне, кстати Z Shell очень нравится )? Думаю, мало кто из нынешних линуксоидов живет консолью. KDE, GNOME и все такое прочее. Хорошо, можно сказать, что раз есть мегаконсоль, то надо думать. Невзирая на то, что ей мало кто пользуется сейчас. Но и в виндах, предствьте, теперь тоже есть мегаконсоль — MONAD. Слахали. Оч. приятная вешь. Базируется на .Net 2.0. Т.е. доступ почти ко всему фреймворку из консоли — это знаете ли, сильно. Так что ша! В виндах мегаконсоль — в виндах надо думать!
Здравствуйте, _wah, Вы писали:
_>насчет бесплатности линукса и "платности" хорошего софта под винды ..... _>Так что, в этом плане — преимуществ пока у линукса не вижу. Под винду есть кучи полнофункциональных бесплатных программ.
Откуда они по большей части? ы?
_>немного пофилософствуем... _>насчет так называемой "лени". _>Шеридан, есть жизнь и вне 4-ч стен оффиса или квартиры. _>и она ЕСТЬ! _>она СУЩЕСТВУЕТ!
Есть такое дело, согласен. Бывает точнее сказать.
_>считаю абсолютно глупым тратить кучу времени на то, чтобы изучать линукс,настраивать его, ..... _>есть ли жизнь вне компьюетрной железяки и линукса? ЕСТЬ — и это классная жизнь!
Хорошо тебе — куча друзей, есть деньги на выед на природу, на концерт и прочие развлечения.
Но это частности конечно. Тебе повезло, мне нет. Друзья в Ставрополе, я в Минеральных Водах. Нет, тут конечно тоже несколько человек есть, но времени нет ни у кого на всякую глупость типа на природу съездить. Хочеш — приежжай в гости, организуем шашлычок...
_> Профессиональная сфера... .........
На работе я уже не программирую после завала пары проектов изза отсутствия ТЗ. Теперь я на техподдержке. Так что предпочитаю всетаки пока что расширять область знаний, а не углублять.
_>и если разобраться, стоит ли всего этого выше перечисленного — несчастная сотня-полторы баксов, которая будет к тому же "разнесена" на несколько лет (многие винду меняют раз в три года) — конечно,стоит. Про сопуствующий аналогичный бесплатный полнофункциональный софт — смотри линк выше.
Если разобраться то у меня (да и не только у меня конечно) зп меньше 400 американских президентов. Стоит покупать винду и прочия с такой зп?
_>И причем, если кто-то вопить будет, что сотня-полторы — это много
см. выше.
_>б) у меня сча друг в Москве со старой хаты съезжал. Стал искать новую. Дешевле 6-ти сотен не нашел Получается, что стоимость винды разнесенная к тому же года на три юзания, составляет всего лишь одну шестую-одну пятую от стоимость МЕСЯЧНОГО съема хаты в Москве! Офигеть как дорого!
Ну мне тут проще немного. Полдома от уехавших в москву родственников осталось. Только коммуналку плачу.
_>но даже без привязки к московским ценам — .... что траты составляют где-то 4 бакса в месяц ... — не составляет абсолютно никакой проблемы.
Очень вкусно у тебя получается... 4 бакса в месяц. Повторяю — у меня зп меньше 400. И при этом мне надо месяц на подножном корме жить дабы винду купить?
_>вобщем, Шеридан, поэтому пока бесплодны твои попытки заманить людей на линукс.
Да, я это начинаю понимать. Если деньги есть — народ расслабляется, что в принципе верно.
_>операционная система — это всего лишь инструмент, а не самоцель.
Микрософт из винды тоже инструмент сделал. Инструмент типа тисков. Бабки выжимать из народа.
_>когда линукс-сообщество это поймет и "повернется лицом к людям", тогда и будет успех.
гм... линукс какраз таки лицом и повернут.
_>а сча... _>пустые сотрясения воздуха.... _>не надо заставлять людей напрягатсья там, где напрягатсья то и не стоит
А где же стоит?
_>но, в тоже время можно предоставить возможность людям, которым надо покопаться во внутренностях — и такую возможность
в линуксе пожалуйста — копайся сколько угодно.
_>"вудь проще, и люди к тебе потянуться" — старая народная мудрость _>применима и для айти
Да я прост как 3 копейки.
Здравствуйте, Farsight, Вы писали:
F>Слова, слова. Ну вот обясните мне, почему это в линухе надо думать, а в виндах нет? Потому что в линухе мегаконсоль (мне, кстати Z Shell очень нравится )?
При чем тут мега консоль? галочек нету — это да. Читать доки приходится. Настраивать. Зато на века.
F>Думаю, мало кто из нынешних линуксоидов живет консолью. KDE, GNOME и все такое прочее. Хорошо, можно сказать, что раз есть мегаконсоль, то надо думать. Невзирая на то, что ей мало кто пользуется сейчас.
Ну... В кде есть konsole, в gnome есть gnome-terminal (вроде), да и вообще есть всякие *term... И не надо думать что раз есть иксы то консоль отмирает. Нет, консоль живее всех иксов. Просто там удобнее. Например что быстрее — вызвать диалог поиска, жмакнуть на поле ввода, написать имя файла, жмакнуть опятьже мышой (ладно, таб понажимать) на кнопку и ждать пока найдет или вызвать консоль и напрать slocate имяфайла — enter?
F>Но и в виндах, предствьте, теперь тоже есть мегаконсоль — MONAD. Слахали. Оч. приятная вешь. Базируется на .Net 2.0. Т.е. доступ почти ко всему фреймворку из консоли — это знаете ли, сильно.
Тоесть дополнительная фича, базирующаяся вдобавок на бэйсике. Извините конечно поклонники дотнета, но я как относился к дотнету как к бэйсику, так и продолжаю так-же к нему относиться.
F>Так что ша! В виндах мегаконсоль — в виндах надо думать!
Да везде надо думать... Где больше, а где меньше
[RSDN@Home][1.2.0][alpha][667]
[Вероятностные знания — вот предел человеческого разумения. [Цицерон]]
Здравствуйте, Sheridan, Вы писали:
S>При чем тут мега консоль? галочек нету — это да. Читать доки приходится. Настраивать. Зато на века.
Ну-ну. Впрочем, возможно. Если руки прямые, то и винда на века.
S>Ну... В кде есть konsole, в gnome есть gnome-terminal (вроде), да и вообще есть всякие *term... И не надо думать что раз есть иксы то консоль отмирает. Нет, консоль живее всех иксов. Просто там удобнее. Например что быстрее — вызвать диалог поиска, жмакнуть на поле ввода, написать имя файла, жмакнуть опятьже мышой (ладно, таб понажимать) на кнопку и ждать пока найдет или вызвать консоль и напрать slocate имяфайла — enter?
Много ли таких патриотов консоли? Сомневаюсь. Большая часть, это бывшие виндузятники, врутившие себе последнюю версию суси, и поднявшие ор типа "винда мастдай". Большая часть из них, если бы попробовала иксы настроить во FreeBSD, вернулась бы на винды, тихо поджав хвост. И эта большая часть, небось, подпрыгивает от страха при звуке *term...
S>Тоесть дополнительная фича, базирующаяся вдобавок на бэйсике. Извините конечно поклонники дотнета, но я как относился к дотнету как к бэйсику, так и продолжаю так-же к нему относиться.
Фича. Базирующаяся на фреймворке, а не на бейсике. Фреймворк базируется на виндовых апишных функциях. При чем тут бейсик? Лучше не развивать эту тему.
S>Да везде надо думать... Где больше, а где меньше
Согласен.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Farsight, Вы писали:
S>Тоесть дополнительная фича, базирующаяся вдобавок на бэйсике. Извините конечно поклонники дотнета, но я как относился к дотнету как к бэйсику, так и продолжаю так-же к нему относиться.
Сам-то понял, что сказал? Sheridan, извини, конечно, но мое мнение о тебе как о весьма поверхностном "специалисте" подтверждается все больше и больше. Тебе бы не на форумах миссией быть, а поучиться что-ли?
Сложность программы растет до тех пор, пока не превысит способности программиста
Здравствуйте, Menestrel, Вы писали:
S>>Тоесть дополнительная фича, базирующаяся вдобавок на бэйсике. Извините конечно поклонники дотнета, но я как относился к дотнету как к бэйсику, так и продолжаю так-же к нему относиться.
M>Сам-то понял, что сказал? Sheridan, извини, конечно, но мое мнение о тебе как о весьма поверхностном "специалисте" подтверждается все больше и больше. Тебе бы не на форумах миссией быть, а поучиться что-ли?
Гм, я на шарпе уже не программлю, мне можно так к нему относиться
Я сейчас в qt4 ушел. Также php, shell, немного перла...
[RSDN@Home][1.2.0][alpha][667]
[Гений есть не что иное, как дар огромного терпения. [Ж. Бюффон]]
Здравствуйте, Sheridan, Вы писали:
M>>Сам-то понял, что сказал? Sheridan, извини, конечно, но мое мнение о тебе как о весьма поверхностном "специалисте" подтверждается все больше и больше. Тебе бы не на форумах миссией быть, а поучиться что-ли? S>Гм, я на шарпе уже не программлю, мне можно так к нему относиться S>Я сейчас в qt4 ушел. Также php, shell, немного перла...
да да, ты мир уже познал, смысл жизни понял... а все остальные -- так, малышня пузатая. им еще учиться и учиться
S>Ну где там оскорбление? Сказать правду — уже оскорбление? То что в виндах думать не надо — плати только — не так все разве? S>Я согласен что настрпоить надо и прочее. Дык тоже можно не вдумываться — звони в техподдержку. Не так? Windows поощряет лень. Где здесь оскорбления? Или правда глаза режет?
Странное дело: когда речь идет о покупке машины, то выбирать надо непременно иномарку, потому что там сел и поехал, не надо думать о ремонте, обслуживании и т.п. Однако те же доводы — "поставил — и работай" — в отношении систем не действуют, просто поставить — это не круто, недостойно настоящего программиста, надо сначала потрахаться неделю, вот тогда можешь с гордостью называться программистом. Что ж вы тогда жигули не покупаете? Там тоже надо все разобрать, подтянуть, смазать, тогда можно потихоньку ехать. А со временем привыкнишь, наберешься опыта и можешь называться крутым водилой.
Невозможно чтобы у всех было всё, так как всех много, а всего мало...
Здравствуйте, _rasta, Вы писали:
_>да да, ты мир уже познал, смысл жизни понял... а все остальные -- так, малышня пузатая. им еще учиться и учиться
Да я давно уже понял что стоит сказать что шарп это бэйсик, срааазу все обижаться начинают. Минусов ставят и прочего говорят. Я же на все не обижаюсь когда коворят что мол линукс это зло .
Я понимаю что шарп мегакрут а немерль еще круче. Что это все работает быстро вполне и доступно в обучении. Что и доки и примеры есть. Что на них писать и быстрее и удобнее. Действительно понимаю. Да вот только от концепции бэйсика микрософт никогда не откажется. Раньше такое называлось VB, теперь .net + c#, что будет дальше — хз.
И уж извините меня дурака но вы меня не переубедите что это бэйсик.
[RSDN@Home][1.2.0][alpha][667]
[Обычай — деспот меж людей. [А. С. Пушкин]]
Здравствуйте, asdfghjkl, Вы писали:
A>Странное дело: когда речь идет о покупке машины, то выбирать надо непременно иномарку, потому что там сел и поехал, не надо думать о ремонте, обслуживании и т.п. Однако те же доводы — "поставил — и работай" — в отношении систем не действуют, просто поставить — это не круто, недостойно настоящего программиста, надо сначала потрахаться неделю, вот тогда можешь с гордостью называться программистом. Что ж вы тогда жигули не покупаете? Там тоже надо все разобрать, подтянуть, смазать, тогда можно потихоньку ехать. А со временем привыкнишь, наберешься опыта и можешь называться крутым водилой.
Слушай, а ты линукс случайно не три-пять лет назад видел?
OpenSuSE 10.1 сейчас поставить проще, чем WinXP и конфигурация по умолчанию будет настроена лучше для использования в качестве десктопа. А в винде у меня куча проблем, и как их "подкручивать" я ума не приложу, хотя хотелось бы — приходится в ней работать. В линуксе, кстати, я большей частью только тогда, когда в Quake3 поиграть охота.
Здравствуйте, asdfghjkl, Вы писали:
A>Странное дело: когда речь идет о покупке машины, то выбирать надо непременно иномарку, потому что там сел и поехал, не надо думать о ремонте, обслуживании и т.п.
Аналогия неуместна имхо. Если бы я мог прити в автосалон, заказать тип кузова, двигатель и прочую начинку, и получить автомобиль своей конфигурации, заплатив при этом меньше (да пусть даже и ненамного больше) денег... Или вообще, разобраться в данной области, дешево приобрести нужные комплектующие (читай — скачать из сети почти на халяву), потратить неделю на сборку, и безо всяких регистраций/техосмотров мог свободно разъезжать по улице, я бы так и поступил. И думаю, не только я.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
S>>То что в виндах думать не надо — плати только — не так все разве? S>>Я согласен что настрпоить надо и прочее. Дык тоже можно не вдумываться — звони в техподдержку. Не так? Windows поощряет лень.
_>насчет бесплатности линукса и "платности" хорошего софта под винды http://doci.nnm.ru/infoparazitizal/15.01.2006/freeware_opensource_soft_pod_windows/ вот по этому линку, внушительный список бесплатных программ под винду. Большинство из них юзается мной в качестве замены аналогичного платного софта. Причем, самого распространенного в плане потребностей "обычного пользователя". _>Так что, в этом плане — преимуществ пока у линукса не вижу. Под винду есть кучи полнофункциональных бесплатных программ.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, _rasta, Вы писали:
_>>да да, ты мир уже познал, смысл жизни понял... а все остальные -- так, малышня пузатая. им еще учиться и учиться
S>Да я давно уже понял что стоит сказать что шарп это бэйсик, срааазу все обижаться начинают. Минусов ставят и прочего говорят. Я же на все не обижаюсь когда коворят что мол линукс это зло .
S>Я понимаю что шарп мегакрут а немерль еще круче. Что это все работает быстро вполне и доступно в обучении. Что и доки и примеры есть. Что на них писать и быстрее и удобнее. Действительно понимаю. Да вот только от концепции бэйсика микрософт никогда не откажется. Раньше такое называлось VB, теперь .net + c#, что будет дальше — хз.
S>И уж извините меня дурака но вы меня не переубедите что это бэйсик.
Есть фишка такая — производительность программиста на квадратный дюйм кода. В этом отношении Qt также можно сравнить с Бэйсиком, как и C# с Бэйсиком — и Qt и C# облегчают работу программиста. Делают ее такой же легкой, как некогда вообще было программироавние на Бэйсике.
Но и Qt и C# позволяют так же легко решать задачи гораздо более высокого плана, чем Бэйсик.
И если появится язык, который позволит мне программировать так же легко, как на Бэйсике, но при этом позволит мне решать огромное количество задач, я буду просто рад.
Быть может, это и есть Немерле, кто знает (кстати, Немерле к МС никакого отношения не имеет )... А может еще что объявится...
Здравствуйте, Sheridan, Вы писали:
S>На работе я уже не программирую после завала пары проектов
Вот это причина по которой у тебя нет и не будет денег. Ибо проекты валишь. Как только перестанешь валить проекты так сразу появятся деньги.
S>изза отсутствия ТЗ.
А это уже отмазка. Если ТЗ не ясно нужно идти и уточнять. Или если уточнить не реально то в лес такого работодателя. Всеравно ни интереса не денег с такой работы не будет. Кстати что забавно платят хорошо только за интересную работу... за всякую рутину платят ровно столько чтобы не сдохнуть с голоду.
S>Теперь я на техподдержке.
Странно что совсем не уволен.
S>Так что предпочитаю всетаки пока что расширять область знаний, а не углублять.
И очень напрасно. Знания нужно углублять.
Вот например я до текущей работы с линухом вобще не имел никаких дел. Я его даже поиграться не ставил.
Так вот я спокойно сел и спокойно начал писать изучая man'ы по ходу дела.
Время на адаптацию у меня ушло ровно столько сколько обычно уходит на адаптацию в любом другом большом проекте.
Кстати меня сейчас интересует одна тема... но знания по вопросу не достаточно глубокие. Так вот и просто пошол и купил 5 толмудов за 2000р. Теперь читаю.
Когда раскручу то что я задумал там будет очень много интересной работы... а сколко будет денег когда оно начнет продаваться...
S>Если разобраться то у меня (да и не только у меня конечно) зп меньше 400 американских президентов. Стоит покупать винду и прочия с такой зп?
А может нужно просто менять город? Например на Москву? Если есть мозги то за вычетом квартиры и налогов 1000$-1500$ можно иметь белыми наруки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sheridan, Вы писали:
F>>Но и в виндах, предствьте, теперь тоже есть мегаконсоль — MONAD. Слахали. Оч. приятная вешь. Базируется на .Net 2.0. Т.е. доступ почти ко всему фреймворку из консоли — это знаете ли, сильно. S>Тоесть дополнительная фича, базирующаяся вдобавок на бэйсике. Извините конечно поклонники дотнета, но я как относился к дотнету как к бэйсику, так и продолжаю так-же к нему относиться.
Ты по што всяку гадость с БЭЙСИКОМ сравниваешь? ((((((((((((((((((((((((((((
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, WolfHound, Вы писали:
S>>Если разобраться то у меня (да и не только у меня конечно) зп меньше 400 американских президентов. Стоит покупать винду и прочия с такой зп? WH>А может нужно просто менять город? Например на Москву? Если есть мозги то за вычетом квартиры и налогов 1000$-1500$ можно иметь белыми наруки.
ооо... имхо это отдельная тема для св.
что-то вроде "надо ли переться в москву за длинным рублем, чтобы она рано или поздно лопнула, или надо сделать так, чтобы везде было достаточно не плохо?".
Здравствуйте, WolfHound, Вы писали:
S>>изза отсутствия ТЗ. WH>А это уже отмазка. Если ТЗ не ясно нужно идти и уточнять.
Уточнения довели что приходилось переписывать кусками заново. В итоге плевал и продолжал хоть чтото что есть но не успевал.
WH>Кстати что забавно платят хорошо только за интересную работу... за всякую рутину платят ровно столько чтобы не сдохнуть с голоду.
Выбирать интересное / рутино можно, если есть выбор.
WH>Странно что совсем не уволен.
А это если есть выбор у работодателя.
S>>Так что предпочитаю всетаки пока что расширять область знаний, а не углублять. WH>И очень напрасно. Знания нужно углублять.
Вот какраз щас начал углублять qt. С линухом уже практически на "ты", по крайней мере с gentoo.
WH>Вот например я до текущей работы с линухом вобще не имел никаких дел. Я его даже поиграться не ставил. WH>Так вот я спокойно сел и спокойно начал писать изучая man'ы по ходу дела. WH>Время на адаптацию у меня ушло ровно столько сколько обычно уходит на адаптацию в любом другом большом проекте.
И что, так ли все плохо, как тут большинство пытается доказать?
WH>А может нужно просто менять город? Например на Москву? Если есть мозги то за вычетом квартиры и налогов 1000$-1500$ можно иметь белыми наруки.
Уехать куда-либо вообще нет возможности, ибо в таком случае испортится карьера жены.
Я тут както спросил у одного человечка в минводах — есть мол работа админом тыщ хотябы на 9... Человечек сделал удивленные глаза и сказал, что мол тут некоторые бегают по 4м-5ти предприятиям — админят, и штук 8-9 какраз и выходит.
[RSDN@Home][1.2.0][alpha][667]
[Легче переносить терпеливо то, что нам не дано исправить. [Гораций]]
При наличии видео от nvidia xgl уже можно не ставить. В последних драйверах nvidia требуемый функционал уже есть. Ставиш дрова, beryl, emerald и их окружение и будет тебе щастье
[RSDN@Home][1.2.0][alpha][667]
[Истина всегда оказывается проще, чем можно было предположить. [Р. Фейнман]]
Здравствуйте, Sheridan, Вы писали:
_>>да да, ты мир уже познал, смысл жизни понял... а все остальные -- так, малышня пузатая. им еще учиться и учиться S>И уж извините меня дурака но вы меня не переубедите что это бэйсик.
это твое мнение как тестера со стажем, или как программиста, завалившего пачку проектов?
Здравствуйте, Sheridan, Вы писали:
S>Уточнения довели что приходилось переписывать кусками заново.
Нужно уточнять до того как придется переписывать кучу кода. S>В итоге плевал и продолжал хоть чтото что есть но не успевал.
Есть у меня такое чувство что дело таки не в работодателе.
S>Выбирать интересное / рутино можно, если есть выбор.
Выбор всегда есть. Единственный кото может ограничить твой выбор это ты сам.
S>А это если есть выбор у работодателя.
Как все запущенно то...
S>Вот какраз щас начал углублять qt.
Не то углубляешь. Нужно углублять фундаментальные знания, а не какуюто там библиотчечку.
Библиотеки это фигня. Их многие тысячи. И углублять знания по каждой жизни не хватит.
Что касается тебя то судя по тому что ты пишешь знания у тебя очень поверхностные.
Короче бросай Qt и начинай изучать фундаментальные вещи. S>С линухом уже практически на "ты", по крайней мере с gentoo.
Человек в общении с компьютером проходит 3 стадии:
1)На Вы.
2)На ты.
3)На ты козёл!
Так вот я начал общение с линухом сразу с третей стадии.
Мне просто показали что где лежит и все. Дальше сам. Вопросы у меня возникали только по внутреннему софту на которой доков нет вобще.
S>И что, так ли все плохо, как тут большинство пытается доказать?
Угу. Посредственная операционка. С уродстким дизайном.
Лично мое мнение что все операционки семействи UNIX кривы изначально ибо ОСь в которой есть fork прямой быть не может просто по тому что поддержка fork'а искривляет вобще все что можно и что нельзя искривить.
Для тех кто уже заготовил помидоры: Попробуйте из процесса в котором крутятся 100 потоков и обрабатывают пару гигов данных запустить новый процес... О впечатлениях раскажите.
WH>>А может нужно просто менять город? Например на Москву? Если есть мозги то за вычетом квартиры и налогов 1000$-1500$ можно иметь белыми наруки. S>Уехать куда-либо вообще нет возможности, ибо в таком случае испортится карьера жены.
Это опять отмазка. Если бы ты был уверен что ты сможешь зарабатывать столько то вы с женой бы давно свалили. В крайнем случае свалили бы в две стадии сначалы ты. Потом когда ты устраиваешься то она.
Ибо в Москве тоже можно карьеру делать. И я болие уверен что по деньгам выдет гораздо лучше.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ибо в Москве тоже можно карьеру делать. И я болие уверен что по деньгам выдет гораздо лучше.
не у всех проблема не в том, что хочется много денег. их много не надо, надо столько чтоб о них не думать. но. сейчас это дело в россии доведено до абсурда и думать о чем-то другом, помимо денег, уже становится сложно. есть москва с ее ЗП, прелестями жизни, товарами на полках и прочее, как нечто отдельное и буквально все остальное, которое в Ж... имхо это не есть хорошо. не могут же все переселиться в москву, да? надуется и лопнет! так что... позиция москвичей в общем-то понятна... мол мы сильные, эдакая привелегированная каста. но. почему-то они не очень в курсе как живет остальной мир. а напрасно
зы. даешь социализьм?!
ззы. не пора бы народ начать раскулачивать?
Здравствуйте, _rasta, Вы писали:
_>не у всех проблема не в том, что хочется много денег. их много не надо, надо столько чтоб о них не думать.
Так я вобщемто не за деньгами в Москву переехал. А за интересной работой. Но как я говорил за интересную работу платят много...
А про деньги я начал по тому что Шеридан плачется что он очень бедный и не может купить винду.
К тому же есть выход заработать не переезжая в Москву... называется шаравара... вон посмотри на yxiie как на шараварках поднялся... но ведь работать нужно... и GPL'ный код использовать нельзя... и прочие стоны насчет свободного софта придется забыть...
_>зы. даешь социализьм?! _>ззы. не пора бы народ начать раскулачивать?
Ты эта... смотри... у меня BFG всегда на готове...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>не у всех проблема не в том, что хочется много денег. их много не надо, надо столько чтоб о них не думать. WH>Так я вобщемто не за деньгами в Москву переехал. А за интересной работой.
да, побродил я по уфе, есть пара контор, но... как-то там все кисло...
возмете меня к себе?
_>>зы. даешь социализьм?! _>>ззы. не пора бы народ начать раскулачивать? WH>Ты эта... смотри... у меня BFG всегда на готове...
Здравствуйте, WolfHound, Вы писали:
WH>Как все запущенно то...
Короче ясно. Ты с подобным не сталкивался. Проехали.
S>>Вот какраз щас начал углублять qt. WH>Не то углубляешь. Нужно углублять фундаментальные знания, а не какуюто там библиотчечку. WH>Библиотеки это фигня. Их многие тысячи. И углублять знания по каждой жизни не хватит. WH>Что касается тебя то судя по тому что ты пишешь знания у тебя очень поверхностные. WH>Короче бросай Qt и начинай изучать фундаментальные вещи.
Ты предлагаеш углубляться в библиотечку дотнет?
S>>С линухом уже практически на "ты", по крайней мере с gentoo. WH>Человек в общении с компьютером проходит 3 стадии:
Я начал с "да пошел ты..."
S>>И что, так ли все плохо, как тут большинство пытается доказать? WH>Угу. Посредственная операционка. С уродстким дизайном.
Все ясно. дотнет рулит, остальное дерьмо, незаслуживающее мозга.
WH>Для тех кто уже заготовил помидоры: Попробуйте из процесса в котором крутятся 100 потоков и обрабатывают пару гигов данных запустить новый процес... О впечатлениях раскажите.
эээ давай угадаю что так работает... Апач?
S>>Уехать куда-либо вообще нет возможности, ибо в таком случае испортится карьера жены. WH>Это опять отмазка. Если бы ты был уверен что ты сможешь зарабатывать столько то вы с женой бы давно свалили. В крайнем случае свалили бы в две стадии сначалы ты. Потом когда ты устраиваешься то она.
А ты не думаеш, что может быть ситуация, когда жене не хочется портить / терять карьеру. Заметь заранее, что мне действительно глубоко по фигу где и кем она работает. Лиш бы она хорошо себя чувствовала, и делала то, что ей нравится. А она не хочет работу терять. А теперь прикинь — в минеральных водах она у меня — помошник прокурора, кем она будет в маааскве?
WH>Ибо в Москве тоже можно карьеру делать. И я болие уверен что по деньгам выдет гораздо лучше.
Для меня москва это самый последний город куда я поеду. Ибо сумашедший дом. А если и искать работу в других городах то для меня список такой по степени так сказать желания в этом городе работать: МинВоды, Пятигорск, Ставрополь, Железноводск, Кисловодск, Ессентуки, Георгиевск, Краснодар, Ростов ..... СПБ, Москва.
Здравствуйте, WolfHound, Вы писали:
WH>Для тех кто уже заготовил помидоры: Попробуйте из процесса в котором крутятся 100 потоков и обрабатывают пару гигов данных запустить новый процес... О впечатлениях раскажите.
Можно просто не форкать "толстые" процессы.Например, держать специальный дочерний процесс для быстрого форканья. Или наоборот — есть некий супервизор, который запускает толстые дочерние рабочие процессы.
Здравствуйте, Sheridan, Вы писали:
WH>>Короче бросай Qt и начинай изучать фундаментальные вещи. S>Ты предлагаеш углубляться в библиотечку дотнет?
он тебе предлагает учить язык. и может быть даже языки...
S>>>С линухом уже практически на "ты", по крайней мере с gentoo. WH>>Человек в общении с компьютером проходит 3 стадии: S>Я начал с "да пошел ты..."
и поэтому из тебя не получилось программиста?
S>>>И что, так ли все плохо, как тут большинство пытается доказать? WH>>Угу. Посредственная операционка. С уродстким дизайном. S>Все ясно. дотнет рулит, остальное дерьмо, незаслуживающее мозга.
Здравствуйте, WolfHound, Вы писали:
WH>Для тех кто уже заготовил помидоры: Попробуйте из процесса в котором крутятся 100 потоков и обрабатывают пару гигов данных запустить новый процес... О впечатлениях раскажите.
для таких целей есть мозг, который переодически должен советовать не трогать большой и толстый процесс. ага?
WolfHound wrote: > S>И что, так ли все плохо, как тут большинство пытается доказать? > Угу. Посредственная операционка. С уродстким дизайном. > Лично мое мнение что все операционки семействи UNIX кривы изначально ибо > ОСь в которой есть fork прямой быть не может просто по тому что > поддержка fork'а искривляет вобще все что можно и что нельзя искривить. > Для тех кто уже заготовил помидоры: Попробуйте из процесса в котором > крутятся 100 потоков и обрабатывают пару гигов данных запустить новый > процес... О впечатлениях раскажите.
Fork — это другая идеология многопоточности. Например, берем Апач и
запускаем пул из 10 процессов. Если в одном из них у нас виснет
Perl'овый скрипт — прибиваем этот процесс и спокойно идем дальше. На
потоках такого не сделать толком.
Естественно, в обоих моделях есть свои паталогические крайние случаи.
Здравствуйте, Sheridan, Вы писали:
WH>>Как все запущенно то... S>Короче ясно. Ты с подобным не сталкивался. Проехали.
Ну печему же? Заходил я пару раз в такие конторки... посмотрел и уходил...
S>Ты предлагаеш углубляться в библиотечку дотнет?
Библиотеку нет. Там нет ничего выдающегося. А вот изучить как работают его механизмы JIT, GC... будет очень полезно. Например на RSDN есть статья про то как работает GC в .НЕТ.
S>Все ясно. дотнет рулит, остальное дерьмо, незаслуживающее мозга.
Что-то тебя на .НЕТ клинит... Да хорошая виртуальныя машина. Но можно было сделать и много лучше.
S>эээ давай угадаю что так работает... Апач?
Апач тормоз. Не выдерживающий нагрузку. Это факт медецинский и не раз проверенный. Его даже веб сервер написанный на ерланге (интерпитируемый язык работает гораздо медленней чем .НЕТ...) рвет как тузик грулку.
У нас вобще свой веб сервер который такой фигней не страдает.
S>А ты не думаеш, что может быть ситуация, когда жене не хочется портить / терять карьеру. Заметь заранее, что мне действительно глубоко по фигу где и кем она работает. Лиш бы она хорошо себя чувствовала, и делала то, что ей нравится. А она не хочет работу терять. А теперь прикинь — в минеральных водах она у меня — помошник прокурора, кем она будет в маааскве?
У... большой человек...
S>Для меня москва это самый последний город куда я поеду. Ибо сумашедший дом.
Кому как. S>А если и искать работу в других городах то для меня список такой по степени так сказать желания в этом городе работать: МинВоды, Пятигорск, Ставрополь, Железноводск, Кисловодск, Ессентуки, Георгиевск, Краснодар, Ростов ..... СПБ, Москва.
А как насчет того чтобы занятся скажем шароварой? Принципы не позволяют?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WHWH>Лично мое мнение что все операционки семействи UNIX кривы изначально ибо ОСь в которой есть fork прямой быть не может просто по тому что поддержка fork'а искривляет вобще все что можно и что нельзя искривить.
Windows также имеет аналог fork а — можно создать новый процесс на основе виртуального пространства родителя. Просто это не документировано и не афишируется. Cледуя Вашей логике кривизна windows имеет то т же порядок, что и unix
WH>Для тех кто уже заготовил помидоры: Попробуйте из процесса в котором крутятся 100 потоков и обрабатывают пару гигов данных запустить новый процес... О впечатлениях раскажите.
100 потоков, обрабатывающих данные — не лучшее решение, они погибнуть переключаясь и синхронизируясь
Здравствуйте, _rasta, Вы писали:
_>для таких целей есть мозг, который переодически должен советовать не трогать большой и толстый процесс. ага?
Он есть. Вот я их и не трогаю. Но это не отменяет кривизны архитектуры. Даже сама идея форка противоестественна.
Я вобще не понимаю что дает форк.
За то сколько проблем он создает...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Fork — это другая идеология многопоточности. Например, берем Апач и запускаем пул из 10 процессов. Если в одном из них у нас виснет Perl'овый скрипт — прибиваем этот процесс и спокойно идем дальше. На потоках такого не сделать толком.
А зачем для этого форк? Чем тебя CreateProcess не устраивает?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WFrag, Вы писали:
WF>Можно просто не форкать "толстые" процессы.Например, держать специальный дочерний процесс для быстрого форканья. Или наоборот — есть некий супервизор, который запускает толстые дочерние рабочие процессы.
Я рассматривал эти костыли но пришол к выводу что слишком много гемороя. Да и как это отменяет кривь форка?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, TarasCo, Вы писали:
TC>Windows также имеет аналог fork а — можно создать новый процесс на основе виртуального пространства родителя.
Ссылку почитать дай. TC>Просто это не документировано и не афишируется. Cледуя Вашей логике кривизна windows имеет то т же порядок, что и unix
Иметь возможность использовать аналог форка. И быть обязанным использовать форк всегда когда хочешь создать новый процесс это несколько разные вещи не находишь?
TC>100 потоков, обрабатывающих данные — не лучшее решение, они погибнуть переключаясь и синхронизируясь
Не забывай про то что еще есть ввод-вывод, а он на современных архитектурах ооочень не быстрый.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, TarasCo, Вы писали:
TC>>Windows также имеет аналог fork а — можно создать новый процесс на основе виртуального пространства родителя. WH>Ссылку почитать дай.
NTSTATUS
PspCreateProcess(
OUT PHANDLE ProcessHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL,
IN HANDLE ParentProcess OPTIONAL,
IN BOOLEAN InheritObjectTable,
IN HANDLE SectionHandle OPTIONAL,
IN HANDLE DebugPort OPTIONAL,
IN HANDLE ExceptionPort OPTIONAL
)
/*++
Routine Description:
This routine creates and initializes a process object. It implements the
foundation for NtCreateProcess and for system initialization process
creation.
Arguments:
ProcessHandle - Returns the handle for the new process.
DesiredAccess - Supplies the desired access modes to the new process.
ObjectAttributes - Supplies the object attributes of the new process.
ParentProcess - Supplies a handle to the process' parent process. If this
parameter is not specified, then the process has no parent
and is created using the system address space.
SectionHandle - Supplies a handle to a section object to be used to create
the process' address space. If this parameter is not
specified, then the address space is simply a clone of the
parent process' address space.
DebugPort - Supplies a handle to a port object that will be used as the
process' debug port.
ExceptionPort - Supplies a handle to a port object that will be used as the
process' exception port.
TC>>100 потоков, обрабатывающих данные — не лучшее решение, они погибнуть переключаясь и синхронизируясь WH>Не забывай про то что еще есть ввод-вывод, а он на современных архитектурах ооочень не быстрый.
1 поток обработает ввод/вывод быстрее, чем 100. Я еще забыл написать что 100 поток при сборке программы по умолчанию израсходуют 100М виртуальной памяти, которая будет потом свопиться очень активно .
Здравствуйте, WolfHound, Вы писали: S>>А если и искать работу в других городах то для меня список такой по степени так сказать желания в этом городе работать: МинВоды, Пятигорск, Ставрополь, Железноводск, Кисловодск, Ессентуки, Георгиевск, Краснодар, Ростов ..... СПБ, Москва. WH>А как насчет того чтобы занятся скажем шароварой? Принципы не позволяют?
Как же можно требовать деньги за программы ? Вдруг он вырастет во что-то напоминающее Microsoft ?
Здравствуйте, WolfHound, Вы писали:
WH>Я рассматривал эти костыли но пришол к выводу что слишком много гемороя.
Ну, если это слишком много геморроя, то я вообще не понимаю, как получилось создать такую толстую систему Ни одно техническое решение не заменит мозг архитектора. А уж когда вопрос идет о масштабируемости решения, то тем более нужно грамотное проектирование с учетом разных технических ограничений.
WH>Да и как это отменяет кривь форка?
Неверная предпосылка. Форк не крив. Он такой, какой он есть, у такой архитектуры есть и плюсы, и минусы. Почему-то другим это не мешает создавать большие и толстые системы, работающие с большими объемами данных.
Здравствуйте, _rasta, Вы писали:
_>это твое мнение как тестера со стажем, или как программиста, завалившего пачку проектов?
Видимо это и есть, так называемый "переход на личности"?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, TarasCo, Вы писали:
TC>1 поток обработает ввод/вывод быстрее, чем 100.
Это смотря какой ввод вывод... Нпример если запрос ушол в сеть то пока придет ответ поток можно спокойно приглушить.
Болие того например файловым системам с журнальной структурой гораздо выгоднее если придет сразу много запросов ибо в этом случае можно гораздо лучше спланировать перемещение головок винта.
Да и вобще почитай Танебаума чтоли...
Кстати посмотри на ерланг... там процессы плодятся десятками тысяч...
TC>Я еще забыл написать что 100 поток при сборке программы по умолчанию израсходуют 100М виртуальной памяти, которая будет потом свопиться очень активно .
У меня 8 гигов. Да и вобще если будет возможность разогнать систему то поставят любое железо. Еесно если обосновать что это железо даст соответсвующей своей цене прирост производительности.
Еще вопросы?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ну печему же? Заходил я пару раз в такие конторки... посмотрел и уходил...
Хорошо, когда есть возможность...
S>>Ты предлагаеш углубляться в библиотечку дотнет? WH>Библиотеку нет. Там нет ничего выдающегося. А вот изучить как работают его механизмы JIT, GC... будет очень полезно. Например на RSDN есть статья про то как работает GC в .НЕТ.
с++ имхо всетаки побыстрее будет, пусть даже и с qt...
S>>Все ясно. дотнет рулит, остальное дерьмо, незаслуживающее мозга. WH>Что-то тебя на .НЕТ клинит... Да хорошая виртуальныя машина. Но можно было сделать и много лучше.
Вот именно.
Что непохая это штука — я согласен.
S>>эээ давай угадаю что так работает... Апач? WH>Апач тормоз. Не выдерживающий нагрузку. Это факт медецинский и не раз проверенный. Его даже веб сервер написанный на ерланге (интерпитируемый язык работает гораздо медленней чем .НЕТ...) рвет как тузик грулку.
Странные у вас апачи... о_0
WH>У нас вобще свой веб сервер который такой фигней не страдает.
Дык ясное дело, сервак, написаный под определенную задачу будет лучше работать чем нечто такоеже, но универсальное...
WH>А как насчет того чтобы занятся скажем шароварой? Принципы не позволяют?
Не потяну. Ибо требуют быстро, а сам понимаеш, за пару часов в день, которые я могу выделить, ни в какой проект не уложишся.
Здравствуйте, WolfHound, Вы писали:
WH>Он есть. Вот я их и не трогаю. Но это не отменяет кривизны архитектуры. Даже сама идея форка противоестественна. WH>Я вобще не понимаю что дает форк. WH>За то сколько проблем он создает...
Здравствуйте, Erop, Вы писали:
_>>это твое мнение как тестера со стажем, или как программиста, завалившего пачку проектов? E>Видимо это и есть, так называемый "переход на личности"?
ну как тебе сказать... я не против конструктивной критики, но... ни разу от шеридана ее не видел. в такие моменты ничего другого не остается
Здравствуйте, WolfHound, Вы писали:
WH>Он есть. Вот я их и не трогаю. Но это не отменяет кривизны архитектуры.
Если Вы не поняли архитектуру, это не значит, что она кривая.
WH>Даже сама идея форка противоестественна.
Расскажите это Томпсону и Ричти
WH>Я вобще не понимаю что дает форк.
Например, позволяет:
* передавать дочернему процессу большие массивы данных, не используя дополнительную память.
* переопределить stdin/stdout/stderr простым способом, а не как в CreateProcess()
* знать pid программы до ее запуска
* иметь два или более процесса в одном бинарике
и многое другое.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Здравствуйте, WolfHound, Вы писали:
WH>Кстати посмотри на ерланг... там процессы плодятся десятками тысяч...
Ага. Потому что они как правило легковесные, а не мегатонные монстры. Как раз с тонной легких процессов у линуксового форка все хорошо, гораздо лучше, чем у виндового CreateProcess. Хорошо заметно на всяких configure, которые плодят много процессов.
Здравствуйте, WFrag, Вы писали:
WF>Ну, если это слишком много геморроя, то я вообще не понимаю, как получилось создать такую толстую систему
Не понял. WF>Ни одно техническое решение не заменит мозг архитектора.
Ессно. Просто я старт процессов рассматривал как одно из решений но пришол к выводу что оно не жизнеспособно. WF>А уж когда вопрос идет о масштабируемости решения, то тем более нужно грамотное проектирование с учетом разных технических ограничений.
Ты кому это расказываешь? У меня кластер масштибируется линейно.
WF>Неверная предпосылка. Форк не крив. Он такой, какой он есть, у такой архитектуры есть и плюсы, и минусы.
Назови хоть один плюс. Только сначала подумай как это можно сделать без форка.
WF>Почему-то другим это не мешает создавать большие и толстые системы, работающие с большими объемами данных.
Оно не помогает. А обойти можно практически любую кривь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Апач тормоз. Не выдерживающий нагрузку. Это факт медецинский и не раз проверенный. Его даже веб сервер написанный на ерланге (интерпитируемый язык работает гораздо медленней чем .НЕТ...) рвет как тузик грулку.
Во-первых, не совсем интерпретируемый, вернее, совсем не интерпретируемый. Подозреваю, что HiPE там таки работал. А во-вторых, нагрузка — она разная бывает. Этот тест сравнивает масштабируемость в довольно-таки патологическом случае. Я более чем уверен, что если взять пользователей в 100 раз меньше, а объем запрашиваемой статики в 100 раз больше, то Apache порвет Yaws, как тузик грелку. Просто потому что Apache может использовать sendfile, а Yaws — нет.
Здравствуйте, ДимДимыч, Вы писали:
ДД>Если Вы не поняли архитектуру, это не значит, что она кривая.
Ну так объясни.
ДД>Расскажите это Томпсону и Ричти
Давить авторитетами бесполезно. Факты давай... факты!
ДД>Например, позволяет: ДД>* передавать дочернему процессу большие массивы данных, не используя дополнительную память.
Для этого форк не нужен.
В разных архитектурах используются разные приемы в винде шарят страници памяти между процессами, а в сингулярити есть exchange heap через которую можно передовать данные любого размера без копирования. ДД>* переопределить stdin/stdout/stderr простым способом, а не как в CreateProcess()
Уж лучше так чем тот ворох проблем который создает форк. ДД>* знать pid программы до ее запуска
Зачем? Болие того пути шедуллера не исповедимы. ДД>* иметь два или более процесса в одном бинарике
Не понял. Надеюсь ты не про совместное использование кода процессами. Так для этого тоже форк не нужен. ДД>и многое другое.
Что именно?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WF>>Ну, если это слишком много геморроя, то я вообще не понимаю, как получилось создать такую толстую систему
WH>Не понял.
Я к тому, что описанные решения имплементируются в течение пары дней. Конечно, я не знаю всей специфики задачи, но, в общем-то, ничего сверхсложного не вижу.
Здравствуйте, Sheridan, Вы писали:
WH>>Библиотеку нет. Там нет ничего выдающегося. А вот изучить как работают его механизмы JIT, GC... будет очень полезно. Например на RSDN есть статья про то как работает GC в .НЕТ. S>с++ имхо всетаки побыстрее будет, пусть даже и с qt...
Очень сильно зависит от задачи... Ты же не знаешь как .НЕТ работает по этому и не можешь говорить для чего он лучше С++, а для чего хуже.
WH>>Что-то тебя на .НЕТ клинит... Да хорошая виртуальныя машина. Но можно было сделать и много лучше. S>Вот именно.
Что именно? Я вот знаю что там можно сделать лучше. А ты знаешь? Ах да ты же и саму систему не знаешь по тому и не сможешь ответить на этот вопрос.
WH>>Апач тормоз. Не выдерживающий нагрузку. Это факт медецинский и не раз проверенный. Его даже веб сервер написанный на ерланге (интерпитируемый язык работает гораздо медленней чем .НЕТ...) рвет как тузик грулку. S>Странные у вас апачи... о_0
Это не у нас апачи странные. Это у вас нагрузки нет.
По сравнению с тем порталом который я сейчас курочу на RSDN вобще никто не ходит...
S>Дык ясное дело, сервак, написаный под определенную задачу будет лучше работать чем нечто такоеже, но универсальное...
Он уневерсальный. Может все что может апач... только тормозить не умеет...
S>Не потяну. Ибо требуют быстро, а сам понимаеш, за пару часов в день, которые я могу выделить, ни в какой проект не уложишся.
Отмазка. Быо-бы жилание...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sheridan, Вы писали:
S>форк, форк... а почему не pthread?
И как мне при помощи pthread сделать изолированное адрессное пространство?
А так да... только pthread'ом и спасаемся.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, TarasCo, Вы писали:
TC>>1 поток обработает ввод/вывод быстрее, чем 100. WH>Это смотря какой ввод вывод... Нпример если запрос ушол в сеть то пока придет ответ поток можно спокойно приглушить.
вместо того, чтобы из этого же потока отслать другой запрос или обслужить пришедший запрос от другого клиента, предлагается просто переключить контекст процессора и добавить системе дополнительную радость попланировать задачи .
WH>Болие того например файловым системам с журнальной структурой гораздо выгоднее если придет сразу много запросов ибо в этом случае можно гораздо лучше спланировать перемещение головок винта. WH>Да и вобще почитай Танебаума чтоли...
Дык и Вам не мешало бы. Про асинхронные операции разузнать например. А то познание остановилось на уровне "один клиент — один поток". В таком виде — хоть 100 потоков, хоть 1000 — они не смогут нагрузить железо. Вместо того, чтобы заниматься полезным делом они будут перепланироваться, свопиться на диск, потом обратно и.т.п. Все высокопроизводительные системы основаны на использовании небольшого пула потоков, каждый в асинхронном режиме обслуживает множество клиентов. Тут не причем ОС — это единственная нормальная схема. Внутри каждого такого потока можно реализовать волокна, исполнять контроллируемый код — что угодно творить.
TC>>Я еще забыл написать что 100 поток при сборке программы по умолчанию израсходуют 100М виртуальной памяти, которая будет потом свопиться очень активно . WH>У меня 8 гигов. Да и вобще если будет возможность разогнать систему то поставят любое железо. Еесно если обосновать что это железо даст соответсвующей своей цене прирост производительности. WH>Еще вопросы?
И что Вы этм хотите сказать? У меня на 4 процессорной машине с 8ГБ памяти приложение работает быстрее, чем у соседа на РIII? Довольно странный аргумент в пользу Windows — было бы логичнее отстаивать позицию, что WIndows не так уж прожолива на ресурсы, как любят расказывать юниксоиды.
Здравствуйте, WFrag, Вы писали:
WF>Я к тому, что описанные решения имплементируются в течение пары дней. Конечно, я не знаю всей специфики задачи, но, в общем-то, ничего сверхсложного не вижу.
А ничего очень сложного и нет. Просто куча скользких мест. Плюс поддержка... через год... когда все все забудут...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Fork — это другая идеология многопоточности. Например, берем Апач и > запускаем пул из 10 процессов. Если в одном из них у нас виснет > Perl'овый скрипт — прибиваем этот процесс и спокойно идем дальше. На > потоках такого не сделать толком. > А зачем для этого форк? Чем тебя CreateProcess не устраивает?
Если действовать по классике — то нужно вызывать CP с наследованием
хэндлов, а потом передать дочернему процессу номера открытых хэндлов.
Если не хочется делать два exe-файла, то еще нужно специальным ключом
командной строки указывать, что запускаемся как ребенок. И т.п.
В общем, будем иметь "форк, вид сбоку". Я так уже делал в одном
приложении, когда нужно было обеспечить изоляцию для очень глючного
стороннего компонента.
WolfHound wrote: > Иметь возможность использовать аналог форка. И быть обязанным > использовать форк всегда когда хочешь создать новый процесс это > несколько разные вещи не находишь?
Есть еще vfork
Здравствуйте, TarasCo, Вы писали:
TC>вместо того, чтобы из этого же потока отслать другой запрос или обслужить пришедший запрос от другого клиента, предлагается просто переключить контекст процессора и добавить системе дополнительную радость попланировать задачи .
Для того чтобы отправить запрос в сеть нужно добратся до драйвера работающего в ядре те переключить контекст. Вне зависимости от того синхронная посылка или нет.
А если мы всравно в ядре то щелкнуть шедуллером не представляет проблем.
Болие того в случае с асинхронной посылкой нам придется либо скопировать весь буфер либо использовать какието методы оповещения процесса о том что сообщение отослано.
TC>Дык и Вам не мешало бы. Про асинхронные операции разузнать например.
Вот и почитай что оно про них пишет... Если мне не изменяет скалероз у него прямым текстом говорится что блокирующие вызовы лучше. Причем приводится масса аргументов в том числе см выше.
TC>А то познание остановилось на уровне "один клиент — один поток".
У тебя?
TC>В таком виде — хоть 100 потоков, хоть 1000 — они не смогут нагрузить железо. TC>Вместо того, чтобы заниматься полезным делом они будут перепланироваться,
По прерыванию те переходу в режим ядра.
Просто так потоки никто не дергает. Если потоку выделили квант то он этот квант и отработает. Елси конечно не выполнит блокирующий вызов ядра. Да и на не блокирующем шедуллеру никто не мешает переключить поток например если квант времени почти вышел.
TC>свопиться на диск, потом обратно и.т.п.
Зачем им свопится на диск? Ведь памяти до чертиков. Тем болие что стек в большинстве случаев только адресное пространство ест, а не память.
TC>Все высокопроизводительные системы основаны на использовании небольшого пула потоков, каждый в асинхронном режиме обслуживает множество клиентов.
Это ты из своего опыта или из источника ОБС?
Ессно используется пул потоков ибо создание потока операция не дешовая. Вот только пул может быть весьма разного размера.
И регулируется этот пул исходя из весьма других соображений... например сколько запросов одновременно железо может вобще обработать... остальные ставятся в очередь.
TC>Тут не причем ОС — это единственная нормальная схема.
Ну как не причем... если сделать ось в которой будет работать только управляемый код (не считая часи ядра) то можно хоть процесс на запрос... Болие того если делать так то для некоторых запросов можно вобще отключать ГЦ сводя выделение памяти к тривиальному.
TC>Внутри каждого такого потока можно реализовать волокна, исполнять контроллируемый код — что угодно творить.
Те делать то что делает ядро... шедулить потоки.... ловить сигналы...
Я конечно понимаю что есть некоторый класс задач накотором волокна могут поднять производительность тапа скриптов в играх или просто нужно перед обменом сообщений выполнить очень малый объем работы но лично у меня таких задач в данный момент нет.
TC>И что Вы этм хотите сказать? У меня на 4 процессорной машине с 8ГБ памяти приложение работает быстрее, чем у соседа на РIII? Довольно странный аргумент в пользу Windows — было бы логичнее отстаивать позицию, что WIndows не так уж прожолива на ресурсы, как любят расказывать юниксоиды.
А где я отстаиваю позиции винды? Я про кривь никсов говорю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Для того чтобы отправить запрос в сеть нужно добратся до драйвера работающего в ядре те переключить контекст. Вне зависимости от того синхронная посылка или нет.
Это разные вещи и скорость пееключения в ядро и обратно на порядок выше чем переключение между задачами.
WH>Болие того в случае с асинхронной посылкой нам придется либо скопировать весь буфер либо использовать какието методы оповещения процесса о том что сообщение отослано.
Асинхронные методы все естсественным образом включают в себя механизм оповещения. Более того, с точки зрения ядра все операции — асинхронные, просто для некоторых приходиться эмулировать синхронность выполнения ( либо они действительно синхронно могут быть выполнены — т.е без ожидания ).
TC>>Дык и Вам не мешало бы. Про асинхронные операции разузнать например. WH>Вот и почитай что оно про них пишет... Если мне не изменяет скалероз у него прямым текстом говорится что блокирующие вызовы лучше. Причем приводится масса аргументов в том числе см выше.
Можете мне привести хоть из Евангилия цитаты. Асинхронный режим потенциально лучше, по крайней мере IIS работает с сетью именно так. А мы же защищаем Windows вроде?
WH>Просто так потоки никто не дергает. Если потоку выделили квант то он этот квант и отработает. Если конечно не выполнит блокирующий вызов ядра. Тык если поток обсдуживает устройство ввода/вывода в блокирующем режиме он так и будет делать — не успел получить управление — бац WriteFile — переаланировка, следующий — количеситво переключений будет возратстать.
WH>Да и на не блокирующем шедуллеру никто не мешает переключить поток например если квант времени почти вышел.
Этого быть не может — перепланировка случается или по таймеру, или если поток добровольно переведет себя в режим ожидания.
TC>>свопиться на диск, потом обратно и.т.п. WH>Зачем им свопится на диск? Ведь памяти до чертиков. Тем болие что стек в большинстве случаев только адресное пространство ест, а не память.
Ну кончено....
TC>>Все высокопроизводительные системы основаны на использовании небольшого пула потоков, каждый в асинхронном режиме обслуживает множество клиентов. WH>Это ты из своего опыта или из источника ОБС? WH>Ессно используется пул потоков ибо создание потока операция не дешовая. Вот только пул может быть весьма разного размера. WH>И регулируется этот пул исходя из весьма других соображений... например сколько запросов одновременно железо может вобще обработать... остальные ставятся в очередь.
Регулировать этот пул весьма просто — сколько процессоров в системе, столько и потоков.
TC>>Тут не причем ОС — это единственная нормальная схема. WH>Ну как не причем... если сделать ось в которой будет работать только управляемый код (не считая часи ядра) то можно хоть процесс на запрос... Болие того если делать так то для некоторых запросов можно вобще отключать ГЦ сводя выделение памяти к тривиальному.
Я согласен, но в этом случае смысл процесса — совсем другой. IMHO сравнивать системы с вытесняющей многозадачностью и изолированными процессами не
корректно.
WH>А где я отстаиваю позиции винды? Я про кривь никсов говорю.
Я знаю одну некривую ось — MS DOS, там негде кривизне проявиться .
WolfHound wrote: > А если мы всравно в ядре то щелкнуть шедуллером не представляет проблем. > Болие того в случае с асинхронной посылкой нам придется либо скопировать > весь буфер либо использовать какието методы оповещения процесса о том > что сообщение отослано.
Вообще-то, при синхронной посылке буфферы тоже копируются в ядерное
пространство (в Windows и Linux). В BSD есть zero-copy sockets, но они
часто не очень эффективны, недавно в Линукс добвили функцию splice,
которая позволяет вручную сплайсить буфферы в ядерное пространство (так
что действительно будет ZC), но это требует явного приложения рук.
Здравствуйте, TarasCo, Вы писали:
TC>1 поток обработает ввод/вывод быстрее, чем 100. Я еще забыл написать что 100 поток при сборке программы по умолчанию израсходуют 100М виртуальной памяти, которая будет потом свопиться очень активно.
Ну разве можно после этого представить себе систему лучше линуха?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, TarasCo, Вы писали:
TC>1 поток обработает ввод/вывод быстрее, чем 100. Я еще забыл написать что 100 поток при сборке программы по умолчанию израсходуют 100М виртуальной памяти, которая будет потом свопиться очень активно :).
С какой стати? 1M — это ж reserve size, не commit size. Committed будут дай бог с десяток страниц из каждого потока.
Здравствуйте, TarasCo, Вы писали:
TC>Это разные вещи и скорость пееключения в ядро и обратно на порядок выше чем переключение между задачами.
В одном процессе? С чего бы?
TC>Асинхронные методы все естсественным образом включают в себя механизм оповещения.
Ессно включают. Но за ними всеравно нужен глаз да глаз...
Если в линуксе сказать MSG_DONTWAIT то по окончании будет вызвана определенная процедурка.
Те переключение контекста всеравно произойдет.
Болие того если вызов этой процедурки произойдет в другом потоке (используются всплывающие потоки) то и переключение потока тоже произойдет...
В прочем в любом случае придется регистры на стек сохранять.
TC>Более того, с точки зрения ядра все операции — асинхронные,
Вот пусть ядро всем этим и занимается. TC>просто для некоторых приходиться эмулировать синхронность выполнения ( либо они действительно синхронно могут быть выполнены — т.е без ожидания ).
Так ее в любом случае придется эмулировать не в ядре так у себя.
TC>Можете мне привести хоть из Евангилия цитаты.
Книжка дома. TC>Асинхронный режим потенциально лучше, по крайней мере IIS работает с сетью именно так.
В винде нужно проверять не закончилась ли посылка... Или можно подождать пока она закончится... заблокировав поток...
TC>А мы же защищаем Windows вроде?
Кто? Где? Не вижу.
TC>Тык если поток обсдуживает устройство ввода/вывода в блокирующем режиме он так и будет делать — не успел получить управление — бац WriteFile — переаланировка, следующий — количеситво переключений будет возратстать.
С асинхронной записью в файл таже фигня...
TC>Этого быть не может — перепланировка случается или по таймеру, или если поток добровольно переведет себя в режим ожидания.
Голову на отсечение даешь? Степень извращения планировщика зависиь исключительно от того кто и зачем этот планировщик пишет.
TC>Регулировать этот пул весьма просто — сколько процессоров в системе, столько и потоков.
Ржу как лошадь.
TC>Я согласен, но в этом случае смысл процесса — совсем другой. IMHO сравнивать системы с вытесняющей многозадачностью и изолированными процессами не корректно.
Так:
1)Процессы по любому изолированны. Вопрос лишь в том какими методами.
2)Метод изоляции процессов (программный или аппаратный) к вытесняющей многозадачности отношения не имеет.
Сравнивать управляемые и не управляемые ОС не только можно но и нужно ибо они решают одни и теже задачи.
Далие насчет синхронности и асинхронности.
Что использовать зависит от того как устроена операционка. Так вот в классические ОС очень часто разумнее использовать синхронную запись ибо с ней гемора меньше.
А в болие модерновых ОС например сингулярити синхронная запись вобще не доступна. Но там асинхронная работа сделана без жуткого гемороя ибо с каналами работать очень легко.
ЗЫ Кстати как ты относишся к процедуре sendfile в линухе?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, _rasta, Вы писали:
_>Здравствуйте, Erop, Вы писали:
_>>>это твое мнение как тестера со стажем, или как программиста, завалившего пачку проектов? E>>Видимо это и есть, так называемый "переход на личности"?
_>ну как тебе сказать... я не против конструктивной критики, но... ни разу от шеридана ее не видел. в такие моменты ничего другого не остается
_>+ он просил его (лично) переубедить...
Да нету у меня ни стажа, я не программер, я не тестер, я вообще уже не знаю кто. Мальчишка на побегушках. Держит только зарплата, которая одна из самых высоких в регионе. Да и коллектив хороший.
В последний раз когда писал софтину для облегчения своей работы, мне мой нач сказал — "нах оно тебе нужно? не занимайся хней". Больше я программированием тут заниматься не буду, желания воообще нету чтото сюда писать.
Дайте мне тз, дайте время (а заваленые проекты это я думаеш только программированием занимался? Прграммированием я от силы гдето на 50% занимался, есть и другие обязанности, в том числе и техподдержка была и тогда), и я напишу. Мелкого то софта я нарисовал тут достаточно. А заваленые проекты были уровня rsdn@home, которые я тянул один.
[RSDN@Home][1.2.0][alpha][668]
[Все мужчины одинаковы перед женщиной, которой они восхищаются. [Б. Шоу]]
Здравствуйте, Alex Fedotov, Вы писали:
AF>С какой стати? 1M — это ж reserve size, не commit size. Committed будут дай бог с десяток страниц из каждого потока.
С этим согласен . Правда страницы по факту коммититься по 64К, т.е их будет не меньше 16 + 3 страницы ядерного стека, который при ожидании юзеровский операций также свопиться. Да к тому же среднее виндовое приложения полюбасу более 64К использует . У меня есть другой аргумент — активное переключение задач будет приводить к постоянному вытеснению стека из кеша процессора, что также при активном использовании стека не есть гуд. .
TC>>Этого быть не может — перепланировка случается или по таймеру, или если поток добровольно переведет себя в режим ожидания. WH>Голову на отсечение даешь? Степень извращения планировщика зависиь исключительно от того кто и зачем этот планировщик пишет.
Да. Планировшик работает по следующим событиям:
1. Прерывания таймера, допустим раз в 10мс
2. Перевод потока в режим ожидания
3. Установка объект синхронизации в сигнализированное состояние, если этот объект ждет поток с более высоким приоритетом.
TC>>Регулировать этот пул весьма просто — сколько процессоров в системе, столько и потоков. WH>Ржу как лошадь.
закончим беседу?
WH>Сравнивать управляемые и не управляемые ОС не только можно но и нужно ибо они решают одни и теже задачи.
Но не так. Допустим я сделаю систему с управляемым кодом, где process — это метод объектов и буду в цикле вызывать process у некоторой коллекции объектов. И скажу: "у меня переключение между процессами занимает 10 инструкций машинного кода". Ну-ка, давайте сравним с Windows и с Unix????
В этом случае сравнение не уместно. Сравнивать можно по объективным показателям производительности — скорость ввода/вывода, обработка больших объемов данных и.т.п. Асинхронные операции делают алгоритм
WH>Далие насчет синхронности и асинхронности. WH>Что использовать зависит от того как устроена операционка. Так вот в классические ОС очень часто разумнее использовать синхронную запись ибо с ней гемора меньше.
Я с этим не спорю. Если есть задача написать серевре которые обслуживает 10000 запросов в час при равномерной интенсивности — тут и думать нечего — однопоточный сервер с блокирующими сокетами.
WH>А в болие модерновых ОС например сингулярити синхронная запись вобще не доступна. Но там асинхронная работа сделана без жуткого гемороя ибо с каналами работать очень легко.
Опять Вы про геморрой, надо же разделять понятия — сложность разработки и производительность решения. Если говорить про Windows, глупо пытаться залепить IOCP в каждую дыру. Но говорить, что блокирующие операции по определению лучше также довольно странно.
WH>ЗЫ Кстати как ты относишся к процедуре sendfile в линухе?
никак, яш пробитый виндуозник
Здравствуйте, WolfHound, Вы писали:
ДД>>Если Вы не поняли архитектуру, это не значит, что она кривая. WH>Ну так объясни.
К сожалению, не обладаю педагогическим даром Если интересно — советую обратиться к соответствующей литературе.
WH>Давить авторитетами бесполезно. Факты давай... факты!
Факты:
ДД>>* передавать дочернему процессу большие массивы данных, не используя дополнительную память. WH>Для этого форк не нужен. WH>В разных архитектурах используются разные приемы в винде шарят страници памяти между процессами, а в сингулярити есть exchange heap через которую можно передовать данные любого размера без копирования.
Да, shared memory тоже можно использовать. Но если нужно от родителя передать данные ребенку единожды, а тем более, если нужно чтобы модификация этих данных не была видима второму процессу, то проще (и эффективнее) ничего кроме fork() нету.
ДД>>* переопределить stdin/stdout/stderr простым способом, а не как в CreateProcess() WH>Уж лучше так чем тот ворох проблем который создает форк.
Если у Вас fork() создает ворох проблем, то это Ваши проблемы, а не fork'а.
ДД>>* знать pid программы до ее запуска WH>Зачем?
Например, диспетчер должен запустить процесс так, чтобы его stdout был записан в файл, имя которого содержит pid.
WH>Болие того пути шедуллера не исповедимы.
В смысле?
ДД>>* иметь два или более процесса в одном бинарике WH>Не понял. Надеюсь ты не про совместное использование кода процессами. Так для этого тоже форк не нужен.
Реализовывал я как-то моделирование физического процесса. Ход процесса нужно было отображать в реальном времени, поэтому каждая итерация пересчета синхронизировалась с временем. Но потом оказалось, что в определенной ситуации необходимо "заглянуть в будущее" и узнать результат до того, как рендерер его отобразит. fork(), в дочернем процессе синхронизация пропускается, получаем результат "наперед" без существенной модификации кода.
Или, например, сервер должен каждому клиенту предоставить отдельное адресное пространство. Каждый раз запускать отдельный бинарик, передавая ему необходимые параметры?
ДД>>и многое другое. WH>Что именно?
Сколько на данный момент параметров у CreateProcess()? 10, в том числе указатель на структуру из 14 используемых записей. А если нужно ввести еще один параметр — создавать CreateProcessEx()? А еще один — CreateProcessExAdv()? С fork() проще, т.к. ничего выдумывать не надо.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, WolfHound, Вы писали:
WH>>Ну печему же? Заходил я пару раз в такие конторки... посмотрел и уходил... S>Хорошо, когда есть возможность...
"кто хочет, ищет возможности, кто не хочет — ищет отмазки". (с) не помню хто.
S>>>Ты предлагаеш углубляться в библиотечку дотнет? WH>>Библиотеку нет. Там нет ничего выдающегося. А вот изучить как работают его механизмы JIT, GC... будет очень полезно. Например на RSDN есть статья про то как работает GC в .НЕТ. S>с++ имхо всетаки побыстрее будет, пусть даже и с qt...
1) в процессе реального девелопмента. важна и скорость разработки
потери в производительности системы — довольны ничтожны
на современных серверах разницы особой нет, работает какая-нибудь enterprise-система на джаве, дотнете или плюсах.
кроме там каких-то особых случаев, где там нужен уж суперпефоманс.
НЕТ РАЗНИЦЫ!!!
2) есть вещи. которые не зависят ни от винды и линукса. ни от конкретного языка программирования, к примеру: database design, OOAD и тд и тп.
почему-то в этом ты не углубляешь знания?
команды языка — ну. это может максимум процентов 30 от того ,что надо
есть гораздо более фундаментальные вещи и они никак не связаны с плюсами, джавами и дотнетом
если ты их понимаешь и применяешь в дотнете, без особых трудностей сможешь применять в джаве и плюсах...
верное и обратное.
вот на чем надо аккцентрировать внимание.
S>>>Все ясно. дотнет рулит, остальное дерьмо, незаслуживающее мозга. WH>>Что-то тебя на .НЕТ клинит... Да хорошая виртуальныя машина. Но можно было сделать и много лучше. S>Вот именно. S>Что непохая это штука — я согласен.
ох#$%ная просто штука, как впрочем и джава не менее ох@#$нная платформа.
обе платформы позволяют делать с высокой скоростью серьезные enterprise-системы, причем, количество человеко-часов гораздо ниже, чем в случае с плюсами и квалификация девелоперов нужна не столь высокая. как в случае плюсов(бюджет проекта нужен меньший — еще один плюс в конкуретной борьбе за заказчика)
а в современной мире жёсткочайшей конкуренции среди аутсорсеров — сроки разработки также играют одну из ключевых ролей в борьбе за заказчика.
а не совсем высокий требуемый уровень разработчиков что на джаве что на дотнете компенсируется наличием фреймворка, которые позволяет предотвратить кучу потенциальных ошибок девелопера и существенно смягчить уже возникшие...
так что, у С++ в этом плане, сильно снизилась ниша
поэтому. и коллосальный спрос на джавистов и дотнетичков и гораздо меньший на плюсовиков.
3) Джава и дотнет позволяют сущетсвенно облегчить ряд достаточно рутинных операций, над которыми в плюсах надо было тратить время. Это — тоже серьезный фактор, так как высвобождается время. которое можно потратить на улучшение бизнес-логики приложения, либо его архитектуры,
так что, Шеридан, тогда и только тогда, когда начнешь заниматься реальными девелопментом, с жёсткими временными рамками, ты оценишь прелесть и джавы и дотнета, и с любимими многими плюсами (и я тоже люблю плюсы и многие мои знакомые тоже ) придется расстаться.потому есть суровая правда жизни,а есть теоретические измышления...
WH>>А как насчет того чтобы занятся скажем шароварой? Принципы не позволяют? S>Не потяну. Ибо требуют быстро, а сам понимаеш, за пару часов в день, которые я могу выделить, ни в какой проект не уложишся.
левый прогон
если ты нормальный девелопер, ты можешь фрилансером быть и забить большую и толстую пиписку на свою текущую работу.
у меня есть несколько знакомых фрилансеров в Харькове. меньше штуки редко когда в месяц имеют.
шароварщики есть знакомые тоже....
ну у них не такой стабильный доход. Иногда и несколько штук в месяц, а иногда и с трудом пару сотен наскребают.
фриланс более стабильный доход и достаточно хорошо оплачиваемый...
вобщем. "кто хочет, ищет возможности, кто не хочет — ищет отмазки". (с) не помню хто.
так что ....
хватит тут гененировать кучу отмазок и давай занимайся реальными проектами и реальными фундаментальными знаниями.
S>>>эээ давай угадаю что так работает... Апач? WH>>Апач тормоз. Не выдерживающий нагрузку. Это факт медецинский и не раз проверенный. Его даже веб сервер написанный на ерланге (интерпитируемый язык работает гораздо медленней чем .НЕТ...) рвет как тузик грулку. S>Странные у вас апачи... о_0
Yaws — это тот самый сервер, написанный на Эрланге.
Дело в том, что при больших загрузках (например, DDOS на 4 и более тысяч запросов в секунду) умирает даже не Апач, а умирает операционка:
Апач выжирает все доступные потоки системы -> система ему больше физически не может ничего отдать -> Апач ложится и не встает.
В случае с Эрлангом (где потоки легковесны и не затрагивают потоки операционной системы), Эрланг не падает даже на 80 тысячах (!) параллельных соединениях.
Таким образом для обработки 80 000 сообщений одновременно Апачу потребуется кластер из 20 машин, а Эрлангу — одна. И тот факт, что Апач написан на С никак не поможет ему в борьбе с сервером, написанном на интерпретируемом Эрланге
Здравствуйте, ДимДимыч, Вы писали:
WH>>ЗЫ Кстати как ты относишся к процедуре sendfile в линухе? ДД>Положительно. Копирование данных выполняется один раз. Со splice() еще меньше.
Так он же блокирующий... а тут утверждают что асинхронность рулит всегда...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, TarasCo, Вы писали:
WH>>Голову на отсечение даешь? Степень извращения планировщика зависиь исключительно от того кто и зачем этот планировщик пишет. TC>Да. Планировшик работает по следующим событиям: TC>1. Прерывания таймера, допустим раз в 10мс TC>2. Перевод потока в режим ожидания TC>3. Установка объект синхронизации в сигнализированное состояние, если этот объект ждет поток с более высоким приоритетом.
Да... придется тебе отрубить себе голову... ибо например планировщик системы реального времени может прервать текущий поток при наступлении любого прирывания (не только от таймера) и переключить на процесс с болие высоким приоритетом (если он был активизирован данным прерыванием). Болие того если вызов не блокирующего метода приведет к тому что проснется (или будет создан) процесс с болие высоким приоритетом то управление также не будет возвращено пока процесс с болие высоким приоритетом не отработает.
При этом политика обращения с остатком кванта может быть любой. Можно его прибавить в следующий раз (но давать работать процессу не больше двух квантов подряд чтобы не забивать процессор), можно просто забить (извини... не повезло... приоритет у тебя маленький...),...
WH>>Сравнивать управляемые и не управляемые ОС не только можно но и нужно ибо они решают одни и теже задачи. TC>Но не так. Допустим я сделаю систему с управляемым кодом, где process — это метод объектов и буду в цикле вызывать process у некоторой коллекции объектов. И скажу: "у меня переключение между процессами занимает 10 инструкций машинного кода". Ну-ка, давайте сравним с Windows и с Unix????
Процесс это единица выделения ресурсов. Чего нельзя сказать о методе.
Хотя действительно можно сделать систему в которой переключение между процессами будет занимать десятки машинных комманд. Правда для этого нужно отказатся от аппаратной защиты памяти. А еще лучше и от виртуальной памяти... чтобы не тормозила... благо современные объемы памяти позволяют.
TC>В этом случае сравнение не уместно. Сравнивать можно по объективным показателям производительности — скорость ввода/вывода, обработка больших объемов данных и.т.п.
Ну так сингулярити работает на уровне винды с линухом и это при том что ее практически не оптимизировали да и виртуальная машина там так себе.
А если сделать правильную ВМ и оптимизировать то такие ОС порвут классические как тузик грелку.
TC>Асинхронные операции делают алгоритм
Чего?
TC>Я с этим не спорю. Если есть задача написать серевре которые обслуживает 10000 запросов в час при равномерной интенсивности — тут и думать нечего — однопоточный сервер с блокирующими сокетами.
У меня система с блокирующими вызовами держит нагрузку на 2-4 десятичных порядка больше (в зависимости от размера запросов/ответов). И лимитируется пропускной способностью канала.
Что я не так делаю?
WH>>ЗЫ Кстати как ты относишся к процедуре sendfile в линухе? TC>никак, яш пробитый виндуозник
А она блокирующая... и это самый быстрый способ отправить файл по сетке.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ДимДимыч, Вы писали:
ДД>Да, shared memory тоже можно использовать. Но если нужно от родителя передать данные ребенку единожды, а тем более, если нужно чтобы модификация этих данных не была видима второму процессу, то проще (и эффективнее) ничего кроме fork() нету.
Эффективнее? Даже если в родительском процессе несколько потоков? Извини не поверю.
ДД>Если у Вас fork() создает ворох проблем, то это Ваши проблемы, а не fork'а.
Так что там со стартом нового процесса из процесса в котором несколько потоков?
ДД>Например, диспетчер должен запустить процесс так, чтобы его stdout был записан в файл, имя которого содержит pid.
Раскажи это тем кто винду писал.
ДД>Реализовывал я как-то моделирование физического процесса. Ход процесса нужно было отображать в реальном времени, поэтому каждая итерация пересчета синхронизировалась с временем.
Стандартное поведение многих компьютерных игр. ДД>Но потом оказалось, что в определенной ситуации необходимо "заглянуть в будущее" и узнать результат до того, как рендерер его отобразит. fork(), в дочернем процессе синхронизация пропускается, получаем результат "наперед" без существенной модификации кода. Это пять! Я плакалЪ! Сочувствую тем кто это потом будет поддерживать.
Я бы при словах синхронизировать по времени создал систему так чтобы можно было объектной модели сказать перейти в следующие состояние.
При словах заглянуть в будущие я бы научил объектную модель клонироваться. Да на С это делать не удобно. На С++ уже много проще. А на какомнибудь .NET или жабе это делается вобще приложением смешного колличества усилий (а для особо ленивых сериализовать/десириализовать в поток в памяти).
А если это делать на функциональном языке то там переход модели в следующие состояние происходит созданием новой модели. При такой системе для заглядывания в будущие вобще делать ничего не нужно... все язык сделает, а оптимизатор спокойно может делать модифицирующие изменеия если не нужно держать копии.
ДД>Или, например, сервер должен каждому клиенту предоставить отдельное адресное пространство. Каждый раз запускать отдельный бинарик, передавая ему необходимые параметры?
1)Чем плох этот вариант?
2)Если используется управляемая система (даже по верх классической ОС например .НЕТ или жаба) то отдельное адресное пространство не нужно.
ДД>Сколько на данный момент параметров у CreateProcess()? 10, в том числе указатель на структуру из 14 используемых записей. А если нужно ввести еще один параметр — создавать CreateProcessEx()? А еще один — CreateProcessExAdv()? С fork() проще, т.к. ничего выдумывать не надо.
А сколько параметров у System.Diagnostics.Process.Start?
То что мелкософты не сделали нормальный интерфейс для CreateProcess не делает форк прямым решением.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sheridan, Вы писали:
S>>>Ты предлагаеш углубляться в библиотечку дотнет? WH>>Библиотеку нет. Там нет ничего выдающегося. А вот изучить как работают его механизмы JIT, GC... будет очень полезно. Например на RSDN есть статья про то как работает GC в .НЕТ. S>с++ имхо всетаки побыстрее будет, пусть даже и с qt...
Вот чтобы таких вещей не думать, тебе и надо расширять свой кругозор. Дело не в платформе — надо знать вообще, как что работает. Как работает HTTP, к примеру. Как работают управляемые среды. Какие проблемы принципиальны, а какие нет. Каким образом сервера баз данных достигают такой сумасшедшей масштабируемости, и почему MS SQL Server сканирует табличку в 1000 строк настолько медленнее, чем наколенная программка — текстовый файл.
Это все фундаментальные вещи, крайне мало зависящие от языка программирования.
WH>>У нас вобще свой веб сервер который такой фигней не страдает. S>Дык ясное дело, сервак, написаный под определенную задачу будет лучше работать чем нечто такоеже, но универсальное...
Это тоже миф. Точнее, это утверждение имеет очень ограниченную область применимости, о которой можно случайно забыть. Во-первых, сейчас все больше применяют на практике методики автоматической генерации частных решений по общим (например, JIT-компиляция с оптимизацией под конкретную целевую архитектуру). Это позволяет иметь производительность общего решение не хуже, чем у частного.
Во-вторых, нужно учитывать релятивистские эффекты, т.е. конечность скорости разработки. Реализация частного решения может занять слишком долгое время, чтобы оказаться рентабельной.
В-третьих, частное решение рискует исходить из слишком зауженной постановки задачи. В итоге оно может либо оказаться вообще неприменимым, либо проигрывать по производительности общему решению. Чтобы не быть голословным — парни из Interbase в свое время решили, что некошерно использовать встроенный шедулер Windows. Вместо этого они реализовали внутре кооперативную многозадачность, естественно выиграв на однопроцессорной машине. К несчастью, на многопроцессорной машине интербейз работал из рук вон плохо, т.к. весь выполнялся в одном потоке ОС и не мог загрузить более 1 CPU.
Или отказ от реализации гранулярных блокировок в СУБД может существенно поднять производительность в read-only задачах и в однопользовательской среде по сравнению с "общим случаем". Однако появление уже второго пользователя в read-write задаче сразу отбросит такое решение на задворки.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>В случае с Эрлангом (где потоки легковесны и не затрагивают потоки операционной системы), Эрланг не падает даже на 80 тысячах (!) параллельных соединениях.
Почему? о_0
[RSDN@Home][1.2.0][alpha][668]
[В молодости учатся, а в старости понимают. [Мария Эшенбах]]
M>>В случае с Эрлангом (где потоки легковесны и не затрагивают потоки операционной системы), Эрланг не падает даже на 80 тысячах (!) параллельных соединениях.
S>Почему? о_0
Потому что все потоки (которые называются процессами в Эрланге) создаются и живут исключительно внутри виртуальной машины Эрланга. Стоимость создания, поддержки и убивания таких процессов почти нулевая. Просто Эрланг изначально создавался, как язык поддерживающий многопоточность, с упором на "много"
Например, в средней программе, написаной на Эрланге нормально создать несколько тысяч процессов — для Эрланга это естественно, а операционная система никак не затрагивается
Здравствуйте, WolfHound, Вы писали:
WH>Эффективнее? Даже если в родительском процессе несколько потоков? Извини не поверю.
Да, эффективнее. И причем здесь потоки? Я не пойму, где ты видишь проблему?
Кстати, знашь ли ты, что далеко не во всех программах требуется многопоточность?
ДД>>Если у Вас fork() создает ворох проблем, то это Ваши проблемы, а не fork'а. WH>Так что там со стартом нового процесса из процесса в котором несколько потоков?
Так что с ним такого?
ДД>>Например, диспетчер должен запустить процесс так, чтобы его stdout был записан в файл, имя которого содержит pid. WH>Раскажи это тем кто винду писал.
Я думаю они об этом знают.
ДД>>Реализовывал я как-то моделирование физического процесса. Ход процесса нужно было отображать в реальном времени, поэтому каждая итерация пересчета синхронизировалась с временем. WH>Стандартное поведение многих компьютерных игр. ДД>>Но потом оказалось, что в определенной ситуации необходимо "заглянуть в будущее" и узнать результат до того, как рендерер его отобразит. fork(), в дочернем процессе синхронизация пропускается, получаем результат "наперед" без существенной модификации кода. WH> Это пять! Я плакалЪ!
Ты наверное не понял. Это расширение функциональности было затребовано уже после того, как программа была готова и использовалась.
WH> Сочувствую тем кто это потом будет поддерживать.
А в чем собственно проблема? Изменения в коде: fork() в нужном месте, отключение рендеринга. Флаг, указывающий, это realtime или ускоренный процесс, обход задержки. Обработчик SIGCHLD в родительском процессе для получения результата.
WH>Я бы при словах синхронизировать по времени создал систему так чтобы можно было объектной модели сказать перейти в следующие состояние.
А так по сути и было сделано.
WH>При словах заглянуть в будущие я бы научил объектную модель клонироваться. Да на С это делать не удобно. На С++ уже много проще.
Частично на C++ оно и писалось. Только используемая сторонняя библиотека имела внутренние состояния, а методов доступа к ним не было.
WH>А на какомнибудь .NET или жабе это делается вобще приложением смешного колличества усилий (а для особо ленивых сериализовать/десириализовать в поток в памяти).
Угу, буду я на embeded-устройстве с 128 Мб ОЗУ и 128 Мб флеш-памяти жабу или .NET ставить. Да еще и майкрософту за винду деньги платить.
ДД>>Или, например, сервер должен каждому клиенту предоставить отдельное адресное пространство. Каждый раз запускать отдельный бинарик, передавая ему необходимые параметры? WH>1)Чем плох этот вариант?
Обращение к ФС. Лишние телодвижения для передачи аргументов. Возможность некорректного запуска бинарика, т.е. с такими параметрами, что он будет думать что он — дочерний процесс, а на самом деле запущен как родительский. Короче, через Ж..
ДД>>Сколько на данный момент параметров у CreateProcess()? 10, в том числе указатель на структуру из 14 используемых записей. А если нужно ввести еще один параметр — создавать CreateProcessEx()? А еще один — CreateProcessExAdv()? С fork() проще, т.к. ничего выдумывать не надо. WH>А сколько параметров у System.Diagnostics.Process.Start?
Не скажу, ибо не знаю откуда это вообще.
WH>То что мелкософты не сделали нормальный интерфейс для CreateProcess не делает форк прямым решением.
Предложите лучшее решение.
CreateProcess создает процесс и загружет в его пространство указанный модуль. fork() только создает процесс. execve() только загружает в пространство модуль. Так что не совсем корректно сравнивать CreateProcess и fork().
Я не говорю, что fork вообще идеален, и кроме него ничего не нужно. Не зря Линус сделал системный вызов clone(2), в который в итоге оборачивается и fork(), и thread_create. Но в большинстве случаев достаточно просто fork.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Здравствуйте, WolfHound, Вы писали: WH>Да... придется тебе отрубить себе голову... ибо например планировщик системы реального времени может прервать текущий поток при наступлении любого прирывания (не только от таймера) и переключить на процесс с болие высоким приоритетом (если он был активизирован данным прерыванием). Болие того если вызов не блокирующего метода приведет к тому что проснется (или будет создан) процесс с болие высоким приоритетом то управление также не будет возвращено пока процесс с болие высоким приоритетом не отработает.
Я говорил о работе планировщика в Windows, а не про RTOS. Ясен пень, говорить за все ОС невозможно — я могу написать планировщик как мне заблагорассудиться. Мы говорили о Windows на которой крутяться 100 потоков. А в этой славной ОС планировщик не работает при обработке любого прерывания, а только таймерного. Более того, обработчики прерываний не могут напрямую повлиять на роцесс планировки. Если им это нужно, они регистрят специальную отложенную процедуру, которая как раз и будет выполнена непосредственно перед плнировкой и может на нее повлиять. Так что голову оставлю при себе с ВАшего позволения .
WH>Хотя действительно можно сделать систему в которой переключение между процессами будет занимать десятки машинных комманд. Правда для этого нужно отказатся от аппаратной защиты памяти. А еще лучше и от виртуальной памяти... чтобы не тормозила... благо современные объемы памяти позволяют.
Вроде мы говорили об управляемых системах? Там и не нужна виртуализация памяти с целью создать изолированные пространства, да и защита памяти не нужна — управляемый код по определению не может попасть в чужую память.
WH>А если сделать правильную ВМ и оптимизировать то такие ОС порвут классические как тузик грелку.
Я не спорю кстате с этим. Это только подтверждает мои слова — в то время как системы с типа Windows занимаются всякой ерундой типа перепланировки задач, свопа памяти и.т.п управляемый код будет тупо работать.
TC>>Я с этим не спорю. Если есть задача написать серевре которые обслуживает 10000 запросов в час при равномерной интенсивности — тут и думать нечего — однопоточный сервер с блокирующими сокетами. WH>У меня система с блокирующими вызовами держит нагрузку на 2-4 десятичных порядка больше (в зависимости от размера запросов/ответов). И лимитируется пропускной способностью канала. WH>Что я не так делаю?
Во-первых не приводите конфигурацию системы, во вторых imho чуть чуть приувеличиваете — 10 000 * 100, я поверю. Учитывая, что железа и процессоров мы не жалеем, я могу представить себе систему — 8ГБ памяти 4 процессора, получится, что у Вас примерно 50-70 запросов в секунду на каждый процессор. Или по 10мс — вообщем, ничего удивительного, похоже на квант времени . А 10 000 * 10 000 — это около 30000 запросов в секунду, у Вас там лагов немерянно. Хотя рассказать можно все что угодно .
WH>>>ЗЫ Кстати как ты относишся к процедуре sendfile в линухе? TC>>никак, яш пробитый виндуозник WH>А она блокирующая... и это самый быстрый способ отправить файл по сетке.
Это ни очем не говорит. Если Вы будете звать ее в цикле для передачи мелких файлов через сеть, то получите следующее — вызов, потеря кванта. Если файл передается быстрее кванта времени — в передаче будут дырки. Асинхронные методы позволили бы этого избежать.
Mamut wrote: > В случае с Эрлангом (где потоки легковесны и не затрагивают потоки > операционной системы), Эрланг не падает даже на 80 тысячах (!) > параллельных соединениях.
Зато Yaws ляжет, если каждому из потоков нужно будет отдать файл
размером в 10Мб. Просто из-за того, что Apache использует sendfile,
который работает в режиме ядра.
WolfHound wrote: > WH>>ЗЫ Кстати как ты относишся к процедуре sendfile в линухе? > ДД>Положительно. Копирование данных выполняется один раз. Со splice() > еще меньше. > Так он же блокирующий... а тут утверждают что асинхронность рулит всегда...
Он асинхронный, точнее он не имеет отношения к синхронности или
асинхронности.
При желании с помощью splice можно одновременно писать в буффер, из
которого драйвер устройства в это же время уже читает данные.
C>Mamut wrote: >> В случае с Эрлангом (где потоки легковесны и не затрагивают потоки >> операционной системы), Эрланг не падает даже на 80 тысячах (!) >> параллельных соединениях. C>Зато Yaws ляжет, если каждому из потоков нужно будет отдать файл C>размером в 10Мб. Просто из-за того, что Apache использует sendfile, C>который работает в режиме ядра.
Возможно, не спорю. Но это надо замеры производить или прикручивать sendfile к yaws
Mamut wrote: > C>Зато Yaws ляжет, если каждому из потоков нужно будет отдать файл > C>размером в 10Мб. Просто из-за того, что Apache использует sendfile, > C>который работает в режиме ядра. > Возможно, не спорю. Но это надо замеры производить или прикручивать > sendfile к yaws
А не получится прикрутить — он блокирующийся То есть нужно будет
создавать пул системных потоков, которые будут выполнять sendfile. Ну в
общем, Апач и получится в итоге.
Здравствуйте, ДимДимыч, Вы писали:
ДД>Я согласен с тем, что асинхронность рулит не всегда. ДД>Но где написано, что он блокирующий? Просто не встречал такой информации.
Ты мне лучше покажи где написанно что он асинхронный. Или хотябы может работать асинхронно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ДимДимыч, Вы писали:
WH>>Эффективнее? Даже если в родительском процессе несколько потоков? Извини не поверю. ДД>Да, эффективнее. И причем здесь потоки? Я не пойму, где ты видишь проблему?
При том что они тоже клонируются... и начинают страници инвалидировать...
ДД>Кстати, знашь ли ты, что далеко не во всех программах требуется многопоточность?
Знаю.
WH>>Так что там со стартом нового процесса из процесса в котором несколько потоков? ДД>Так что с ним такого?
ТОРРРРРМОЗЗЗАААА!!!!
ДД>>>Например, диспетчер должен запустить процесс так, чтобы его stdout был записан в файл, имя которого содержит pid. WH>>Раскажи это тем кто винду писал. ДД>Я думаю они об этом знают.
И работают без форка...
ДД>Ты наверное не понял. Это расширение функциональности было затребовано уже после того, как программа была готова и использовалась.
Я понял. Просто я не понял какие проблемы склонировать модель? Или ты написал программу в худших традициях фортрана?
ДД>А в чем собственно проблема? Изменения в коде: fork() в нужном месте, отключение рендеринга. Флаг, указывающий, это realtime или ускоренный процесс, обход задержки. Обработчик SIGCHLD в родительском процессе для получения результата.
Это называется в чем проблема... я фигею дорогая редакция.
ДД>Частично на C++ оно и писалось. Только используемая сторонняя библиотека имела внутренние состояния, а методов доступа к ним не было.
Угу... оправдываем наличие кривизны криворокими программистами... прэлесно.
ДД>Угу, буду я на embeded-устройстве с 128 Мб ОЗУ и 128 Мб флеш-памяти жабу или .NET ставить. Да еще и майкрософту за винду деньги платить.
1)128 метров памяти болие чем достаточно для того чтобы поднять жабу.
2)Так причем тут винда? Жаба на линуксе работать умеет.
3)Это легко делается везде где есть рантайм рефлексия или еще лучше метапрограммирование.
ДД>Обращение к ФС.
Ты хотел сказать обращение к уже загруженному в память бинарному образу. Причем никто его клонировать не будет. Его зашарят.
По твоему туже винду совсем идиоты писали? ДД>Лишние телодвижения для передачи аргументов.
Какой кошмар... берешь любой OORPC хоть COM хоть CORBA и никаких проблем.
А в системах с метаинформацией вобще и управляемых ОС в частности можно делать входные точки процесса с произвольной сигнатурой. ДД>Возможность некорректного запуска бинарика, т.е. с такими параметрами, что он будет думать что он — дочерний процесс, а на самом деле запущен как родительский.
А зачем ему это вобще знать? ДД>Короче, через Ж..
И это говорит любитель форка...
WH>>А сколько параметров у System.Diagnostics.Process.Start? ДД>Не скажу, ибо не знаю откуда это вообще.
Это из библиотеки .НЕТ
WH>>То что мелкософты не сделали нормальный интерфейс для CreateProcess не делает форк прямым решением. ДД>Предложите лучшее решение.
Ну допустим както так
InitCreateProcessInfo не переходит в режим ядра ибо не нужно. Эта процедура инициализирует структуру значениями по умолчанию.
CREATE_PROCESS_INFO_VERSION нужен на случай изменения структуры в будущем.
Вобщем банальный ООП.
Короче посмотри на System.Diagnostics.Process там все весьма не плохо сделано.
Да это несколько длиннее чем fork но за то нам не нужно решать проблемы которые создает fork, а это очень большой плюс.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, TarasCo, Вы писали:
TC>Я говорил о работе планировщика в Windows, а не про RTOS. Ясен пень, говорить за все ОС невозможно — я могу написать планировщик как мне заблагорассудиться. Мы говорили о Windows на которой крутяться 100 потоков.
Вобщето разговор изначально шол про юникс клоны. После чего плавно перешол на ОС вобще. TC>А в этой славной ОС планировщик не работает при обработке любого прерывания, а только таймерного.
Если мне не изменяет скалероз работа планировщика в этой ОС вобще не документирована и меняется от версии к версии. TC>Более того, обработчики прерываний не могут напрямую повлиять на роцесс планировки.
И кто мешает мелкософтам это поменять? TC>Если им это нужно, они регистрят специальную отложенную процедуру, которая как раз и будет выполнена непосредственно перед плнировкой и может на нее повлиять. Так что голову оставлю при себе с ВАшего позволения .
[голосом мегазлодея]
Не зарекайся... [безумный смех]Муха-ха-ха-ха-ха-ха...[/безумный смех]
[/голосом мегазлодея]
TC>Вроде мы говорили об управляемых системах? Там и не нужна виртуализация памяти с целью создать изолированные пространства, да и защита памяти не нужна — управляемый код по определению не может попасть в чужую память.
Я это все прекрасно знаю.
Только учти что если тебе понадобится адресного пространства больше чем есть физической памяти тебе всеравно придется использовать виртуализацию.
TC>Во-первых не приводите конфигурацию системы, во вторых imho чуть чуть приувеличиваете — 10 000 * 100, я поверю. Учитывая, что железа и процессоров мы не жалеем, я могу представить себе систему — 8ГБ памяти 4 процессора, получится, что у Вас примерно 50-70 запросов в секунду на каждый процессор. Или по 10мс — вообщем, ничего удивительного, похоже на квант времени . А 10 000 * 10 000 — это около 30000 запросов в секунду,
4 это я не по той клавиши попал. 2-3 порядка. TC>у Вас там лагов немерянно.
Чего?
TC>Это ни очем не говорит. Если Вы будете звать ее в цикле для передачи мелких файлов через сеть, то получите следующее — вызов, потеря кванта. Если файл передается быстрее кванта времени — в передаче будут дырки. Асинхронные методы позволили бы этого избежать.
Гм... А почему тогда dstat говорит что гигабитная сеть забита под завязку?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Я уже давно понял, что производительность положена на алтарь скорости разрботки. Поэтому и требуются все более и более мощные компы...
Я все жду хотябы прогноза — когдаже перестанут гнать количество, а возьмутся за качество. Но думаю очень нескоро...
WolfHound wrote: > ДД>Я согласен с тем, что асинхронность рулит не всегда. > ДД>Но где написано, что он блокирующий? Просто не встречал такой информации. > Ты мне лучше покажи где написанно что он асинхронный. Или хотябы может > работать асинхронно.
splice() просто помещает страницы в ядерное пространство, он больше
ничего не делает. Помещение страниц в ядро — очень быстрая операция, так
как просто нужно поправить несколько дескрипторов.
Что дальше с этими страницами будешь делать — твое личное дело. Можешь,
например, натравить на них DMA (который есть асинхронный). А можешь
отдать sendfile'у, который синхронный.
Sheridan wrote: > Если это так, то это хорошо. Но вот чтото мне подсказывает, что не так > все гладко.
Это "что-то" тебе подсказывает неправильно. Тысячи и сотни тысяч одновременных процессов в Эрланге — это самое обычное дело. Это
все прекрасно работает из-за того, что процессы там легковесные — и на
один системный поток может проецироваться несколько эрланговских процессов.
Этот трюк еще в JRockit для Java применяется.
> зы В баше создать пару тыщ процессов в крупном скрипте также естесственно.
Не одновременно.
Здравствуйте, WolfHound, Вы писали:
WH>Да это несколько длиннее чем fork но за то нам не нужно решать проблемы которые создает fork, а это очень большой плюс.
Если форк создает проблемы — не используй форк. В чем проблемы-то?
>> C>Зато Yaws ляжет, если каждому из потоков нужно будет отдать файл >> C>размером в 10Мб. Просто из-за того, что Apache использует sendfile, >> C>который работает в режиме ядра. >> Возможно, не спорю. Но это надо замеры производить или прикручивать >> sendfile к yaws C>А не получится прикрутить — он блокирующийся То есть нужно будет C>создавать пул системных потоков, которые будут выполнять sendfile. Ну в C>общем, Апач и получится в итоге.
Интересно, в рассылке создатель Yaws ответил следующее:
I'm pretty sure that apache would outperform yaws here — unless
the number of concurrent clients requesting these 10M files
is large — in which case I think yaws would do fine.
Anyway, the test is mostly uninteresting, also building a sendfile
driver and use that for large files in Yaws is a p.o.c — it would probably
take several hours to do ....
Здравствуйте, WFrag, Вы писали:
WF>Если форк создает проблемы — не используй форк. В чем проблемы-то?
Я стараюсь... вот только как иначе в юниксах процессы создавать?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WF>>Если форк создает проблемы — не используй форк. В чем проблемы-то? WH>Я стараюсь... вот только как иначе в юниксах процессы создавать?
Ты вообще читаешь, что тебе пишут? Как минимум три варианта назвали — clone, vfork, posix_spawn. Причем последняя функция — POSIX-овая. Почитай на нее ман (в частности, раздел RATIONALE), много интересного найдешь.
Здравствуйте, WolfHound, Вы писали:
WH>При том что они тоже клонируются... и начинают страници инвалидировать...
Они не клонируются. После fork()'а в дочернем процессе работает один поток.
WH>Я понял. Просто я не понял какие проблемы склонировать модель? Или ты написал программу в худших традициях фортрана?
Еще раз: проблема была в том, что сторонняя библиотека не предоставляла методов для сохранения и восстановления своего контекста.
ДД>>Частично на C++ оно и писалось. Только используемая сторонняя библиотека имела внутренние состояния, а методов доступа к ним не было. WH>Угу... оправдываем наличие кривизны криворокими программистами... прэлесно.
ДД>>Угу, буду я на embeded-устройстве с 128 Мб ОЗУ и 128 Мб флеш-памяти жабу или .NET ставить. Да еще и майкрософту за винду деньги платить. WH>1)128 метров памяти болие чем достаточно для того чтобы поднять жабу. WH>2)Так причем тут винда? Жаба на линуксе работать умеет. WH>3)Это легко делается везде где есть рантайм рефлексия или еще лучше метапрограммирование.
В эти 128 метров еще должны поместиться иксы с OpenGL, куча спрайтов/текстур и других ресурсов.
Мне начинать изучать джаву или .NET, чтоб тулить их туда, где задача прекрасно решается без них?
ДД>>Обращение к ФС. WH>Ты хотел сказать обращение к уже загруженному в память бинарному образу. Причем никто его клонировать не будет. Его зашарят.
А если еще не загруженому?
WH>По твоему туже винду совсем идиоты писали?
По-видимому не совсем. В linux'е тоже есть такой sharing, только он не используется там, где без него можно обойтись.
ДД>>Лишние телодвижения для передачи аргументов. WH>Какой кошмар... берешь любой OORPC хоть COM хоть CORBA и никаких проблем.
И нахрена мне все это, если есть более простые и быстрые способы?
ДД>>Короче, через Ж.. WH>И это говорит любитель форка...
Jedem das seine.
WH>>>То что мелкософты не сделали нормальный интерфейс для CreateProcess не делает форк прямым решением. ДД>>Предложите лучшее решение. WH>Ну допустим както так WH>
WH>InitCreateProcessInfo не переходит в режим ядра ибо не нужно. Эта процедура инициализирует структуру значениями по умолчанию. WH>CREATE_PROCESS_INFO_VERSION нужен на случай изменения структуры в будущем.
И поддерживать все возможные версии? А если их станет слишком много, старые убирать, теряя обратную совместимость?
WH>Вобщем банальный ООП.
Я не сторонник пихания ООП во все подряд.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Здравствуйте, TarasCo, Вы писали:
TC>С этим согласен . Правда страницы по факту коммититься по 64К, т.е их будет не меньше 16 + 3 страницы ядерного стека, который при ожидании юзеровский операций также свопиться. Да к тому же среднее виндовое приложения полюбасу более 64К использует . У меня есть другой аргумент — активное переключение задач будет приводить к постоянному вытеснению стека из кеша процессора, что также при активном использовании стека не есть гуд. .
А какое переключение не будет?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sheridan, Вы писали:
S>Для меня москва это самый последний город куда я поеду. Ибо сумашедший дом. А если и искать работу в других городах то для меня список такой по степени так сказать желания в этом городе работать: МинВоды, Пятигорск, Ставрополь, Железноводск, Кисловодск, Ессентуки, Георгиевск, Краснодар, Ростов ..... СПБ, Москва.
Варианты Redmond (Bellevue, Kirkland, Seattle), NY, LA etc не рассматриваются?
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Получается, что стоимость винды разнесенная к тому же года на три юзания, составляет всего лишь одну шестую-одну пятую от стоимость МЕСЯЧНОГО съема хаты в Москве! Офигеть как дорого!
1.2.0 alpha rev. 655
