|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Vladimir Lazarenko 2:461/106 17 Jun 2003 01:00:16 To : Michael Shigorin Subject : еще по поводу модератора -------------------------------------------------------------------------------- 17 Jun 03 02:05, you wrote to me: >> С таким подходом много не заплатят. rb1/2 может и пользует такие >> методы, а вот мы просто финансово, исходя из своих SLA не можем себе >> такое позволить. MS> Ой ли? MS> Вот если за SLA говорить -- однозначно не верю, что самопальный MS> велосипед лучше доведенного по месту фабричного. Лучше... Если для того, чтобы оформить RPM под Tru64 - его надо переписать - надо написать свое. В этом случае девелоперу, чтобы пофиксить баг, не надо колупаться в чужом, недокументированом API. (Я не в курсе насколько хорошо документирован API RPM, но я сомневаюсь, что настолько тщательно как наш внутренний код. MS> Пример: свежая неприятность в компоненте системы, который вроде как не MS> является совсем critical (в плане того, что его обтачивать надо) -- MS> например, glibc -- но при этом у кастомера появляется возможность MS> залететь от какой-нить проезжей SMS-ки или недовольного жизнью MS> инженера. Ты не поверишь, но у системы есть совокупный годовой downtime, оговоренный в SLA, и такие случаи там тоже предусмотрены :) (И люди за это платят миллионы? - Кашмар). А обточка - 24/7 в случае варианта. что система залетает от SMS, или еще чего, т.е. reproduce at will. В таком случае дежурный девелопер лабает hotfix, после чего фиксится в mainstream софте. maintenance releases выпускаются в среднем раз в месяц, с собранием подобного дерьма, и ролаутятся на системы опять. Каменный век :) >> AK> А отслеживать все текущие глюки/баги/правки по живому в хотя бы >> AK> основных вещах - ядре, glibc и т.п лично я уже давно не в силах >> AK> - не хватает ни квалификации, ни времени. Т.е даже просто >> AK> оценить MS> Ja, ja, оно самое. Более 8000 девелоперов занимаются 15 программными продуктами. Есть у них время? :) Есть. За то и платят. >> AK> актуальность/нужность фирменных патчей (а их десятки, если не >> AK> сотни) - не получается. >> Угу. А есть люди, которым за это платят, и они этим занимаются на >> работе. Мы же, пожинаем плоды их работы. И поверь мне, у тех людей, MS> Я не поверю. Потому что квалификация подразумевает и умение оценить MS> обстановку и не заниматься дурной работой. Они не занимаются тупой работой. Они занимаются тестированием всего что нам надо в том opensource, который используется, и если там находится баг, они его фиксят. >> которые у нас в конторе этим занимаются, квалификации хватает. >> (Патчей кстати сотни таки...) MS> Тьфу ты. Это значит, plain and simple, что ваша контора на дурную MS> голову бабки на ветер бросает. MS> Потому как дублирует своими фултаймерами работу других фултаймеров -- MS> не хуже, как минимум (в каком-нить IBM или HP). Hе дублируют они HP && IBM. Мы не пользуем glibc их реализации. KISS-style - Keep it simple, stupid. www.gnu.org - это используется. Собирается in the house. С gnu.org идет замечательная полновременная переписка, насколько я знаю. MS> Hо толку от этого -- грамм, потому как остается-то он (толк) внутри MS> конторы, и его каждый раз надо ПЕРЕИЗОБРЕТАТЬ. Да нет. gnu.org - весьма хороши в feedback control. MS> Hу на пальцах -- почему не сели писать httpd свой? libc? kernel? httpd в последнем релизе практически переписан, так как он уже не столько httpd, сколько Corporate Account server. Для web-applications - обычный customised apache. MS> Так вот ровно потому же (проще допилить) и другие части техцепочки MS> осмысленно доводить до уровня. MS> Я понятно излагаю? :-) Абсолютно. Я согласен, что некоторые вещи в европейских конторах делаются с нашей точки зрения неправильно. Hо тогда ответьте мне на избитый вопрос :) "Если вы все такие умные, почему же вы строем не ходите?" (с) Т.е. я в том смысле, что если все так херово, то почему они на этом делают миллиарды, а мы нет? MS> ---- WBR, Michael Shigorin <mike@altlinux.ru> Vladimir --- GoldED+/LNX 1.1.5 * Origin: Doubledutch (2:461/106) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/18173eee4eca.html, оценка из 5, голосов 10
|