Marmot писал(а):Ты имеешь ввиду ребят написавших SQL-server?
или OpenSSH?
это ты о чем? я могу тебе про ребят из оракла сказать у которых транзакция не ролбекалась при выключении питания машины и они потом патч призылали флеймер!
Marmot писал(а):Ты имеешь ввиду ребят написавших SQL-server?
или OpenSSH?
это ты о чем? я могу тебе про ребят из оракла сказать у которых транзакция не ролбекалась при выключении питания машины и они потом патч призылали флеймер!
Oops, sorry Папа, у меня под рукой ссылки на Oracle не оказалось, но это только подтверждает мою мысль, Oracle написан на plain C
Добавление:
Пап, ты бы сначала прочитал бы трэд, сходил бы по линкам, у меня там на всё подтверждения имеются, я тебе не просто флеймер...
Последний раз редактировалось Marmot 20 сен 2003, 19:17, всего редактировалось 1 раз.
drain bamage писал(а):buf. overflows - это при прочих равных важно для студентов 1-2 курса .. ну и для тех, кто не знает как корректно работать с памятью ..
Ты имеешь ввиду ребят написавших SQL-server?
или OpenSSH?
sure .. поверь мне, что для имплементации любого протокола, особенно используя готовые crypto libraries, особого ума не надо. если там случился buf overflow - значит с хорошей вероятностью (надо будет сорцы поглядеть) у них не было consistent framework для работы с памятью в общем и для парсинга inbound пакетов в частности.
Marmot писал(а):Ты имеешь ввиду ребят написавших SQL-server?
или OpenSSH?
это ты о чем? я могу тебе про ребят из оракла сказать у которых транзакция не ролбекалась при выключении питания машины и они потом патч призылали флеймер!
Oops, sorry Папа, у меня под рукой ссылки на Oracle не оказалось, но это только подтверждает мою мысль, Oracle написан на plain C
самое крутое что не поддавалось никакому объяснению это появление не NULL значений в свеже добавленном аттрибуте (GUID) и некоторых других постановах. я заклеймил этот баг в мс, они его пофиксили в первом сервиспаке (вроде фикс №52 или что-то около того), после того как я зааплаил тот сервис пак я все еще наблюдал эту проблему редко, но наблюдал потом нашли другой баг.... это была чистая специфика с распределением памяти при работе с курсорами и хмлом сразу.... мс сказал что пофиксит где-то в конце 2003 года.... вышел 3а сервис пак.... над опроверять
на самом деле.... обычная большая лавка, много народу большие проекты, большие деньги. обхаивать можно что угодно, только у нас нет даже этого
Господа, как я вас всех понимаю, вы бы были абсолютно правы, если бы не самая большая проблема IT: КАТОСТРАФИЧЕСКАЯ НЕХВАТКА УМНЫХ ЛЮДЕЙ!!!
Если бы все были такие умные как вы, всё бы было прекрасно!!!
НО, >90% современных программистов не понимают всех этих сложностей, и никогда не смогут понять!
Кто-то должен им помочь, и VM - это один из способов облегчить их страдания!!!
Marmot писал(а):Господа, как я вас всех понимаю, вы бы были абсолютно правы, если бы не самая большая проблема IT: КАТОСТРАФИЧЕСКАЯ НЕХВАТКА УМНЫХ ЛЮДЕЙ!!!
Если бы все были такие умные как вы, всё бы было прекрасно!!!
НО, >90% современных программистов не понимают всех этих сложностей, и никогда не смогут понять!
Кто-то должен им помочь, и VM - это один из способов облегчить их страдания!!!
смотри.... я иногда поигрываю в каунтер страйк.... раз играли.... 5 игроков с каждой стороны: мы, пятеро, средние игроки, но хорошо сыгранная команда, на той стороне 4 крутых пацана, но не сыгранная команда вообще (каждый воюет за себя)... они проиграли 10:0
к чему это? к тому, что наличие крутых мало. гвозди можно экскаватором забивать. надо знать как использовать то, что у тебя есть
мне нужен с№. бейсик мне не нравится (в школе на программировался). с++ нравится, и могу, но с памятью возиться лень, явы не знаю и наверное не хочу, а хочется сделать все быстро. стал я из-за этого плохим программистом? может быть. волнует меня это или нет? наверное нет
А я и не говорил что эти парни плохие программисты...
Их называют по разному: average developers, corporate developers, system analists, etc.
Это люди которые заинтересованы в конечном результате а не в технологии...
Они не могут и не хотят разбираться во всех наворотох C++.
--Они не могут и не хотят разбираться во всех наворотох C++.
откуда там навороты ? описание в 20 страниц.
Вот PL/1 был - 200 страниц книжка. И то никто не жаловался.
Уж если таким программистам сложно прочитать про весьма незатейливые языковые конструкции - мне очень жаль за таких программистов.