Пересобираем полученный SRPM под другую платформу: mock -r epel-x86_64 --rebuild /path/to/file.src.rpm
Спеку конечно писать нужно, но зато никаких проблем с лишними пакетами в живой системе или нехваткой зависимостей — все делается автоматически в chroot — удобно и чисто.
Каждый щелчок языка создает звуковые волны. Эти волны отражаются от поверхности окружающих предметов и отдаются у меня в ушах слабым эхом. Мой мозг преобразует эхо-сигналы в динамические образы. Я как бы разговариваю с окружающим миром.
Просто поразительно какие ресурсы скрыты в нашем организме.
Да, согласен, протупил. Нельзя с утра без кофе :) Пока не могу придумать изящного алгоритма, а без него — все равно два сравнения и тогда все равно, похоже, какой адрес будет броадкастом. А единицы взяты из езернет наследия.
Отсылка в книгу не совсем верная. Цитата из книги:
Unfortunately, an early release of TCP/IP code that accompanied Berkeley UNIX incorrectly used all zeroes for broadcast. Because the error stil survives, TCP/IP software often includes an option that allows a site to use all zeroes for directed broadcast.
И все это относится к этапу classful addressing scheme — когда нельзя было задать маску /23 или /9, а были только фиксированные /8, /16 и /24. На том этапе не нужна была и маска сети как таковая, так как класс сети (и маску соотв.) можно было определить по первым битам адреса (0... - /8, 10... - /16, 110... - /24). В том случае броадкастом и адресом сети могло быть что угодно, но согласованное между всеми заинтересованными лицами.
Но когда появилась идея CIDR, т.е. возможность «резать» адресное пространство в практически произвольных пропорциях — появилась необходимость в маске и правильном броадкасте. Поэтому уже сделать маску сети с единицами, а броадкаст нулями не выйдет из-за того что броадкаст будет одинаковым для нескольких сетей.
В принципе, этой же цитатой можно объяснить и почему хосту нельзя назначить адрес сети — так как существовали бажные реализации, которые могли интерпретировать такой адрес как броадкаст и пакет был бы отправлен не одному адресату, а всей сети.
Все из-за той же простоты и скорости. Если пришел пакет с dstip, то проверить предназначен ли он нам достаточно следующего условия: dstip & myip == myip
Это условие будет правдой и в случае если dstip == myip и если dstip будет броадкаст адресом.
Можно было бы использовать для него адрес сети.
Пока сети были classfull — да, вполне можно было попробовать. Но вы попробуйте отличить сеть 192.168.1.0/24 и 192.168.1.0/25 — адрес сети у них будет одинаковый, а в IP заголовке передается только один адрес (без маски). Поэтому используется броадкаст — так как он различается в случае classless сетей :)
Для чего нужен адрес сети? Почему его нельзя назначить хосту?
Для того чтобы быстро определить принадлежность IP данной сети: ipaddr & netmask == netaddr
Чем проще метод определения принадлежности — тем проще (и быстрее) маршрутизация
Я не бухгалтер — просто исследовал тему перед тем как открывать себе СПД. На общей системе ЕСВ считается от дохода (на упрощенной, от минимальной ЗП) соотв. если нет дохода, то платить ничего не нужно. И там не все так просто — на общей системе ЕСВ платится авансом с дохода за предыдущий год, а потом доплачивается (или получается?!) разница по результатам текущего года. Но если переходишь с упрощенной системы, то доходов за предыдущий год нет (в общей системе) — то и платить ничего не нужно, и все отчеты сдаются нулевые. Вот из моих закладок ФЛП на общей системе налогообложения
Что нужно для перехода — это нужно в налоговой узнавать, по-моему отсутствие долгов и заявление — со следующего квартала на новой системе налогообложения. Но вот переходить на упрощенную систему можно не чаще чем один раз за календарный год (Налоговый кодекс, статьи 291.3, 298)
Вторая группа может работать только с юриками плательщиками единого налога, а это, как Вы понимаете, исключительно резиденты Украины (ну или зарегистрированные в Украине предприятия/предприниматели). Для ВЭД небходимо хотя бы третью группу — они могут работать с кем угодно (при наличии договоров/контрактов естественно).
Вот немного опыта описано: Работа с иностранными заказчиками. Ведение ВЭД.
Сорри, не заметил Ваш спор ниже в коментариях — полностью поддеживаю. ЗЫ. Спасибо за продукт — даже бесплатная версия помогает контролировать бухгалтеров и сроки.
Да, я упомянул про трудовые отношения. Если смотреть с точки зрения IT — где «сотрудники» сидят в офисе своего «работодателя» — то трудовые отношения налицо, поэтому все фирмы пытаются учить своих «сотрудников» говорить «правильные слова» (мол я зашел только проект сдать). Но это смешно когда видишь фирму 100+ человек и все «случайно зашли».
Если переработать бизнес-модель — когда люди работают дома или в коворкинге, т.е. превращаются во фрилансеров — это уже вполне законная схема субподряда — но далеко не всякий работодатель на такое согласится.
По такой схеме, кстати, сейчас работают большинство такси и маршруток — когда фирма обеспечивает диспетчеризацию, а водители заключают контракт на перевозку людей на личном автотранспорте.
Всех сотрудников компании оформляем, как СПД, и их зарплату выплачиваем в качестве оплаты за услуги по договору,… и полученная зарплата будет… абсолютно белая и законная. Кроме этого, сотрудникам будет идти официальный пенсионный стаж.
При такой схеме стоит быть очень внимательными как со стороны сотрудников (вернее субподрядчиков): пенсионный стаж будет идти с минимальной зарплаты, т.е. такой же как и с серой ЗП (когда по трудовой платится минималка, остальное в конверте); никаких социальных гарантий, т.е. оплата больничных и отпускных исключительно как акт доброй воли заказчика; обычно местом осуществления деятельности у СПД является его домашний адрес, поэтому при работе в офисе следует оформлять договора аренды на помещение и офисную технику, иначе это может быть расценено как получение прибыли/помощи (вы пользуетесь компом/офисом бесплатно но извлекаете из этого прибыль) налоговой, со всеми вытекающими штафами.
Так и стороны заказчика: регистрировать виды деятельности связанные также с арендой; проводить ликбез с «сотрудниками» про то, что они субподрядчики и вообще зашли в офис случайно когда там оказалась налоговая; забыть слова работодатель и сотрудник, так как это может быть квалифицировано как скрытые трудовые отношения и привести к штрафам; проблемы с испытательным сроком (не каждому же СПД на испыталку оформлять, поэтому налом, а его где-то взять нужно, а можно раз в квартал как написано в статье).
Хоть это и популярный законный метод избежать налогов для предприятия — налоговая не очень хорошо относится к такому методу уклонения от налогов.
После очередного обновления centos, мы обнаружили, что разработчик pacemaker перестал поддерживать репозиторий для данной ОС, а в официальных репозиториях была сборка, подразумевающая совершенно другую конфигурацию (cman вместо corosync).
В шестой версии никто ничего не выпиливал. RedHat сами активно смотрят на pacemaker + corosync и пилят эту сборку в Fedora, но пилят для нового corosync 2.x (в rhel/centos 6 только 1.x).
После крайнего обновления pacemaker в шестой ветке от туда выкинули crm шелл (в пользу нового pcs, который же сами и пилят). И добавили варнингов что мол связка pacemaker + corosync 1.х (pacemaker как плагин к corosync) уже устарела и скоро будет удалена — пользуйтесь плагином для cman. Таким образом достаточно установить только cman, corosync, pacemaker и оно снова заработает, даже конфиги pacemaker'a не нужно править — сам подтянет старые конфигурации. Что поменяется — corosync будет подниматься как «плагин» cman (и pacemaker тоже) и конфигурить corosync теперь нужно в настройках cman. Ну и crmsh нужно будет установить от куда-то, если не охота pacemaker через xml настраивать :)
И идея, и реализация :) Идея — потому что один класс из статьи это уже вполне самодостаточный и универсальный код, который будет полезен всем. Написание велосипедов сверх этого кода — это уже требование каждого отдельного проекта. Поэтому полезность скрипта уменьшается только для проектов подобного плана. Да, не спорю, если у Вас регулярно возникают подобные задачи — то переиспользование кода это путь в светлое будущее :)
По реализации. Как написали выше — ну вообще не круто. Зачем мне бегать по трем файлам и искать где настраиваются сигналы, например? А они реально размазаны по всем трем файлам. То что сигналы относятся к демону Вы поняли и сделали соотв. метод в правильном месте, но реализация заполнения массива хендлеров — оторви и выбрось. Вместо всей этой вакханалии с кучей классов, сделайте декоратор, который будет обрабатывать хендлеры и подготавливать все необходимое для последующей настройки. Например:
from daemon import Daemon, signal
from signal import SIGTERM
class MyDaemon(Daemon):
def run(self):
pass
@signal(SIGTERM)
@staticmethod
def handler1(signum, frame):
pass
Да, Вам придется подумать как правильно и красиво это написать, но читабельность и переиспользуемость повысится на порядок — все будет в одном месте, будет видно что и как управляет демоном.
Про reacts4daemon можно написать практически тоже самое — почему что-то внешнее должно решать как ведет себя мой демон. Добавьте метод типа do_action() к демону — пусть он сам парсит что может делать, а что нет. Если кто-то захочет — то переопределит этот метод в своем HisDaemon. Получим минус несколько классов и плюс к читаемости и пониманию.
Статическая конфигурация? Зачем Вам писать столько строк кода, если Вы их все равно дублируете — внесите настройки в сам класс MyDaemon. Тогда у Вас останется один подключаемый файл (daemon.py с основным классом и декоратором) и один основной файл, который несет в себе конфигурацию. Взглянув на последний будут видны и настройки, и порядок выполенения кода/сигналов. И под себя нужно будет менять один основной файл, а не несколько как сейчас :)
Даже в пределах одного файла пересекаются несколько стилей именования переменных и методов — очень не удобно читать. Хоть бы стиль причесали раз код вместе соединили.
Вы все-таки перепутали HPC и HighLoad системы. Так как я слабо себе представляю суперкомпьютер который обрабатывает «150 хитов в секунду» — у него совсем другие задачи :) Что есть HPC (High Performance Computing) можете прочитать хотя бы в википедии (Supercomputer) у убедится что оно имеет очень мало общего с описанным выше.
Собираем SRPM:
mock -r epel-i686 --spec /path/to/file.spec --sources /path/to/sources/Пересобираем полученный SRPM под другую платформу:
mock -r epel-x86_64 --rebuild /path/to/file.src.rpmСпеку конечно писать нужно, но зато никаких проблем с лишними пакетами в живой системе или нехваткой зависимостей — все делается автоматически в chroot — удобно и чисто.
Например так: Человек – летучая мышь
Просто поразительно какие ресурсы скрыты в нашем организме.
И все это относится к этапу classful addressing scheme — когда нельзя было задать маску /23 или /9, а были только фиксированные /8, /16 и /24. На том этапе не нужна была и маска сети как таковая, так как класс сети (и маску соотв.) можно было определить по первым битам адреса (
0... - /8, 10... - /16, 110... - /24). В том случае броадкастом и адресом сети могло быть что угодно, но согласованное между всеми заинтересованными лицами.Но когда появилась идея CIDR, т.е. возможность «резать» адресное пространство в практически произвольных пропорциях — появилась необходимость в маске и правильном броадкасте. Поэтому уже сделать маску сети с единицами, а броадкаст нулями не выйдет из-за того что броадкаст будет одинаковым для нескольких сетей.
В принципе, этой же цитатой можно объяснить и почему хосту нельзя назначить адрес сети — так как существовали бажные реализации, которые могли интерпретировать такой адрес как броадкаст и пакет был бы отправлен не одному адресату, а всей сети.
Все из-за той же простоты и скорости. Если пришел пакет с
dstip, то проверить предназначен ли он нам достаточно следующего условия:dstip & myip == myipЭто условие будет правдой и в случае если
dstip == myipи еслиdstipбудет броадкаст адресом.Пока сети были classfull — да, вполне можно было попробовать. Но вы попробуйте отличить сеть 192.168.1.0/24 и 192.168.1.0/25 — адрес сети у них будет одинаковый, а в IP заголовке передается только один адрес (без маски). Поэтому используется броадкаст — так как он различается в случае classless сетей :)
Для того чтобы быстро определить принадлежность IP данной сети:
ipaddr & netmask == netaddrЧем проще метод определения принадлежности — тем проще (и быстрее) маршрутизация
Что нужно для перехода — это нужно в налоговой узнавать, по-моему отсутствие долгов и заявление — со следующего квартала на новой системе налогообложения. Но вот переходить на упрощенную систему можно не чаще чем один раз за календарный год (Налоговый кодекс, статьи 291.3, 298)
Вот немного опыта описано: Работа с иностранными заказчиками. Ведение ВЭД.
ЗЫ. Спасибо за продукт — даже бесплатная версия помогает контролировать бухгалтеров и сроки.
Если переработать бизнес-модель — когда люди работают дома или в коворкинге, т.е. превращаются во фрилансеров — это уже вполне законная схема субподряда — но далеко не всякий работодатель на такое согласится.
По такой схеме, кстати, сейчас работают большинство такси и маршруток — когда фирма обеспечивает диспетчеризацию, а водители заключают контракт на перевозку людей на личном автотранспорте.
При такой схеме стоит быть очень внимательными как со стороны сотрудников (вернее субподрядчиков): пенсионный стаж будет идти с минимальной зарплаты, т.е. такой же как и с серой ЗП (когда по трудовой платится минималка, остальное в конверте); никаких социальных гарантий, т.е. оплата больничных и отпускных исключительно как акт доброй воли заказчика; обычно местом осуществления деятельности у СПД является его домашний адрес, поэтому при работе в офисе следует оформлять договора аренды на помещение и офисную технику, иначе это может быть расценено как получение прибыли/помощи (вы пользуетесь компом/офисом бесплатно но извлекаете из этого прибыль) налоговой, со всеми вытекающими штафами.
Так и стороны заказчика: регистрировать виды деятельности связанные также с арендой; проводить ликбез с «сотрудниками» про то, что они субподрядчики и вообще зашли в офис случайно когда там оказалась налоговая; забыть слова работодатель и сотрудник, так как это может быть квалифицировано как скрытые трудовые отношения и привести к штрафам; проблемы с испытательным сроком (не каждому же СПД на испыталку оформлять, поэтому налом, а его где-то взять нужно, а можно раз в квартал как написано в статье).
Хоть это и популярный законный метод избежать налогов для предприятия — налоговая не очень хорошо относится к такому методу уклонения от налогов.
В шестой версии никто ничего не выпиливал. RedHat сами активно смотрят на pacemaker + corosync и пилят эту сборку в Fedora, но пилят для нового corosync 2.x (в rhel/centos 6 только 1.x).
После крайнего обновления pacemaker в шестой ветке от туда выкинули crm шелл (в пользу нового pcs, который же сами и пилят). И добавили варнингов что мол связка pacemaker + corosync 1.х (pacemaker как плагин к corosync) уже устарела и скоро будет удалена — пользуйтесь плагином для cman. Таким образом достаточно установить только cman, corosync, pacemaker и оно снова заработает, даже конфиги pacemaker'a не нужно править — сам подтянет старые конфигурации. Что поменяется — corosync будет подниматься как «плагин» cman (и pacemaker тоже) и конфигурить corosync теперь нужно в настройках cman. Ну и crmsh нужно будет установить от куда-то, если не охота pacemaker через xml настраивать :)
Что будет гораздо проще воспринимать :)
По реализации. Как написали выше — ну вообще не круто. Зачем мне бегать по трем файлам и искать где настраиваются сигналы, например? А они реально размазаны по всем трем файлам. То что сигналы относятся к демону Вы поняли и сделали соотв. метод в правильном месте, но реализация заполнения массива хендлеров — оторви и выбрось. Вместо всей этой вакханалии с кучей классов, сделайте декоратор, который будет обрабатывать хендлеры и подготавливать все необходимое для последующей настройки. Например:
Да, Вам придется подумать как правильно и красиво это написать, но читабельность и переиспользуемость повысится на порядок — все будет в одном месте, будет видно что и как управляет демоном.
Про reacts4daemon можно написать практически тоже самое — почему что-то внешнее должно решать как ведет себя мой демон. Добавьте метод типа do_action() к демону — пусть он сам парсит что может делать, а что нет. Если кто-то захочет — то переопределит этот метод в своем HisDaemon. Получим минус несколько классов и плюс к читаемости и пониманию.
Статическая конфигурация? Зачем Вам писать столько строк кода, если Вы их все равно дублируете — внесите настройки в сам класс MyDaemon. Тогда у Вас останется один подключаемый файл (daemon.py с основным классом и декоратором) и один основной файл, который несет в себе конфигурацию. Взглянув на последний будут видны и настройки, и порядок выполенения кода/сигналов. И под себя нужно будет менять один основной файл, а не несколько как сейчас :)
Даже в пределах одного файла пересекаются несколько стилей именования переменных и методов — очень не удобно читать. Хоть бы стиль причесали раз код вместе соединили.