А зачем загрузчику уметь LVM? Держать /boot на отдельном маленьком разделе в начале диска (в ext2, конечно) — это очень полезно и удобно. А все остальное можно уже отвести под LVM, поддержкой этого уже должно озаботиться ядро/initramfs.
Совершенно не понимаю сарказма. Комментарий был по существу, Вы ведь не сказали, что подразумеваете под «фейк рейд» — софтварный рейд средствами системы или маркетинговый рейд, присутствующий на современных матерях.
MyISAM и InnoDB — это сама по себе длинная и грустная история, лично для меня закончившаяся переводом критично важных баз на постгрес. InnoDB определенно лучше MyISAM, но в случае повреждения журнала его поведение совершенно неадекватно, а именно — блокируется запуск mysqld целиком до внесения innodb_force_recovery в конфиг. Когда из-за проблем в одной таблице одной базы (пусть даже достаточно серьезных) не запускается демон, обслуживающий множество других баз — это ненормально.
Постгрес попробовать стоит, но не на заббиксе. Последние два дня тестирования показали, что поддержка постгреса там скорее для галочки, а не на уровне нормального продакшена.
Что касается графиков по расписанию, то я подразумевал то, как это сделано в cacti — графики могут создаваться и на лету при запросе, но могут и генерироваться как графические файлы в указанной папке. Возможность включать-выключать этот механизм должна быть доступна через веб-интерфейс. Тогда можно включить это для нескольких графиков, а остальные оставить в стандартном режиме.
Даже если на графики никто не смотрит, они все равно могут генерироваться. Например, они могут висеть на отдельном рабочем столе либо вовсе в кач-ве обоев. Знаю людей, находящих это удобным.
Что до актуальности, то на оси абсцисс ведь указывается время, поэтому видно, когда график в последний раз обновлялся. Хотя, конечно, нулевые значения лучше видно, чем дату.
Но вообще мне кажется, что вылизываемый десятилетиями крон более надежен, чем браузер-вебсервер-пхп, поэтому вряд ли с расписанием что-то случится :)
В разных ситуациях удобны разные подходы и было бы просто замечательно, если бы авторы давали выбор. В связи с этим я бы с удовольствием пользовался cacti, но заббикс все-таки намного больше умеет делать :)
Жил-был у меня zabbix с базами в mysql. Довольно долго жил, прежде чем однажды mysql не упал вместе с виртуальной машиной. После поднятия в заббиксе исчезли несколько элементов данных, из которых строились графики. Очень было печально, в результате поднял новый заббикс, но уже на PostgreSQL. Заодно и более свежую версию заббикса использовал.
Но не все оказалось так просто. Поддержка постгреса оставляет желать лучшего. Например, при создании хоста из шаблона и попытке деактивировать ненужные элементы данных веб-морда после долго размышления выбрасывала логи неудачных sql-запросов. Когда же я пытался удалить сразу несколько элементов данных, веб-морда основательно висла, а постгресовые логи непрерывно заполнялись сообщениями о тысячах одинаковых неудачных транзакций…
Еще в заббиксе огорчает невозможность генерировать графики по расписанию, а не пхп-кодом по запросу. Куда менее ресурсоемко было бы, имхо.
А в целом система неплохая, да. Особенно радуют возможности манипулировать графиками в ajax-стиле, с выделениями участков графика для их масштабирования по времени и пр.
Дело не столько в совместимости, сколько в стандартизации. Например, я однажды не смог использовать 2.6, поскольку в дистрибутиве был постгресовый драйвер только для 2.5, а из исходников он собираться не желал. И таких мелочей довольно много.
Что до дистрибутивов, то времени у их авторов теперь много… А переходить на третью ветку рано или поздно все равно придется. Вон перепишут гентушники emerge на третьем питоне — будет прорыв :)
В целом я хотел сказать, что слишком много разных версий языка находится в активном использовании, пусть даже они не очень друг от друга отличаются.
Прошу прощения, промазал по кнопке. Оказывается, комменты на Хабре отправляются по ctrl+enter :)
Итак, пусть разработчики занимаются улучшением реализации текущего стандарта языка, авторы всех более-менее полезных проектов — переводом их на третью версию, а сборщики дистрибутивов — включением этой версии по умолчанию. Думаю, язык уже убежал достаточно далеко и многие за ним попросту не успевают. Поэтому лучше потратить несколько лет на приведение всех систем/библиотек/проектов к общему виду, чтоб избавиться от текущей мешанины из версий 2.4, 2.5, 2.6, 3… А когда все подтянутся, можно шагать дальше :)
Ну Вы же несете чушь, почему мне нельзя? То, что Вам неудобно, Вы не умеете, Вам лень учиться — это только Ваша проблема, не нужно заявлять, будто это «просто неудобно» для всех.
Ну лично на мне отразилось заметным ухудшением качества связи. Если раньше мною UMC использовалось как качественная связь, а Лайф — как дешевая, то теперь они все более и более схожи.
billing=# select * from tasks having id > 5;
ERROR: column "tasks.id" must appear in the GROUP BY clause or be used in an aggregate function
СТРОКА 1:select * from tasks having id > 5;
^
billing=#
Если MySQL позволяет так делать, это еще не значит, что так можно :)
Постгрес попробовать стоит, но не на заббиксе. Последние два дня тестирования показали, что поддержка постгреса там скорее для галочки, а не на уровне нормального продакшена.
Что касается графиков по расписанию, то я подразумевал то, как это сделано в cacti — графики могут создаваться и на лету при запросе, но могут и генерироваться как графические файлы в указанной папке. Возможность включать-выключать этот механизм должна быть доступна через веб-интерфейс. Тогда можно включить это для нескольких графиков, а остальные оставить в стандартном режиме.
Даже если на графики никто не смотрит, они все равно могут генерироваться. Например, они могут висеть на отдельном рабочем столе либо вовсе в кач-ве обоев. Знаю людей, находящих это удобным.
Что до актуальности, то на оси абсцисс ведь указывается время, поэтому видно, когда график в последний раз обновлялся. Хотя, конечно, нулевые значения лучше видно, чем дату.
Но вообще мне кажется, что вылизываемый десятилетиями крон более надежен, чем браузер-вебсервер-пхп, поэтому вряд ли с расписанием что-то случится :)
В разных ситуациях удобны разные подходы и было бы просто замечательно, если бы авторы давали выбор. В связи с этим я бы с удовольствием пользовался cacti, но заббикс все-таки намного больше умеет делать :)
Но не все оказалось так просто. Поддержка постгреса оставляет желать лучшего. Например, при создании хоста из шаблона и попытке деактивировать ненужные элементы данных веб-морда после долго размышления выбрасывала логи неудачных sql-запросов. Когда же я пытался удалить сразу несколько элементов данных, веб-морда основательно висла, а постгресовые логи непрерывно заполнялись сообщениями о тысячах одинаковых неудачных транзакций…
Еще в заббиксе огорчает невозможность генерировать графики по расписанию, а не пхп-кодом по запросу. Куда менее ресурсоемко было бы, имхо.
А в целом система неплохая, да. Особенно радуют возможности манипулировать графиками в ajax-стиле, с выделениями участков графика для их масштабирования по времени и пр.
Что до дистрибутивов, то времени у их авторов теперь много… А переходить на третью ветку рано или поздно все равно придется. Вон перепишут гентушники emerge на третьем питоне — будет прорыв :)
В целом я хотел сказать, что слишком много разных версий языка находится в активном использовании, пусть даже они не очень друг от друга отличаются.
Итак, пусть разработчики занимаются улучшением реализации текущего стандарта языка, авторы всех более-менее полезных проектов — переводом их на третью версию, а сборщики дистрибутивов — включением этой версии по умолчанию. Думаю, язык уже убежал достаточно далеко и многие за ним попросту не успевают. Поэтому лучше потратить несколько лет на приведение всех систем/библиотек/проектов к общему виду, чтоб избавиться от текущей мешанины из версий 2.4, 2.5, 2.6, 3… А когда все подтянутся, можно шагать дальше :)
Да ради бога, кто Вас заставляет. Пользуйтесь своим Блокнотом и дальше…
Имхо, проще
Хотя вообще очень полезная штука — плагин FuzzyFinder — файловый менеджер, список буферов, история файлов, история команд и т.д.
billing=# select * from tasks having id > 5; ERROR: column "tasks.id" must appear in the GROUP BY clause or be used in an aggregate function СТРОКА 1:select * from tasks having id > 5; ^ billing=#Если MySQL позволяет так делать, это еще не значит, что так можно :)
Больше привык к cat /etc/*release* или cat /etc/*version*
Указанный лог — Debian testing.
No LSB modules are available.
ineu@ineu ~ % uname -a
Linux ineu.loc 2.6.30-1-amd64 #1 SMP Sat Aug 15 18:09:19 UTC 2009 x86_64 GNU/Linux