Это может быть следствием чего-либо. Например один, имея значительное количество платных приложений на аккаунте, прекратил пользоваться яблочными устройствами, а другой использует учетку первого, чтоб не покупать. Удобно, когда семейная группа с общими покупками в силу каких-либо причин не устраивает. Т.е. общее/совместное использование или "наследство".
В моем случае объединения требуют три аккаунта: 1 был создан, когда для российского региона не поддерживались яблочные аккаунты и позже был перенесен в российский регион через техподдержку для предоставления покупок семейной группе, 2 и 3 случились во время запуска icloud с возможностью использования своей почты (учетка mobileme разделилась на две - одна mobileme+icloud и вторая со сторонним адресом-доменом, пока спохватился - уже висели покупки на обеих). До сегодняшнего дня все решалось через семейную группу, но теперь можно избавиться от старых учетных записей и хранить все на одной.
При переходе с 0.3 на 0.4 отказались от встраивания маршрутизации, так что теперь Yggdrasil с поддержкой CKR ведет отдельно один из разработчиков: yggdrasilckr от Alexander Neil, плюс еще другие форки с CKR появились.
"Свобода одного заканчивается там, где начинается свобода другого". Соответственно, "несвобода", если рассматривать ее именно на едином уровне взаимодействия, а не как инструмент давления сверху вниз, - это еще и безопасность от применения к себе "свободы другого". Крайние позиции недостижимы, а промежуточные всегда будут в ущерб одним за счет пользы другим.
Только имется нюансик: на магистральном уровне уровне широковещалки могут блокировать/фильтровать, а используемые публичные пиры-ретрансляторы для mesh могут внезапно оказаться "недоверенными".
Маскировка хороша, пока по туннелю нет серьезной нагрузки и она не дает поведенческой сигнатуры. Для одиночных пользователей еще норм, для локалки или массово - в лучшем случае скорость зарежут...
Плюс всякие заморочки, вроде "отжатия" ICANN-ом у сообщества зон OpenNIC или, скажем, "развод и раздел имущества" в ущерб развитию единого общего проекта из-за расхождения по cryptokey routing у авторов Yggdrasil и тп.
Работа в задачах яндекс-календаря видна: уже научились делать привязанные к дате задачи, теперь, хорошо б, научить повторяющиеся. А то приходится все задачи формата task пихать в календарь в формате cal - там хотя бы можно повторы базовые использовать, хоть нельзя отмечать выполненное и не хватает гибкости (например вместо одного ежемесячного напоминания "за 2 дня до окончания месяца" приходится создавать 12 привязанных к конкретному числу ежегодных на каждый месяц)
Ой не факт: не всякой организации с ее лимитированным каналом по тарифу для юр-лиц захочется пропускать через себя весь домашний трафик сотрудников, а push/pull маршруты уже не всякое оборудование умеет.
Это может быть следствием чего-либо. Например один, имея значительное количество платных приложений на аккаунте, прекратил пользоваться яблочными устройствами, а другой использует учетку первого, чтоб не покупать. Удобно, когда семейная группа с общими покупками в силу каких-либо причин не устраивает. Т.е. общее/совместное использование или "наследство".
В моем случае объединения требуют три аккаунта: 1 был создан, когда для российского региона не поддерживались яблочные аккаунты и позже был перенесен в российский регион через техподдержку для предоставления покупок семейной группе, 2 и 3 случились во время запуска icloud с возможностью использования своей почты (учетка mobileme разделилась на две - одна mobileme+icloud и вторая со сторонним адресом-доменом, пока спохватился - уже висели покупки на обеих). До сегодняшнего дня все решалось через семейную группу, но теперь можно избавиться от старых учетных записей и хранить все на одной.
При переходе с 0.3 на 0.4 отказались от встраивания маршрутизации, так что теперь Yggdrasil с поддержкой CKR ведет отдельно один из разработчиков: yggdrasilckr от Alexander Neil, плюс еще другие форки с CKR появились.
"Свобода одного заканчивается там, где начинается свобода другого". Соответственно, "несвобода", если рассматривать ее именно на едином уровне взаимодействия, а не как инструмент давления сверху вниз, - это еще и безопасность от применения к себе "свободы другого". Крайние позиции недостижимы, а промежуточные всегда будут в ущерб одним за счет пользы другим.
Только имется нюансик: на магистральном уровне уровне широковещалки могут блокировать/фильтровать, а используемые публичные пиры-ретрансляторы для mesh могут внезапно оказаться "недоверенными".
Маскировка хороша, пока по туннелю нет серьезной нагрузки и она не дает поведенческой сигнатуры. Для одиночных пользователей еще норм, для локалки или массово - в лучшем случае скорость зарежут...
Плюс всякие заморочки, вроде "отжатия" ICANN-ом у сообщества зон OpenNIC или, скажем, "развод и раздел имущества" в ущерб развитию единого общего проекта из-за расхождения по cryptokey routing у авторов Yggdrasil и тп.
Работа в задачах яндекс-календаря видна: уже научились делать привязанные к дате задачи, теперь, хорошо б, научить повторяющиеся. А то приходится все задачи формата task пихать в календарь в формате cal - там хотя бы можно повторы базовые использовать, хоть нельзя отмечать выполненное и не хватает гибкости (например вместо одного ежемесячного напоминания "за 2 дня до окончания месяца" приходится создавать 12 привязанных к конкретному числу ежегодных на каждый месяц)
https://nic.ru/whois/ чем был плох?
Опубликовались только в гугл и яблосторах. Они хуавеевкий, рустор, и нашстор не осилили, а вы от них знание буквы ё ожидаете.
Ой не факт: не всякой организации с ее лимитированным каналом по тарифу для юр-лиц захочется пропускать через себя весь домашний трафик сотрудников, а push/pull маршруты уже не всякое оборудование умеет.