On Fri, Jun 29, 2001 at 05:44:22PM +0400, Khimenko Victor wrote:
> > Методом перезапуска и правки конфига, ведь правда? А в таком коленкоре
> > можно и перетранслировать что надо.
> >
> Ну можно и операционку свою написать. Перетрансляция и изменение
> конфига - вещи все же разных порядков (например для перетрансляции нужно
> исходники иметь). Человек, налаживающий работу сервера, вообще говоря, и
> вообще не должен уметь этот самый Apache компилировать.
Он должен сказать кому надо "надо модуль такой-то", а не совать непойми
какую бинарную хню.
> > > системе после upgrade glibc у нас перестала работать Berkeley DB и
> >
> > Извини, но такие странные проблемы мне не понять. У меня нет glibc,
> > а когда апгрэйдится libc, то ничего страшного не происходит. Может
> > стоит в консерватории что подправить?
> >
>
> В glibc 2.1.3 входила Berkeley DB 1.x. В glibc 2.2 нет вообще никакой (ибо
> 1.x многим программам не подходит, а с 3.x есть проблемы с лицензией).
Ну и что? Я не понимаю проблемы. Не взять из гнезда DB 1.x и не подсунуть
ее через LD_PRELOAD? (Я не обсуждаю вопрос, почему в glibc не включили
1.x и 2.x -- еще раз повторюсь, я не комсомолец придумывать себе трудности)
> сборки Apache тоже). Просто это из того, что сразу вспомнилось. А переход
> gd с GIF'ов на PNG не забыли ?
И что? Апач-то тут каким боком?
> И еще такие случаи случались (после чего
> тут начинался поиск портов новых версий под FreeBSD обычно)...
Чего-чего начинается? Это как? Все хором ищут у себя на диске каталог
/usr/ports? Или что?
> А когда
> security hole в mod_rewrite была найдена - что делать со статически
> влинкованной версией ?
Как чего? Ничего. У меня не используется mod_rewrite. А так -- наложить патч и пересобрать. А ты чего делать будешь?
> Да, можно все время даржеть Apache "на верстаке",
> чтобы иметь возможность ее пересобрать. Но только если это - не основная
> ваша деятельность и вы его переконфигуарцией раз в полгода занимаетесь, то
> как-то странной выглядит наладка всей этой инфраструктуры...
Тебе что, жалко держать configure.status от него? Или раскрытые сырцы?
> То есть ? Где-то есть Alpha или Sparc ? А зачем ? Конечно в этом случае
Да. А чего я спрашивается должен менять-то работающую конфигурацию?
Оно с 1995 года работает. Или тогда были писюки, сравнимые с альфой?
Или операционки на писюках сравнялись по качеству с опреционками на
Alpha/Sparc?
> никакой бинарной дистрибуции не получится. Но опять-таки: ЗАЧЕМ ? Для
> какой-такой задачи (активно использующей Apache) IA32 не подошел ?
Ну говно ж IA32. Да, очень дешевое. Но говно.
> > кое-где версии libc принципиально другие,
>
> Опять-таки: зачем ?
Я маньяк их каждые полгода менять? Работает и не трогаю.
>
> > а совместимость я включать не хочу.
> >
> Хозяин - барин. Если вам хочется выиграть уже вычислявшиеся тут 10% (а на
> самом деле куда меньше) - можете не включать совместимости и вообще все на
> ассемблере написать если вы Левшой заделались.
Чего-чего? Ты вообще понял, про что я написал?
> (это просто неправда :-). Я объяснял - почему нормальным людям, которые
> несовершенны, иногда совершают ошибки и не знают всех тонкостей работы
> gcc, kernel'а и/или make не стоит связываться с пересборкой чего бы то ни
> были "под систему" без КРАЙНЕЙ необходимости. Ключевое слово: "серийное
> производство".
Серийным производством должны заниматься профессионалы.
> кучу усовершенстваний внести. Почему ? Дешевле. В конечном итоге. Да, я
> понимаю, что это выглядит кощунством: настройка сервера без знания C/C++,
> make, vi или b-shell'а.
70 лет нашей страной управляла каждая средняя кухарка. Ну и?
> Но именно ТАК должна быть устроена система для
> "массового потребителя".
А, так ты про виндуз.
=============================================================================
= Apache-Talk@xxxxxxxxxxxxx mailing list =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
= Archive avaliable at http://www.lexa.ru/apache-talk =
"Russian Apache" includes software developed
by the Apache Group for use in the Apache HTTP server project
(http://www.apache.org/) See
Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C)
1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.