Я с Вами согласен в том, что полагаться на то, что мессенджер будет в приступе альтруизма хранить переписку и даже вложения "вечно" – сомнительная идея (хотя _пока что_ телеграм там делает, но гарантий никаких нет). И полностью поддерживаю необходимость резервного копирования истории. API для backup-ов был бы прямо очень кстати. Или хотя бы просто возможность легко экспортировать историю в тот же JSON. Кстати, я не смотрел, позволяет ли WhatsApp сделать что-нибудь подобное. Возможно, да, ведь им же нужно соблюдать GDPR. Но тут, опять же, не факт, что они всё хранят на серверах с учётом сквозного шифрования, а без "централизованного хранилища" процесс резервного копирования резко усложняется. Ещё, на мой взгляд, плюсик в копилку отсутствия шифрования по умолчанию.
Но в целом, если рассмотреть ситуацию отсутствия у пользователя регулярных backup-ов по правилу 3-2-1 с ZRAID-ами, магнитными кассетами и облаками, то я всё же остаюсь при своей позиции :) Ну и даже с резервным копированием делать его проще без сквозного шифрования.
Кстати, надо будет заморочиться резервными копиями наконец уже) Все семейные чаты в WhatsApp (у меня не было выбора :) ).
Да. Попробуйте потерять свой телефон. Я уже молчу о том, что WhatsApp – это невероятно плохое ПО. Вот я прямо сейчас проскроллил один из семейных чатов, и на маке я не вижу историю дальше 18 июня. Это как вообще? И это при том, что телефон мой – вот он, рядышком лежит, и там история есть (и даже её backup есть, нешифрованный, да, потому что сесурити у WhatsApp "на высоте"). Но и то не вся история, потому что часть картинок и аудиосообщений я загрузить уже не могу, месяц спустя. WhatsApp – невероятно, невероятно, невероятно плохая система.
Но оставим в стороне WhatsApp. Допустим, у нас есть нормальный мессенджер со сквозным шифрованием. Точно не Viber, но может быть Signal, не знаю, не пользовался. Некий гипотетический мессенджер. По определению, мы не можем хранить ключ от чата на сервере в открытом виде. То есть мы, по идее, могли бы хранить на сервере зашифрованную историю. И даже могли бы хранить шифрованный ключ от чата, полагаю. В этом случае утеря устройства не будет проблемой. Но пользователь должен иметь возможность расшифровать ключ, чтобы расшифровать историю. А значит, пользователь должен помнить пароль. Если пользователь потерял устройство и забыл пароль – дело дрянь. Например, решил вернуться в мессенджер после года отсутствия, посмотреть свои старые переписки.
Тут, конечно, можно сказать, что пользователь сам дурак, и, в целом, это правда. Но вот я за себя не могу на 100% поручиться, что я всегда на 100% не дурак. Мне гораздо-гораздо удобнее, чтобы не особо важная переписка была незашифрованной. Я логинюсь в любом месте и вижу всю свою историю, как оно и должно быть. Я забыл пароль – я восстанавливаю его, и всё хорошо. Я отдаю себе отчёт, что переписка хранится в открытом виде. При этом для ситуаций, которые требуют шифрования – я делаю два клика мышкой, и у меня шифрованный чат. Шифрованные чаты в Telegram, полагаю, можно было бы улучшить, но в целом главное – что обычные чаты не шифрованные.
Ну вот, то есть мы ещё и плюсы бэкапа не факт, что получим)) WhatsApp вообще поражает меня как ПО, за которым стоит многомиллиардная корпорация. На iOS backup-ы выполняются регулярно, но не знаю, насколько стабильно работает восстановление.
Бэкап – это не непонятное окно (по крайней мере, на iOS). Это "включено по умолчанию, и поди разберись, как выключить". Получаем все минусы сквозного шифрования и ноль приватности по умолчанию.
Сквозного шифрования по умолчанию быть не должно. Точнее, пусть все делают как хотят, конечно, но оставьте хоть один нормальный мессенджер.
@snakers4, на всякий случай дополню немного: объединив два Raid-1 по 2 Tb в Raid-0, Вы получите Raid-10 на 4 Tb, как Вы и ожидали.
Либо можете взять Raid-6, это тоже даст Вам 4 Tb. Работать будет медленнее, чем Raid-10, но зато Вы можете потерять любые два диска без потери данных. В случае с Raid-10 Вы можете потерять до 2 дисков, если они в разных Raid-1 массивах. Если накроются два диска в одном Raid-1 массиве, всему Raid-10 труба. Там довольно обширная тема с нюансами по resilvering-у, подбору числа дисков для оптимальной производительности и т.д., я сам разбираюсь довольно поверхностно, к сожалению :)
Ну и, конечно, не забывайте, что Raid – это не backup :)
Raid-1 из любого числа 2 Тб дисков даст 2 Тб, т.к. это просто зеркало. Насчёт 10 – я никогда не работал с mdadm и не знаю, как там устроено создание Raid-10, но Raid 10 – это просто Raid-0 массив из двух Raid-1 массивов. Так что, если у Вас есть два Raid-1, вы можете объединить их в Raid-0, и получите Raid-10.
mdadm отказался без видимых причин делать массив из 4 дисков почему-то. Точнее делает только на 2 терабайта, когда должен на 4.
А какой тип массива Вы создавали? Такое ощущение, что он просто сделал зеркало (Raid-1 на 4 диска с полным дублированием). А Вы, похоже, хотели либо Raid-6, либо Raid-10, судя по тому, что рассчитывали на 4 Тб пространства.
Сейчас они как раз не особо стагнируют. А вот во времена господства Intel мы лет на 10 застряли с приростом производительности от поколения к поколению процентов 5-10. И на 4-х ядрах в топовых моделях. Это продолжалось, пока AMD не выкатили Ryzen, дав Intel волшебного пинка.
Скажите, пожалуйста, можно ли использовать Swift Testing на старых версиях iOS? Ну то есть если target-ом выбран, например, симулятор с iOS 14, и deployment target приложения iOS 14, оно будет работать?
Выше в комментарии написали правильно – несколько лет назад предоставили API для докачки контента. Но, если я не путаю, этот контент отдельно тоже проходит ревью. Точнее, приложение проходит ревью вместе с контентом, просто контент во время установки не скачивается, а может быть загружен пользователем позднее.
Этот тред убивает меня. Нет противопоставления NVMe и SSD. То, что обычно называют NVMe – это SSD. Точнее, как правило, M.2 NVMe SSD.
Бывают M.2 SATA SSD. Бывают (относительно) большие U.2 NVMe SSD.
О, спасибо большое! :)
Я с Вами согласен в том, что полагаться на то, что мессенджер будет в приступе альтруизма хранить переписку и даже вложения "вечно" – сомнительная идея (хотя _пока что_ телеграм там делает, но гарантий никаких нет). И полностью поддерживаю необходимость резервного копирования истории. API для backup-ов был бы прямо очень кстати. Или хотя бы просто возможность легко экспортировать историю в тот же JSON. Кстати, я не смотрел, позволяет ли WhatsApp сделать что-нибудь подобное. Возможно, да, ведь им же нужно соблюдать GDPR. Но тут, опять же, не факт, что они всё хранят на серверах с учётом сквозного шифрования, а без "централизованного хранилища" процесс резервного копирования резко усложняется. Ещё, на мой взгляд, плюсик в копилку отсутствия шифрования по умолчанию.
Но в целом, если рассмотреть ситуацию отсутствия у пользователя регулярных backup-ов по правилу 3-2-1 с ZRAID-ами, магнитными кассетами и облаками, то я всё же остаюсь при своей позиции :) Ну и даже с резервным копированием делать его проще без сквозного шифрования.
Кстати, надо будет заморочиться резервными копиями наконец уже) Все семейные чаты в WhatsApp (у меня не было выбора :) ).
Да. Попробуйте потерять свой телефон. Я уже молчу о том, что WhatsApp – это невероятно плохое ПО. Вот я прямо сейчас проскроллил один из семейных чатов, и на маке я не вижу историю дальше 18 июня. Это как вообще? И это при том, что телефон мой – вот он, рядышком лежит, и там история есть (и даже её backup есть, нешифрованный, да, потому что сесурити у WhatsApp "на высоте"). Но и то не вся история, потому что часть картинок и аудиосообщений я загрузить уже не могу, месяц спустя. WhatsApp – невероятно, невероятно, невероятно плохая система.
Но оставим в стороне WhatsApp. Допустим, у нас есть нормальный мессенджер со сквозным шифрованием. Точно не Viber, но может быть Signal, не знаю, не пользовался. Некий гипотетический мессенджер. По определению, мы не можем хранить ключ от чата на сервере в открытом виде. То есть мы, по идее, могли бы хранить на сервере зашифрованную историю. И даже могли бы хранить шифрованный ключ от чата, полагаю. В этом случае утеря устройства не будет проблемой. Но пользователь должен иметь возможность расшифровать ключ, чтобы расшифровать историю. А значит, пользователь должен помнить пароль. Если пользователь потерял устройство и забыл пароль – дело дрянь. Например, решил вернуться в мессенджер после года отсутствия, посмотреть свои старые переписки.
Тут, конечно, можно сказать, что пользователь сам дурак, и, в целом, это правда. Но вот я за себя не могу на 100% поручиться, что я всегда на 100% не дурак. Мне гораздо-гораздо удобнее, чтобы не особо важная переписка была незашифрованной. Я логинюсь в любом месте и вижу всю свою историю, как оно и должно быть. Я забыл пароль – я восстанавливаю его, и всё хорошо. Я отдаю себе отчёт, что переписка хранится в открытом виде. При этом для ситуаций, которые требуют шифрования – я делаю два клика мышкой, и у меня шифрованный чат. Шифрованные чаты в Telegram, полагаю, можно было бы улучшить, но в целом главное – что обычные чаты не шифрованные.
Ну вот, то есть мы ещё и плюсы бэкапа не факт, что получим)) WhatsApp вообще поражает меня как ПО, за которым стоит многомиллиардная корпорация. На iOS backup-ы выполняются регулярно, но не знаю, насколько стабильно работает восстановление.
Ну так, полагаю, в коде клиента и есть? Если что, я это не "с наездом", просто по логике вещей он должен быть как раз там)
Бэкап – это не непонятное окно (по крайней мере, на iOS). Это "включено по умолчанию, и поди разберись, как выключить". Получаем все минусы сквозного шифрования и ноль приватности по умолчанию.
Сквозного шифрования по умолчанию быть не должно. Точнее, пусть все делают как хотят, конечно, но оставьте хоть один нормальный мессенджер.
@snakers4, на всякий случай дополню немного: объединив два Raid-1 по 2 Tb в Raid-0, Вы получите Raid-10 на 4 Tb, как Вы и ожидали.
Либо можете взять Raid-6, это тоже даст Вам 4 Tb. Работать будет медленнее, чем Raid-10, но зато Вы можете потерять любые два диска без потери данных. В случае с Raid-10 Вы можете потерять до 2 дисков, если они в разных Raid-1 массивах. Если накроются два диска в одном Raid-1 массиве, всему Raid-10 труба. Там довольно обширная тема с нюансами по resilvering-у, подбору числа дисков для оптимальной производительности и т.д., я сам разбираюсь довольно поверхностно, к сожалению :)
Ну и, конечно, не забывайте, что Raid – это не backup :)
Ну вот, остался один шаг :)
Raid-1 из любого числа 2 Тб дисков даст 2 Тб, т.к. это просто зеркало. Насчёт 10 – я никогда не работал с
mdadmи не знаю, как там устроено создание Raid-10, но Raid 10 – это просто Raid-0 массив из двух Raid-1 массивов. Так что, если у Вас есть два Raid-1, вы можете объединить их в Raid-0, и получите Raid-10.А какой тип массива Вы создавали? Такое ощущение, что он просто сделал зеркало (Raid-1 на 4 диска с полным дублированием). А Вы, похоже, хотели либо Raid-6, либо Raid-10, судя по тому, что рассчитывали на 4 Тб пространства.
Сейчас они как раз не особо стагнируют. А вот во времена господства Intel мы лет на 10 застряли с приростом производительности от поколения к поколению процентов 5-10. И на 4-х ядрах в топовых моделях. Это продолжалось, пока AMD не выкатили Ryzen, дав Intel волшебного пинка.
О, отлично! Значит, можно начинать пользоваться) Спасибо!
Скажите, пожалуйста, можно ли использовать Swift Testing на старых версиях iOS? Ну то есть если target-ом выбран, например, симулятор с iOS 14, и deployment target приложения iOS 14, оно будет работать?
Это да.
Выше в комментарии написали правильно – несколько лет назад предоставили API для докачки контента. Но, если я не путаю, этот контент отдельно тоже проходит ревью. Точнее, приложение проходит ревью вместе с контентом, просто контент во время установки не скачивается, а может быть загружен пользователем позднее.
А я думал "с тех пор, как научил" :)
Веки у девушки тоже не очень, когда закрываются.
У Вас что, до сих пор неблокирующийся монитор? Мда, а, казалось бы, технический ресурс...
Использовать можно только через API? Локально не развернуть?