Да, это всё про сходимость и предельные значения, т.е. диаграмма строится при длительных итерациях x. Ну, и, конечно, это всё так же и про степень погрешности, и про скорость сходимости.
Я так понимаю, что при а=3 среда, в которой происходит процесс может случайно распасться на 2 фракции изза флуктуаций.
Я бы сказал, что — это не 2 фракции, а два разных состояния среды. Недаром эти точки ещё называют фазовым переходом.
Некоторые области a=3+0 начинают жить по одному процессу, а другие a=3-0 живут по другому процессу.
Как оказалось, там (точка a=3) не всё так линейно и просто. Похоже, что граница имеет фрактальную структуру, и какой процесс протекает зависит не только от знака малого (-0 или +0), но и от самого этого малого, т.е. масштаба рассмотрения.
Конечно есть. "Пустые полосы" — суть зоны с периодической сходимостью. Например, при
обозначенном Вами коэффициенте a=3,8 (вернее, a≈3,83 или ещё более точно a=1+81/2) переменная x итерируется с периодом 3. Про это можно почитать в Википедии по указанной мной выше ссылке про логистического отображение.
Обратите внимание, что на бифуркационной диаграмме логистического отображения на прямой абсцисс откладывается коэффициент a, а на прямой ординат переменная x отображения: xn+1 = axn(1 — xn). В этом отображении только одна переменная — x, которая вычисляется сама из себя, т.е. каждый следующий x вычисляется через предыдущий x. Одно такое вычисление называется итерацией. При этом задаётся коэффициент a.
Задают значение коэффициента a (0 < a < 4), выбирают начальный x0 (0 < x < 1), итерируют значение переменной x и смотрят на сходимость.
На диаграмме видно, что при aот 0 до 1, x сходится к 0 (xn+1=xn=0), при aот 1 до 3, x сходится к какому-то одному значению (xn+1=xn), т.е. период сходимости x равен 1.
Самое интересное начинается при коэффициенте a в диапазоне от 3 до 4. В этом диапазоне при одних значениях коэффициента a переменная x может итерироваться с каким-то периодом (например, с периодом 3: xn -> xn+1 -> xn+2 -> xn+3 -> xn+4 -> xn+5 ->..., где xn=xn+3k, n=0,1,2..., k=1,2,3...), а при других значениях коэффициента a в этом диапазоне периодической сходимости x не возникает.
Значения коэффициента a, при которых происходит удвоение периода сходимости x, называют точками бифуркации (или ещё точками фазового перехода). Например, известной точкой бифуркации на бифуркационной диаграмме логистического отображения является a=3, в которой периодичность сходимости x сменяется с 1 на 2.
Под Александром Сарковским, представителем советской школы исследования динамических систем, в тексте, по-видимому, подразумевается Александр Николаевич Шарковский, автор указанного далее в тексте порядка Шарковского.
Патч руками в таком случае, наверное, тоже не тривиально будет применить, т.к. не будет однозначного соответствия между изменениями в патче и файлами конфига.
Глянул, TC патчи тоже версионирует. Т.е. появилось по одному патчу на настроенную сборку (где были изменения конфига), которые перезаписываются и коммитется. Если не важна история изменения конфига (а в случае, когда изменяется только одна переменная проекта TC, она наверное, не важна), можно и руками периодически применять текущие патчи.
На самом деле, у нас так и есть — переменная с версией приложения хранится в гите (правда, в отдельном проекте). Но также есть зеркальная ей переменная проекта в TC. Разработчику удобно видеть в gui TC текущую версию приложения. Плюс, переменная нужна для плагина, который в Слаку отправляет сообщения, а этот плагин оперирует только переменными проекта TC. От плагина можно отказаться, т.к. в Слаку легко слать сообщения и без плагина. Наверное, можно, пожертвовав удобством разработчиков, вообще отказаться от этой переменной проекта в TC. Тогда и патчей, связанных с изменениями этой переменной, не будет.
Да, согласен, надо не патч применять степом сборки, а сам конфиг изменять. Мне кажется, если одним степом изменить конфиг (значение переменной проекта TC), а следующим — саму переменную проекта TC, то патча не будет, т.к переменная будет соответствовать конфигу. Надо проверить.
Почитал доку про версионирование настроек. Правильно ли я понял, что любые изменения, сделанные в gui, придётся вручную вносить через патч, который TC сохранит в репе настроек? Выглядит не совсем удобным.
У нас один из шагов сборки сохраняет новое значение в переменную проекта (в ней хранится вычисляемый определённым образом номер версии приложения), и, соответсвенно, при следующей сборке уже используется это новое значение переменной (чтобы вычислить следующее значение и т.д.). Выглядит это как изменения внесённые через gui, т.е. в gui после сборки отображается новое значение переменной. Сборки запускаются автоматом при пуше в репу проекта.
Хотелось бы, чтобы TC репу настроек, соответственно, автоматом обновлял, при внесении изменений в gui. Т.к. в нашем случае вручную отслеживать поступление патчей сложно.
Понятно, что можно добавить ещё один степ сборки и накатывать автоматом этот патч. Но, во-первых, выглядит костыльно, а, во-вторых, пока не понятно, когда этот патч появляется в репе конфига.
Можете как-то прокомментировать или подсказать что-нибудь по этому поводу?
Эту статью видели. По сути это — тоже самое, что и подписка по стандартной ссылке на ics-файл, которую (ссылку) предоставляет Зимбра в диалоге расшаривания календаря. Правда, эта ссылка будет работать только если календарь расшарин.
Если расшаривать календарь в интернете не хочется, то этот ics-файл можно получить и без расшаривания календаря, пройдя аутентификацию по https.
Но Гугл не может это делать (автор статьи об этом тоже пишет), поэтому он предлагает поднять сторонний веб-сервер (или использовать веб-сервер Зимбры), который бы отдавал ics-файл Гуглу без аутентификации. А сам же этот ics-файл каким-либо образом (bash-скриптом или использовать API Зимбры) периодически обновлять для этого стороннего веб-сервера.
Но чем это тогда отличается от расшаривания календаря в интернете? По сути он также в свободном доступе. Конечно, можно сделать какую-то хитрую ссылку. Это первое.
Второе, какая разница как Гугл получит ics-файл, если он всё равно сам его не обновляет? Вернее, автор статьи пишет, что Гугл обновляет этот файл в течение 12-24 часов. Интересная информация, надо будет её проверить. Но для нас это всё равно слишком много. Нам нужно, чтобы календарь синхронизировался хотя бы каждые 5-10 минут.
И третье, в окружении Гугла добавить встречу в подписанный по ics-ссылке календарь невозможно. Но для нас это не критично.
Идеальным вариантом была бы возможность перенастроить в Зимбре календарь по умолчанию, куда приходят приглашения на встречи. Это бы сняло все проблемы (второе и третье).
По этой инструкции мы настраиваем в Зимбре наши gmail-календари. И всё работает прекрасно. Календари синхронизируются в обе стороны без проблем. На какой стороне мы бы не добавили встречу, она автоматически появляется на другой стороне.
Теперь обратная ситуация, нам нужно стандартный зимбровский Calendar интегрировать в Гугл, и чтобы тоже работала синхронизация в обе стороны. Так вот, тут календарь просто импортируется в Гугл, и никакая синхронизация уже не работает.
Для чего это нужно? У нас есть пользователи, которые больше работают с календарём Гугла (первые), а есть пользователи, которые больше работают с календарём Зимбры (вторые). Если вторые создают в Зимбре встречу и приглашают в эту встречу первых, то эта встреча появится у первых в стандартном зимбровском календаре Calendar, который в гугловские календари, которыми в основном пользуются первые, не сихронизируется. Т.е. первым приходится мониторить оба календаря: Зимбры и Гугла и в разных приложениях.
Но мы уже поняли, что это проблема не Зимбры, а Гугла, а также Микрософта и других облачных провайдеров. Все они только импортируют календари, а не интегрируют, т.е. у них нет механизма синхронизации календаря, который бы переодически обращался в Зимбру за обновлениями её календаря.
Тут есть два решения:
1. По аналогии с указанной Вами инструкцией, надо бы каким-то образом создать и настроить приложение в облаке Гугла для синхронизации календаря Зимбры в календари Гугла. Или аналогичное в облаке Микрософта. Было бы очень замечательно, если у Вас есть ссылка на такую инструкцию. Или Ваши специалисты или специалисты Зимбры написали бы такую инструкцию в базе знаний Зимбры.
2. Научить Зимбру указывать календарь, в который она будет добавлять приглашения на встречу. Это могла бы быть, например, настройка календаря по умолчанию. Сейчас эта настройка всего лишь предлагает календарь, куда добавить встречу владельцу календаря. Было бы замечательно, если бы эта настройка также указывала и календарь, куда приходят приглашения на встречу от других пользователей. Сейчас такие приглашения жёстко завязаны только на один календарь с именем Calendar. Или, может, такое поведение можно изменить в командной строке где-то в конфигурационных файлах Зимбры или базе данных?
1. Есть ли возможность календарь из Зимбры интегрировать в Гугл календари таким образом, чтобы работала синхронизация? Сейчас, добавляя в Гугл календарь подписку календаря из Зимбры по ссылке ICS, календарь не обновляется, т.е. он единожды сихронизируется и всё, больше никаких изменений не видно.
2. Другой вариант. Мы можем добавить в Зимбру календари из Гугла. Они нормально синхронизируются в обе стороны. Возможно ли каким-то образом настроить Зимбру, чтобы календарём по умолчанию, куда добавлялись бы приглашения на встручу, был другой календарь? Это бы сняло проблему из первого пункта.
права на все директории выставляются в 0770 — полный доступ владельца и его группы и полный запрет для всех остальных.
Есть же четвёртый бит доступа. Ставьте права на директорию в 2770 и не нужны будут хуки.
Копать в сторону setgid:
Бит setgid для каталога (chmod g+s) заставляет только новые каталоги и файлы, созданные в нём, наследовать ID группы этого каталога вместо ID группы пользователя, создавшего файл. Новые подкаталоги также наследуют бит setgid. Это позволяет создать общее рабочее пространство для группы без неудобств членам группы явно менять их текущую группу для создания новых файлов и каталогов.
На TP-Link (WR1043ND v1, прошивка 3.13.15 ) полёт для SSID — нормальный. Проверка идёт через JS, и символы Emoji проверку не проходят. Проверяет функция checkname() в центральном фрейме. Замена её на новую не помогла, т.к. судя по всему, js постоянно перегружается с роутера. Пришлось воспользоваться дебагером Хрома. Выставил брейкпоинт в этой функции и подменил значение на валидное (про дебагер в Хроме в этой статье можно почитать).
Вот, интересно получается, devops-евангелисты есть, а devops-инженеров нет.
Да, это всё про сходимость и предельные значения, т.е. диаграмма строится при длительных итерациях x. Ну, и, конечно, это всё так же и про степень погрешности, и про скорость сходимости.
Я бы сказал, что — это не 2 фракции, а два разных состояния среды. Недаром эти точки ещё называют фазовым переходом.
Как оказалось, там (точка a=3) не всё так линейно и просто. Похоже, что граница имеет фрактальную структуру, и какой процесс протекает зависит не только от знака малого (-0 или +0), но и от самого этого малого, т.е. масштаба рассмотрения.
Конечно есть. "Пустые полосы" — суть зоны с периодической сходимостью. Например, при
обозначенном Вами коэффициенте a=3,8 (вернее, a≈3,83 или ещё более точно a=1+81/2) переменная x итерируется с периодом 3. Про это можно почитать в Википедии по указанной мной выше ссылке про логистического отображение.
Вот, интересно получается, Бэкэндщик у Артёма есть, а Девопса — нет.
???
Обратите внимание, что на бифуркационной диаграмме логистического отображения на прямой абсцисс откладывается коэффициент a, а на прямой ординат переменная x отображения: xn+1 = a xn(1 — xn). В этом отображении только одна переменная — x, которая вычисляется сама из себя, т.е. каждый следующий x вычисляется через предыдущий x. Одно такое вычисление называется итерацией. При этом задаётся коэффициент a.
Задают значение коэффициента a (0 < a < 4), выбирают начальный x0 (0 < x < 1), итерируют значение переменной x и смотрят на сходимость.
На диаграмме видно, что при a от 0 до 1, x сходится к 0 (xn+1=xn=0), при a от 1 до 3, x сходится к какому-то одному значению (xn+1=xn), т.е. период сходимости x равен 1.
Самое интересное начинается при коэффициенте a в диапазоне от 3 до 4. В этом диапазоне при одних значениях коэффициента a переменная x может итерироваться с каким-то периодом (например, с периодом 3: xn -> xn+1 -> xn+2 -> xn+3 -> xn+4 -> xn+5 ->..., где xn=xn+3k, n=0,1,2..., k=1,2,3...), а при других значениях коэффициента a в этом диапазоне периодической сходимости x не возникает.
Значения коэффициента a, при которых происходит удвоение периода сходимости x, называют точками бифуркации (или ещё точками фазового перехода). Например, известной точкой бифуркации на бифуркационной диаграмме логистического отображения является a=3, в которой периодичность сходимости x сменяется с 1 на 2.
Глянул, TC патчи тоже версионирует. Т.е. появилось по одному патчу на настроенную сборку (где были изменения конфига), которые перезаписываются и коммитется. Если не важна история изменения конфига (а в случае, когда изменяется только одна переменная проекта TC, она наверное, не важна), можно и руками периодически применять текущие патчи.
На самом деле, у нас так и есть — переменная с версией приложения хранится в гите (правда, в отдельном проекте). Но также есть зеркальная ей переменная проекта в TC. Разработчику удобно видеть в gui TC текущую версию приложения. Плюс, переменная нужна для плагина, который в Слаку отправляет сообщения, а этот плагин оперирует только переменными проекта TC. От плагина можно отказаться, т.к. в Слаку легко слать сообщения и без плагина. Наверное, можно, пожертвовав удобством разработчиков, вообще отказаться от этой переменной проекта в TC. Тогда и патчей, связанных с изменениями этой переменной, не будет.
Да, согласен, надо не патч применять степом сборки, а сам конфиг изменять. Мне кажется, если одним степом изменить конфиг (значение переменной проекта TC), а следующим — саму переменную проекта TC, то патча не будет, т.к переменная будет соответствовать конфигу. Надо проверить.
У нас один из шагов сборки сохраняет новое значение в переменную проекта (в ней хранится вычисляемый определённым образом номер версии приложения), и, соответсвенно, при следующей сборке уже используется это новое значение переменной (чтобы вычислить следующее значение и т.д.). Выглядит это как изменения внесённые через gui, т.е. в gui после сборки отображается новое значение переменной. Сборки запускаются автоматом при пуше в репу проекта.
Хотелось бы, чтобы TC репу настроек, соответственно, автоматом обновлял, при внесении изменений в gui. Т.к. в нашем случае вручную отслеживать поступление патчей сложно.
Понятно, что можно добавить ещё один степ сборки и накатывать автоматом этот патч. Но, во-первых, выглядит костыльно, а, во-вторых, пока не понятно, когда этот патч появляется в репе конфига.
Можете как-то прокомментировать или подсказать что-нибудь по этому поводу?
Про версионирование настроек и security не знал. Спасибо за наводку!
Эту статью видели. По сути это — тоже самое, что и подписка по стандартной ссылке на ics-файл, которую (ссылку) предоставляет Зимбра в диалоге расшаривания календаря. Правда, эта ссылка будет работать только если календарь расшарин.
Если расшаривать календарь в интернете не хочется, то этот ics-файл можно получить и без расшаривания календаря, пройдя аутентификацию по https.
Но Гугл не может это делать (автор статьи об этом тоже пишет), поэтому он предлагает поднять сторонний веб-сервер (или использовать веб-сервер Зимбры), который бы отдавал ics-файл Гуглу без аутентификации. А сам же этот ics-файл каким-либо образом (bash-скриптом или использовать API Зимбры) периодически обновлять для этого стороннего веб-сервера.
Но чем это тогда отличается от расшаривания календаря в интернете? По сути он также в свободном доступе. Конечно, можно сделать какую-то хитрую ссылку. Это первое.
Второе, какая разница как Гугл получит ics-файл, если он всё равно сам его не обновляет? Вернее, автор статьи пишет, что Гугл обновляет этот файл в течение 12-24 часов. Интересная информация, надо будет её проверить. Но для нас это всё равно слишком много. Нам нужно, чтобы календарь синхронизировался хотя бы каждые 5-10 минут.
И третье, в окружении Гугла добавить встречу в подписанный по ics-ссылке календарь невозможно. Но для нас это не критично.
Идеальным вариантом была бы возможность перенастроить в Зимбре календарь по умолчанию, куда приходят приглашения на встречи. Это бы сняло все проблемы (второе и третье).
Спасибо за ответ, за Ваше желание помочь!
По этой инструкции мы настраиваем в Зимбре наши gmail-календари. И всё работает прекрасно. Календари синхронизируются в обе стороны без проблем. На какой стороне мы бы не добавили встречу, она автоматически появляется на другой стороне.
Теперь обратная ситуация, нам нужно стандартный зимбровский Calendar интегрировать в Гугл, и чтобы тоже работала синхронизация в обе стороны. Так вот, тут календарь просто импортируется в Гугл, и никакая синхронизация уже не работает.
Для чего это нужно? У нас есть пользователи, которые больше работают с календарём Гугла (первые), а есть пользователи, которые больше работают с календарём Зимбры (вторые). Если вторые создают в Зимбре встречу и приглашают в эту встречу первых, то эта встреча появится у первых в стандартном зимбровском календаре Calendar, который в гугловские календари, которыми в основном пользуются первые, не сихронизируется. Т.е. первым приходится мониторить оба календаря: Зимбры и Гугла и в разных приложениях.
Но мы уже поняли, что это проблема не Зимбры, а Гугла, а также Микрософта и других облачных провайдеров. Все они только импортируют календари, а не интегрируют, т.е. у них нет механизма синхронизации календаря, который бы переодически обращался в Зимбру за обновлениями её календаря.
Тут есть два решения:
1. По аналогии с указанной Вами инструкцией, надо бы каким-то образом создать и настроить приложение в облаке Гугла для синхронизации календаря Зимбры в календари Гугла. Или аналогичное в облаке Микрософта. Было бы очень замечательно, если у Вас есть ссылка на такую инструкцию. Или Ваши специалисты или специалисты Зимбры написали бы такую инструкцию в базе знаний Зимбры.
2. Научить Зимбру указывать календарь, в который она будет добавлять приглашения на встречу. Это могла бы быть, например, настройка календаря по умолчанию. Сейчас эта настройка всего лишь предлагает календарь, куда добавить встречу владельцу календаря. Было бы замечательно, если бы эта настройка также указывала и календарь, куда приходят приглашения на встречу от других пользователей. Сейчас такие приглашения жёстко завязаны только на один календарь с именем Calendar. Или, может, такое поведение можно изменить в командной строке где-то в конфигурационных файлах Зимбры или базе данных?
2. Другой вариант. Мы можем добавить в Зимбру календари из Гугла. Они нормально синхронизируются в обе стороны. Возможно ли каким-то образом настроить Зимбру, чтобы календарём по умолчанию, куда добавлялись бы приглашения на встручу, был другой календарь? Это бы сняло проблему из первого пункта.
Копать в сторону setgid:
Бит setgid для каталога (chmod g+s) заставляет только новые каталоги и файлы, созданные в нём, наследовать ID группы этого каталога вместо ID группы пользователя, создавшего файл. Новые подкаталоги также наследуют бит setgid. Это позволяет создать общее рабочее пространство для группы без неудобств членам группы явно менять их текущую группу для создания новых файлов и каталогов.
Расскажите, пожалуйста, поподробнее о приобретении Splunk. Что значит, продажи в России не производятся?