Коллеги, а как можно предложить НЛО создать хаб «Здоровье» или «Спорт»?
По мне так вопрос уже назрел…
Судя по линкам в статье автора подобная тематика сейчас лежит в Чулане, Apple, Смартфоны и коммуникаторы…
Думаю, что без пульсометра мне было бы сложнее бегать. Пульсометр помогает не_брать завышенный темп, который чувтсвуется только через несколько минут стабильного равномерного бега, когда уже «вдруг» начинаешь задыхаться…
ИМХО, у Polar почти все функции — это виртуальные попугаи с маркетинговыми названиями… алгоритмизация на уровне нескольких else if с параметрами ЧССначальная, ЧССтекущая и ЧССмаксимальная_возрастная…
Итого минусы:
— невозможность синхронизации с компом (для данной модели)
— субъективно завышенная стоимость (для всех подобных решений)
Плюсы:
— неожиданно порадовала функция Own Zone, по мне так достаточно неплохо оценивает мое текущее состояние перед забегом (выспался/не выспался, бодряк/слабость и т.д.)…
Пользуюсь Polar RS100. При заказе лохонулся: кто же знал, что функция «Uplink: Прием и передача данных с монитора на компьютер» ограничена возможностью загрузки логотипа в верхнюю строку экрана пульсометра…
А вообще, субъективно считаю, что стоимость данных устройств очень сильно завышена.
Жду не дождусь, когда на китайской барахолке можно будет по адекватной цене купить нагрудный bluetooth-датчик+часы c программируемым контроллером внутри. Ибо считаю не совсем правильным просить за подобное серийно-изготавливаемое устройство 400-500$
У нас в парке их (15шки) кто-то догадался в синий цвет покрасить — типа в жетоны превратили.
Мы с друзьями разбили 5 или 6 копилок… но играли не долго — нас пропалили… и пожаловались нашим родителям))))))
После этого делали хитрее — покупали 1 жетон, а играли 4-5 игр… покрасить 15шки в тот же цвет, почему-то не получилось…
Думаю, что в случае катакомб, пещер и т.п. на первый план выйдет проблема связи, что существенно затруднит применение подобного решения… Радиоволны упрямо не хотят распространяться под землей…
Разве что, как вариант, группа при движении вкглубь будет оставлять за собой приемопередатчики(wi-fi?) но тогда любой обвал м/у группой и базой — лишит их связи и будет иметь много неприятных последствий…
После долгой жизни с bacula поняли, что она для нас слишком большая. Перешли на backuppc. Очень удобная альтернатива самописным скриптам, с веб-интерфейсом (что особенно удобно при восстановлении отдельных файлов).
Полностью согласен.
Только вот количество плееров «плохого тона» похоже зашкаливает. Очень долго искал бесплатную замену ломаному винампу, виндовый плеер не устраивает абсолютно ибо тормоз, а вот aimp — откровенно порадовал. У меня девушке в нем особенно нравится каталог онлайн радиостанций — теперь дома обычное радио не играет. Но это все оффтоп лирика…
Разница в использовании недокументированных возможностей. Речь вот о чем:
Присутствуй в скриптах обработка параметра PEER в файлах ifcfg-* я бы с радостью его использовал. Ну, например, так:
В этом случае шаманство с if-up.d было бы действительно излишним, и я был бы в этом случае почти полностью уверен, что после yum update сохраниться обратная совместимость и новая версия ifup-eth корректно обработает данные настройки.
В вашем же случае, есть хоть небольшая, но вероятность того, что после апдейта параметр
SCOPE=«peer 192.168.0.1»
новой версией ifup-eth так, как мы хотим, обработан не будет. Потому что параметр scope команды ip не может иметь значение «peer 192.168.0.1». И параметр peer команды ip не является подпараметром параметра scope (Но они оба являются подпараметрами параметра IFADDR).
IFADDR := ПРЕФИКС | ADDR peer ПРЕФИКС [ broadcast АДРЕС ] [ anycast АДРЕС ] [ label СТРОКА ] [ scope SCOPE-ID ]
SCOPE-ID := [ host | link | global | ЧИСЛО ]
Именно поэтому, мне кажется, что используя вариант с if-up.d (или его аналогом) мы получим более стабильную систему. Ну а админу — да, придется потратить дополнительно пару секунд на то, чтобы просмотреть еще один файл.
Надеюсь, что у меня получилось пояснить свою точку зрения.
Команды ip — очень удобное средство.
«чтоб настройки хранились там где им положено» — да я только за!
вот только использование отсутствия проверки параметра SCOPE для того, чтобы вставить другой параметр (peer) со значением этого другого параметра — считаю неразумным. Как только в скрипте появится данная проверка (параметра scope, благо он задокументирован) — это сразу проявится. Способ же предложенный мной не использует никаких назадокументированных возможностей скрипта. Более того, опирается на статью из RH KB. При этом все настройки продолжают хранится в /etc/sysconfig/network-scripts/
Именно там, где их и будут искать.
А по поводу примера использвоания ETHTOOL_OPTS — ничего против не имею. В данном случае, имя параметра и его назначение вполне соотносится со значением ему присвоенным.
Вас послушать, так за появление в федоре каталогов ifup.d и ifdown.d вообще надо на костре сжечь. Мой способ просто реализует их функционал. Они ведь тоже служат для выполнения отдельных команд после поднятия интерфейса.
И я действительно считаю, что полная команда, прописанная в файле лежащем, к примеру, в ifup.d гораздо удобнее, чем подстановака одного параметра вместо другого, опирающаяся на отсуствии проверки этого другого параметра скриптом. Как-то очевиднее это, что ли…
Отсуствия у себя знаний в определенных областях я не стесняюсь. Вот только ваша категоричная вера в собственную исключительную правоту вызывает у меня, как минимум. удивление. Я готов с радостью увеличить уровень своей компетентности в данном вопросе. Но ваши доводы не кажутся мне достаточными, чтобы назвать ваш способ решения задачи единственно-верным, а мой — предать огню)) Оценивать же чью-то компетентность только на основании того, разделяет ли человек мое мнение в определенном (достаточно узком) вопросе или нет — я бы не стал. Мне кажется, что тут вы перегибаете палку.
По поводу же хамства — ни в коем случае не собирался Вас задеть.
На практике не проверял — сделаю это в понедельник (не люблю в ночь на субботу ковырять настройки интерфейса у работающего сервера… чревато....)))) Пока просто скрипты почитал
SCOPE=«peer 192.168.0.1» — это хак)))
И исключительно по принципу «грязный хак против долгого гемора»
Причем откровенный… Ну где же тут идеология RH?.. Ведь стоит им в скрипте организовать проверку SCOPE по возможным значениям (хотя бы на том уровне, на котором это организовано для параметров маршрутизации) — и работа сети после апдейта нарушится.
Отвечаю по пунктам)
1. Да, к debian-подобным привык, есть такое. Сейчас вот с rh-подобными разбираюсь.
2. пример с mtu взят из Red Hat Knowledgebase DOC-8695 (!) Но умоляю Вас сильно не пинать Red Hat, они все же многое сделали для Linux и Open Source сообщества вцелом) Да и статья в kbase писалась в далеком декабре 2004го, может за 5 лет, как раз и добавили параметр для задания MTU
3. Ни в коем случае не собираюсь ругать тот или иной дистриб. Мотивы, по которым писалась моя заметка — в первых двух ее абзацах.
Если вдаваться в подробности, то изначальная цель была другой — заставить весь трафик данного хоста (даже локальный — т.е. в пределах его подсети) ходить через gateway. Сам знаю, что задача несколько странная. Так как перелопатив весь каталог network-scripts я не нашел возможности удаления/изменения маршрута для родной подсети, создаваемого по-умолчанию — пришлось работать через запускаемый скрипт.
В случае, если вы ткнете меня в способ решения данной задачи не выходя за пределы идеологии RH — буду очень благодарен.
По мне так вопрос уже назрел…
Судя по линкам в статье автора подобная тематика сейчас лежит в Чулане, Apple, Смартфоны и коммуникаторы…
При этом самое дешевое решение — тот же RS 100
— невозможность синхронизации с компом (для данной модели)
— субъективно завышенная стоимость (для всех подобных решений)
Плюсы:
— неожиданно порадовала функция Own Zone, по мне так достаточно неплохо оценивает мое текущее состояние перед забегом (выспался/не выспался, бодряк/слабость и т.д.)…
А вообще, субъективно считаю, что стоимость данных устройств очень сильно завышена.
Жду не дождусь, когда на китайской барахолке можно будет по адекватной цене купить нагрудный bluetooth-датчик+часы c программируемым контроллером внутри. Ибо считаю не совсем правильным просить за подобное серийно-изготавливаемое устройство 400-500$
Мы с друзьями разбили 5 или 6 копилок… но играли не долго — нас пропалили… и пожаловались нашим родителям))))))
После этого делали хитрее — покупали 1 жетон, а играли 4-5 игр… покрасить 15шки в тот же цвет, почему-то не получилось…
Разве что, как вариант, группа при движении вкглубь будет оставлять за собой приемопередатчики(wi-fi?) но тогда любой обвал м/у группой и базой — лишит их связи и будет иметь много неприятных последствий…
Только вот количество плееров «плохого тона» похоже зашкаливает. Очень долго искал бесплатную замену ломаному винампу, виндовый плеер не устраивает абсолютно ибо тормоз, а вот aimp — откровенно порадовал. У меня девушке в нем особенно нравится каталог онлайн радиостанций — теперь дома обычное радио не играет. Но это все
оффтоплирика…Присутствуй в скриптах обработка параметра PEER в файлах ifcfg-* я бы с радостью его использовал. Ну, например, так:
fcfg-eth0:
DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.0.255
HWADDR=40:61:86:2b:86:fd
IPADDR=192.168.0.15
NETMASK=255.255.255.255
PEER=192.168.0.1
В этом случае шаманство с if-up.d было бы действительно излишним, и я был бы в этом случае почти полностью уверен, что после yum update сохраниться обратная совместимость и новая версия ifup-eth корректно обработает данные настройки.
В вашем же случае, есть хоть небольшая, но вероятность того, что после апдейта параметр
SCOPE=«peer 192.168.0.1»
новой версией ifup-eth так, как мы хотим, обработан не будет. Потому что параметр scope команды ip не может иметь значение «peer 192.168.0.1». И параметр peer команды ip не является подпараметром параметра scope (Но они оба являются подпараметрами параметра IFADDR).
IFADDR := ПРЕФИКС | ADDR peer ПРЕФИКС [ broadcast АДРЕС ] [ anycast АДРЕС ] [ label СТРОКА ] [ scope SCOPE-ID ]
SCOPE-ID := [ host | link | global | ЧИСЛО ]
Именно поэтому, мне кажется, что используя вариант с if-up.d (или его аналогом) мы получим более стабильную систему. Ну а админу — да, придется потратить дополнительно пару секунд на то, чтобы просмотреть еще один файл.
Надеюсь, что у меня получилось пояснить свою точку зрения.
«чтоб настройки хранились там где им положено» — да я только за!
вот только использование отсутствия проверки параметра SCOPE для того, чтобы вставить другой параметр (peer) со значением этого другого параметра — считаю неразумным. Как только в скрипте появится данная проверка (параметра scope, благо он задокументирован) — это сразу проявится. Способ же предложенный мной не использует никаких назадокументированных возможностей скрипта. Более того, опирается на статью из RH KB. При этом все настройки продолжают хранится в /etc/sysconfig/network-scripts/
Именно там, где их и будут искать.
А по поводу примера использвоания ETHTOOL_OPTS — ничего против не имею. В данном случае, имя параметра и его назначение вполне соотносится со значением ему присвоенным.
Вас послушать, так за появление в федоре каталогов ifup.d и ifdown.d вообще надо на костре сжечь. Мой способ просто реализует их функционал. Они ведь тоже служат для выполнения отдельных команд после поднятия интерфейса.
И я действительно считаю, что полная команда, прописанная в файле лежащем, к примеру, в ifup.d гораздо удобнее, чем подстановака одного параметра вместо другого, опирающаяся на отсуствии проверки этого другого параметра скриптом. Как-то очевиднее это, что ли…
Отсуствия у себя знаний в определенных областях я не стесняюсь. Вот только ваша категоричная вера в собственную исключительную правоту вызывает у меня, как минимум. удивление. Я готов с радостью увеличить уровень своей компетентности в данном вопросе. Но ваши доводы не кажутся мне достаточными, чтобы назвать ваш способ решения задачи единственно-верным, а мой — предать огню)) Оценивать же чью-то компетентность только на основании того, разделяет ли человек мое мнение в определенном (достаточно узком) вопросе или нет — я бы не стал. Мне кажется, что тут вы перегибаете палку.
По поводу же хамства — ни в коем случае не собирался Вас задеть.
SCOPE=«peer 192.168.0.1» — это хак)))
И исключительно по принципу «грязный хак против долгого гемора»
Причем откровенный… Ну где же тут идеология RH?.. Ведь стоит им в скрипте организовать проверку SCOPE по возможным значениям (хотя бы на том уровне, на котором это организовано для параметров маршрутизации) — и работа сети после апдейта нарушится.
1. Да, к debian-подобным привык, есть такое. Сейчас вот с rh-подобными разбираюсь.
2. пример с mtu взят из Red Hat Knowledgebase DOC-8695 (!)
Но умоляю Вас сильно не пинать Red Hat, они все же многое сделали для Linux и Open Source сообщества вцелом) Да и статья в kbase писалась в далеком декабре 2004го, может за 5 лет, как раз и добавили параметр для задания MTU3. Ни в коем случае не собираюсь ругать тот или иной дистриб. Мотивы, по которым писалась моя заметка — в первых двух ее абзацах.
Если вдаваться в подробности, то изначальная цель была другой — заставить весь трафик данного хоста (даже локальный — т.е. в пределах его подсети) ходить через gateway. Сам знаю, что задача несколько странная. Так как перелопатив весь каталог network-scripts я не нашел возможности удаления/изменения маршрута для родной подсети, создаваемого по-умолчанию — пришлось работать через запускаемый скрипт.
В случае, если вы ткнете меня в способ решения данной задачи не выходя за пределы идеологии RH — буду очень благодарен.
но не вижу в этом ничего для себя страшного.
вот адрес отправки с сайта мтс
http://www.mts.ru/messaging/sendsms/