Если нет поддержки VoLTE, то в 4G у вас не будет одновременно голоса и данных — если у вас "всё работает одновременно" — это просто потому что оно включено по умолчанию и ваш оператор поддерживает VoLTE. Или потому что у вас dual-SIM телефон.
Посмотрите в настройках VoLTE — если есть, может решить проблему с одновременным интернетом и звонками. Хотя может и не решить — если оператор этого не умеет, но попытка не пытка.
Зачем ждать? Видеосвязь с участием сотрудников HR/поддержки/безопасности и того кто знает человека в лицо, или на худой конец просто аудио но с теми кто знает голос сотрудника плюс контрольные вопросы, или перезвон на домаший номер, или… в общем есть много вариантов для того чтобы убедится что это тот кто говорит что он тот.
Если же "ой тут связь плохая" или "у меня камера поломалась" (а это уже как минимум "жёлтый флаг") — то ждать либо пока связь восстановится или камеру приведут в порядок, либо таки лично, потому что ущерб от отсутствия доступа сотрудника за два-три дня вряд-ли будет выше (или хотя бы отдалённо сравним) с потенциальной утечкой данных или доступом к сети кого-то чужого, не говоря уже о том что если "связь плохая" то чёрта с два он удалённо сможет работать.
диссиденты явно наносят урон по рекламному рынку в т.ч. Гугла и по заработку блогеров
Скорее всего этот ущерб в районе статистической погрешности. Подозреваю что большинство из тех кто пользуется адблоками с высокой вероятностью либо устойчивы к рекламе либо всё равно ничего не купят (в силу бюджета либо полного отсутствия интереса к конкретному товару/услуге) — соответственно, они вообще погоды не делают.
С другой стороны, нельзя прекращать борьбу с адблоками — иначе они точно появится у всех и тогда ущерб станет реальным, а пока баланс в пользу рекламодателей.
Речь про маленькие комании, разумеется. В случае с большими вопрос о взаимозаменяемости обычно не возникает (если процессы поставлены).
Хотя, если бы мне пришлось это делать в большой компании то принцип был бы простой — планы выполняются (это заметно по отчётам, обратной связи с клиентами и доходам) — пусть себе повышают (в пределах бюджета), но если пойдут косяки — то последствия будут соответствующими.
Разумеется, если команды не имеют доли от доходов (т.е. нет прямой заинтересованности в их повышении), контроль за расходами и доступностью/заменяемостью должен быть, но именно контроль а не поводок — обычно чистые управленцы недостаточно компетентны технически чтобы "прочухать" уровень человека.
gambit_fin Как минимум одна которую я знаю — уже 40 лет существует. Небольшая, но очень гордая со стабильным доходом — без роскошеств, но довольно достойным.
Если мне вдруг придётся ввести пароль в публичном месте — он будет сменен при первой же возможности, потому что нет никаких гарантий что на клавиатуру и экран не смотрит камера — а с камерой фокус "сложно запомнить" не пройдёт.
Ok, посчитаем. Допустим мы используем словарь из 10 тыс. слов, дата у нас 6 цифр а слов всего 5. Получаем 10000^5 * 10^6 = 10^27, т.е. 89 бит. И это я не считаю непонятно где стоящую пунктуацию, то факт что дата может содержать точки или тире а регистр у слов может быть разным, да и их взаимное расположение — тоже.
Так что там у нас с брутфорсом на 89 бит? А если это не простой SHA256 а PBKDF2 или bcrypt?
SATA 2.5" (CMR) либо медленные либо очень дорогие. Насчёт майнеров — не знаю как в РФ, а у нас (Германия) пока полно дисков на 6-18 гиг по ценам прошлого года (с которого они падали вплоть до апреля).
Зачем такие сложности? Нечто вроде "Aquamen Notorious" + набор цифр (например памятная дата кроме дат рождения/свадеб) + название любимой книги с точкой в конце — и вопрос решён — брутфосом это не перебрать (не зная структуры) и соответствует всем адским требованиям (разные регистры + цифры + спецсимвол). Можно в другом поряде, но смысл в том чтобы было несколько не связанных мнжду собой компонентов, каждый из которых легко запоминается или находится если вдруг забыт.
reServer позиционируется именно как сервер, а в NUC всего один сетевой порт и место для одного HDD (и то скорее всего 2.5") — про RAID и быстрые объёмные диски можно забыть, не говоря уже о том что он не расчитан на работу 24/7.
Как по мне, если расчитывать что он будет работать минимум три года (а скорее всего дольше) то эти $200+ — не такая большая разница. Будь такая штука доступна лет 5 назад — взял бы не раздумывая, а так пришлось брать Shuttle (потому что нужно было место для двух HDD).
Неправильно. Вероятность того что под наркозом изнасилуют очень мала (хотя известны случаи) по сравнению с вероятностью что любопытный ремонтник пошарится в данных на ремонтируемом устройстве, особенно если устройство не закрыто паролем/пином.
Вы бы отдали в ремонт телефон с данными которые можно использовать против вас (или нанести ущерб), не имея уверенности что сервису можно доверять? Я, к примеру, предпочёл бы его уничтожить.
В общем-то, отдавая в ремонт телефон с голыми (да и вообще любыми) фотками можно подумать о том что работники сервиса могут их увидеть. И не только фотки.
Видимо мы как-то иначе вариации считаем. В частности, почему в вашем примере нет 0011, 0101, 0110 и 0111? Должно ж 16 вариантов получится — если каждый "бит" это наличие условия для параметра или его отсутствие, параметров 4 и условие только одно.
3^n у меня получилось для случаев (parm = col), (parm <> col) и отсутствия параметра — т.е. три возможных варианта для каждого (вместо двух если бы было только "=").
Если я правильно вас понял, речь идёт о том чтобы в запросе иметь нечто вроде:
SELECT * FROM table
WHERE (:parm1 IS NULL OR (col1 = :parm1))
AND (:parm2 IS NULL OR (col2 = :parm2))
Выглядит конечно заманчиво, но есть нюанс (о котором я говорил раньше) — нет абсолютно никаких гарантий что сначала будет проверено условие "IS NULL" для параметра, т.е. сервер может впустую сравнивать все параметры (которые не указаны) с данными из таблицы. Да, в идеале оптимизатор должен это прочухать — но всё же гарантий нет.
И ещё момент — кроме условия "=" может быть "<>" — а вот это в один запрос впихнуть уже проблематично. Можно конечно как-то так:
SELECT * FROM table
WHERE (:parm1eq IS NOT NULL AND (col1 = :parm1eq))
OR (:parm2ne IS NOT NULL AND (col2 <> :parm2ne))
и вынести выбор параметров в приложение (передавая только один в зависимости от условия), но проблема с неопределенным порядком остается, да и в отличие от большинства "нормальных" ЯП в SQL нет "короткого замыкания" в логических операторах, плюс есть шанс что планировщик сойдёт с ума и план для "универсального" запроса может быть значительно дороже чем для узкоспециализированного.
Собственно, в сложных системах где запросы ещё могут использовать другие операторы (типа LIKE или BETWEEN) всё уже просто становится неподъёмно и сильно усложняет код — так что динамическая генерация самый простой способ, а в сочетании с кэшем и учётом того что вариантов (реально используемых) всё же не очень много это отлично работает.
Кроме собственно строки обычно кэшируется подготовленный запрос (prepared statement). Сборка строки может быть сравнительно недорогой, но вот prepare — может быть очень дорого, для этого и нужен кэш запросов.
Если нет поддержки VoLTE, то в 4G у вас не будет одновременно голоса и данных — если у вас "всё работает одновременно" — это просто потому что оно включено по умолчанию и ваш оператор поддерживает VoLTE. Или потому что у вас dual-SIM телефон.
Посмотрите в настройках VoLTE — если есть, может решить проблему с одновременным интернетом и звонками. Хотя может и не решить — если оператор этого не умеет, но попытка не пытка.
Зачем ждать? Видеосвязь с участием сотрудников HR/поддержки/безопасности и того кто знает человека в лицо, или на худой конец просто аудио но с теми кто знает голос сотрудника плюс контрольные вопросы, или перезвон на домаший номер, или… в общем есть много вариантов для того чтобы убедится что это тот кто говорит что он тот.
Если же "ой тут связь плохая" или "у меня камера поломалась" (а это уже как минимум "жёлтый флаг") — то ждать либо пока связь восстановится или камеру приведут в порядок, либо таки лично, потому что ущерб от отсутствия доступа сотрудника за два-три дня вряд-ли будет выше (или хотя бы отдалённо сравним) с потенциальной утечкой данных или доступом к сети кого-то чужого, не говоря уже о том что если "связь плохая" то чёрта с два он удалённо сможет работать.
Скорее всего этот ущерб в районе статистической погрешности. Подозреваю что большинство из тех кто пользуется адблоками с высокой вероятностью либо устойчивы к рекламе либо всё равно ничего не купят (в силу бюджета либо полного отсутствия интереса к конкретному товару/услуге) — соответственно, они вообще погоды не делают.
С другой стороны, нельзя прекращать борьбу с адблоками — иначе они точно появится у всех и тогда ущерб станет реальным, а пока баланс в пользу рекламодателей.
Речь про маленькие комании, разумеется. В случае с большими вопрос о взаимозаменяемости обычно не возникает (если процессы поставлены).
Хотя, если бы мне пришлось это делать в большой компании то принцип был бы простой — планы выполняются (это заметно по отчётам, обратной связи с клиентами и доходам) — пусть себе повышают (в пределах бюджета), но если пойдут косяки — то последствия будут соответствующими.
Разумеется, если команды не имеют доли от доходов (т.е. нет прямой заинтересованности в их повышении), контроль за расходами и доступностью/заменяемостью должен быть, но именно контроль а не поводок — обычно чистые управленцы недостаточно компетентны технически чтобы "прочухать" уровень человека.
gambit_fin Как минимум одна которую я знаю — уже 40 лет существует. Небольшая, но очень гордая со стабильным доходом — без роскошеств, но довольно достойным.
Вы не поверите… вся команда собирается и решает, что и как.
И как же быть командам в которых нет начальника, а есть роли которые меняются в зависимости от текущих задач? Не все компании выстроены вертикально.
Вы, вероятно, невнимательно прочитали мой первый комментарий на эту тему, там не было речи про "два слова", цитирую себя же:
Так что как раз 5-6 слов (или больше), но легко запоминаемое или восстанавливаемое, с достаточной энтропией.
Давайте уж разовьем идею в "пользу" и предположим что они хранятся в открытом виде — поможет нам 128 бит, или даже 1024?
Если мне вдруг придётся ввести пароль в публичном месте — он будет сменен при первой же возможности, потому что нет никаких гарантий что на клавиатуру и экран не смотрит камера — а с камерой фокус "сложно запомнить" не пройдёт.
Ok, посчитаем. Допустим мы используем словарь из 10 тыс. слов, дата у нас 6 цифр а слов всего 5. Получаем 10000^5 * 10^6 = 10^27, т.е. 89 бит. И это я не считаю непонятно где стоящую пунктуацию, то факт что дата может содержать точки или тире а регистр у слов может быть разным, да и их взаимное расположение — тоже.
Так что там у нас с брутфорсом на 89 бит? А если это не простой SHA256 а PBKDF2 или bcrypt?
SATA 2.5" (CMR) либо медленные либо очень дорогие. Насчёт майнеров — не знаю как в РФ, а у нас (Германия) пока полно дисков на 6-18 гиг по ценам прошлого года (с которого они падали вплоть до апреля).
Зачем такие сложности? Нечто вроде "Aquamen Notorious" + набор цифр (например памятная дата кроме дат рождения/свадеб) + название любимой книги с точкой в конце — и вопрос решён — брутфосом это не перебрать (не зная структуры) и соответствует всем адским требованиям (разные регистры + цифры + спецсимвол). Можно в другом поряде, но смысл в том чтобы было несколько не связанных мнжду собой компонентов, каждый из которых легко запоминается или находится если вдруг забыт.
reServer позиционируется именно как сервер, а в NUC всего один сетевой порт и место для одного HDD (и то скорее всего 2.5") — про RAID и быстрые объёмные диски можно забыть, не говоря уже о том что он не расчитан на работу 24/7.
Как по мне, если расчитывать что он будет работать минимум три года (а скорее всего дольше) то эти $200+ — не такая большая разница. Будь такая штука доступна лет 5 назад — взял бы не раздумывая, а так пришлось брать Shuttle (потому что нужно было место для двух HDD).
Я разве говорил что это глупость? Я всего лишь сказал что "можно подумать" о возможных проблемах, особенно когда на телефоне голые фотки.
Неправильно. Вероятность того что под наркозом изнасилуют очень мала (хотя известны случаи) по сравнению с вероятностью что любопытный ремонтник пошарится в данных на ремонтируемом устройстве, особенно если устройство не закрыто паролем/пином.
Вы бы отдали в ремонт телефон с данными которые можно использовать против вас (или нанести ущерб), не имея уверенности что сервису можно доверять? Я, к примеру, предпочёл бы его уничтожить.
В общем-то, отдавая в ремонт телефон с голыми (да и вообще любыми) фотками можно подумать о том что работники сервиса могут их увидеть. И не только фотки.
Увы, не только MySQL — ещё SQLite.
Видимо мы как-то иначе вариации считаем. В частности, почему в вашем примере нет 0011, 0101, 0110 и 0111? Должно ж 16 вариантов получится — если каждый "бит" это наличие условия для параметра или его отсутствие, параметров 4 и условие только одно.
3^n у меня получилось для случаев (parm = col), (parm <> col) и отсутствия параметра — т.е. три возможных варианта для каждого (вместо двух если бы было только "=").
Если я правильно вас понял, речь идёт о том чтобы в запросе иметь нечто вроде:
Выглядит конечно заманчиво, но есть нюанс (о котором я говорил раньше) — нет абсолютно никаких гарантий что сначала будет проверено условие "IS NULL" для параметра, т.е. сервер может впустую сравнивать все параметры (которые не указаны) с данными из таблицы. Да, в идеале оптимизатор должен это прочухать — но всё же гарантий нет.
И ещё момент — кроме условия "=" может быть "<>" — а вот это в один запрос впихнуть уже проблематично. Можно конечно как-то так:
и вынести выбор параметров в приложение (передавая только один в зависимости от условия), но проблема с неопределенным порядком остается, да и в отличие от большинства "нормальных" ЯП в SQL нет "короткого замыкания" в логических операторах, плюс есть шанс что планировщик сойдёт с ума и план для "универсального" запроса может быть значительно дороже чем для узкоспециализированного.
Собственно, в сложных системах где запросы ещё могут использовать другие операторы (типа LIKE или BETWEEN) всё уже просто становится неподъёмно и сильно усложняет код — так что динамическая генерация самый простой способ, а в сочетании с кэшем и учётом того что вариантов (реально используемых) всё же не очень много это отлично работает.
Кроме собственно строки обычно кэшируется подготовленный запрос (prepared statement). Сборка строки может быть сравнительно недорогой, но вот prepare — может быть очень дорого, для этого и нужен кэш запросов.