Самое уязвимое место не то, что оператор, а любой человек в любом месте, в т.ч. сама жертва.
В случае
Часто начал сталкиваться с угоном акков у знакомых, причем перехватываются/не доходят sms, но звонки доходят.
т.е. не просто перевыпуска SIM, а именно тупо редиректа смс, в абсолютном большинстве случаев жертва сама дала такой карт-бланш, тут даже доступ к оператору не нужен никакой.
Самый популярный способ, которому уже 10+ лет - наличие на телефоне приложухи, которая мютит и перенаправляет текст смс куда надо, обычно также в виде смски ( что палится по детализации ). Причем, это может быть вполне легальное какое-то приложение, которое изначально делалось с добрыми намерениями, но которое "службы безопасности всех банков" активно юзают, как юзали раньше TeamViever ( или юзают до сих пор )
Чуть менее популярный - SMSPro у МТС, но тут узкий круг жертв выловить можно, у Т2 тоже недавно появилась услуга редиректа смс из ЛК. Причем, несмотря на то, что для подключения услуги нужен доступ к ЛК и, что при подключении услуги клиенту перед этим приходит смс жертве о факте редиректа и есть даже задержка подключения, мошенников это особо не останавливает. Жертва либо вовсе не замечает такой смски, что происходит чаще всего, либо мошенники легко разводят жертву. Судя по разным кейсам в новостях, это не является для них проблемой.
Немало хейта в комментах в сторону CF и поддержки "пострадавшего".
Но держите в голове важные детали, когда вы жалеете "пострадавшего" :
статья была написана заинтересованной стороной и что было там на самом деле - пока никто кроме этих сторон не знает Мы заведомо не знаем, насколько приврано в тексте
Заинтересованная сторона - казино с 4кк юзерами, которая экономила на CF, пользуясь ими буквально бесплатно, но при этом не удосужились заранее подумать о резервных площадках за счёт огромной экономии на CF. Типа риски с доменом они просчитывают, а риски инфры чот ну позабыли, ага ага.
Понятно, что CF тоже вполне может играть не совсем по правилам, и из статьи выходит, что шантажировал. Но с другой стороны, он продавец и вполне может выставлять свои хотелки по их же условиям, а ты или выполняй или уходи, И судя по временным промежуткам был какой-никакой срок, чтобы понять намек и переехать, или хотя бы резерв сделать, а вместо этого использовались беспонтовые детские угрозы уходом к другим, прекрасно понимая, что они пользуются "забесплатно" и притворяясь небольшим бизнесом. Так что кто тут ещё шантажист надо подумать.
У меня в proxmox живёт и truenas, и nextcloud ( ну там на самом деле все хуже - на трёх виртуалках у меня кубер и именно в нем nextcloud )
В целом, жизнеспособно. Диски в truenas прокинуты как есть. Оверхеда или проблем со скоростью дискового массива нет в моем случае. Но если будет возможность прокинуть железный raid контроллер в виртуалку truenas, то это будет, кмк, надёжнее.
Затем он может изменить номер своей цели на свою SIM-карту из системы самой компании.
Эта котолампа скорее похожа на сюжет какого-то сериала типа "След", где могут увеличить изображение в тысячу раз и увидеть номер автомобиля, который на фотке размером в три пикселя изначально был.
С каких пор любой случайный сотрудник может иметь доступ к изменению данных на UDR и HLR? Тем более в США. Либо в США с безопасностью мобильной связи все ещё хуже, чем в РФ, либо это дикая котолампа.
С каких пор у каких-то людей внутри твиттера есть права для изменения мыла и пароля, ну ладно, хотя это я могу допустить для саппорта, но почему у них существует доступ во внешнюю сеть из-за чего доступен левый сайт, и как они знали, как выглядят внутренние интерфейсы.
Современные джуны по уровню теоретической подготовки соответствуют сеньйорам
В корне не согласен с этим утверждением.
Если смотреть именно по требованиям в вакансиях, то действительно может сложиться такое мнение, но если же смотреть по факту, то картина совсем обратная - современные джуны по уровню теории, и тем более практики, в среднем/по медиане хуже того, что было лет 15 назад. Причем, это справедливо почти для любого стека технологий.
Взять тот же JS - сегодняшние джуны-вкатуны зачастую изучают какой-то модный фреймворк, а саму базу JS им удается как-то избегать. Как следствие, они завязаны на этот фреймворк, их труднее перекинуть на проект с другим фреймворком. И довольно часто, возникает парадокс, на реакте приложение в целом относительно неплохо пишется, но как только помощника в виде фреймворка нет и надо зайти на уровень ниже, используя JS в голом виде, то они могут сломаться на ровном месте и напишут, скорее всего, какашку, либо будут сидеть целую неделю с задачей на пару часов. Это не шутка.
Плюс, тогдашние даже новички самостоятельно могли развернуть проект на серваке, админить, в случае проблем с окружением и закуском проекта самостоятельно находить решения. А сегодняшние JS(точнее даже react/vue) кодеры довольно часто перекидывают этот вопрос на админов/девопсов, если вдруг по их стандартному пути раскатки что-то пошло не так. Довольно редкие кадры соответствует тому уровню подготовки, что был 15 лет назад.
Да, среди них могут затесаться очень толковые ребята, которые тебе ещё и кишки реакта пропатчат, и на ангуляре без проблем и нытья покодят, ещё бонусом и на c++ пишут, ну и кубер оператор на го зафигачат, но их прям исчезающе мало. Если же говорить о длинных списках требований в вакансиях для джунов, то да, слышать о всем списке технологий и инструментов из вакансии вкатуны может и слышали, и даже кучу мемов с ними в рабочих чатах покидают без проблем, но это не означает автоматически, что они могут их с толком использовать, когда это действительно нужно, для решения бизнес-задач - таких, опять же, буквально единицы.
Так что тезис оратора выше вполне справедлив, если показать себя, то дальше будет сильно легче обойти толпу макак, потому как реально квалифицированных кадров действительно не хватает. Вопрос же трудоустройства и всратых собесов это отдельная многогранная тема, нередко не имеющая ничего общего с востребованностью кадров, самое главное пройти этот этап, на что, конечно, тоже нужны скиллы.
Работать лучше Яндекса на русском - это довольно сильное заявление, я вам скажу.
Вы действительно сможете сделать так, чтобы ассистент полностью понимал контекст и синонимы, без необходимости указывать ему точное название устройства в УД?
Например, из фразы "включи свет у входа" смог бы определить, что речь о прихожей, хотя в системе УД "прихожая" никак не помечена, что это "около входа"? Или при "включи левую лампу" он понимает, что речь о "левом светильнике" в той же комнате, где расположен ассистент? Или чтобы он понимал, что "кондей" и "кондёр" это кондиционер, а не падал бы в конвульсиях от невозможности найти такой девайс, или по "Убери в комнате" понимал бы, что речь о том, что надо запустить пылесос в зоне комнаты
Если да, то ждём-с. А то что-то пока что-то кроме Яндекса никто не смог сделать это более-менее красиво. Посоперничать могут разве что гугл ( но в русском он никакой ) и эпл ( ещё хуже ). Многие пытались и пытаются сделать это ни один год и до сих пор до их уровня даже и близко никто не дошел, а вы такими заявлениями разбрасываетесь. И чтобы вы не говорили ниже, а куча бабла решает, это точно такой же ресурс, который помогает и ускоряет процесс.
Внезапно, HA предлагает приложение, где можно создать автоматизации, предлагает опциональное облако с e2e для управления вашим инстансом HA, и голосового ассистента, работающего без интернета. Да, ассистент топорный, хуже Яндекса, но есть.
Единственное, чего HA пока не может предложить - подсказки на основе паттернов. Но я не уверен, что это в принципе возможно сделать одинаково полезно и удобно для всех пользователей. Да и насколько оно нужно.
Будто бы вам действительно было влом проресерчить вопрос :)
Но, если вы действительно сможете сделать голосового ассистента лучше того же Яндекса, да и ещё без требований доступа к инету, если вы действительно сможете сделать удобную систему УД - я только похлопаю вам.
Так вопрос же не только в стойкости пароля для перебора все таки, но и в том, что пароль может быть слит из самого сервиса. У нас никогда нет и не должно быть уверенности в том, что пароль на серверной стороне хотя бы пусть и без соли, но хешируется.
Да и у нас нет гарантий, что мы где нибудь сами не спалим этот пароль своими руками. Причем этот риск довольно высок даже у лютых гиков на опыте, а менять один слитый пароль в одном сервисе проще, чем бегать по всем.
И тут как раз и появляется нюанс, если пароль один на все сервисы, то до попытки залезть в другие сервисы после получения пароля остались считанные дни, а то и часы. И тут уже абсолютно не важно, насколько стойкий у вас будет простой и надёжный пароль для перебора.
Так что в идеале действительно желательно иметь разные пароли в сервисах. А выбор инструмента уже по желанию. Если вы можете запомнить кучу разных простых и надёжных паролей в голове и не забыть их после отпуска - никто ж вам не запрещает. Если вы не можете положиться на память, то менеджер паролей в целом закрывает этот вопрос. Также можно закладывать в пароль с одной "базой" определенную логику формирования, которая позволит его сделать в меру разным для разных сервисов, но запоминающимся для вас лично. Менеджер паролей в массах выбирается как в достаточной мере надёжное и простое решение. Правда, у меня к онлайновым доверия маловато все же.
А вы при этом на 100% уверены, что пароли в сервисах хранятся должным образом и при утечке одного не потерпите крах?)
Можно кстати использовать одну "базу" для пароля, при этом некоторая его часть меняется в зависимости от каких-то факторов. Будь то название сервиса, домен, логин или ещё какая-то метаинфа. Не в открытом полном виде, конечно, а по какой-то логике, например, последняя буква названия, количество символов в названии. При этом, логику эту знаете только вы. Также можно добавлять некоторую соль для более сложных паролей. Да хоть год последней смены паролей.
Это тоже позволяет запомнить только одну базу, при этом прям с этим же паролем не получится зайти везде сходу, а о наличии логики в пароле ещё надо догадаться. Но минус - это требует немного включать мозг иногда, не всегда на автоматизме набирать, наверное, получится. Ну и если использовать пасхалки по названию или домену, а сервис сделает ребрендинг, то об этом тоже надо помнить.
Тут я не могу поспорить. Просто обычно vi-адепты распространяющие в массы не упоминают эту важную деталь, но почему-то зацикливаются то и дело на хоткеи так, будто их нет нигде, крому vi-*
У вас есть умный дом с ХА или это все только догадки? Или вы настолько накрутили ХА что он меняет свои алгоритмы по статистике?
Какой смысл мне было бы вклиниваться в диалог по теме, которую я не знаю)
Да, накрутил,
Статистика не зависит от доступности БД. Просто она будет нулевая при запуске и для ее наполнения потребуется время. А уж если БД отвалилась во время работы, то статистика ни куда не денется, она все так же будет доступна.
и проблема в том, что в действительности это работает не совсем так, как я ожидаю из доки. Вы не учитываете, что в реальности могут быть баги и неотработанные ситуации, и описание на сайте не гарантия того, что не возникнет коллизий. Гляньте список багов в гитхабе, в тч на SQLAlchemy и, например psycopg2, если говорить про pg, будете приятно удивлены. В ситуации в вакууме вида "доступ до БД отвалился и вернулся" проблемы, конечно, вряд ли будут. Однако в реальности все сложнее и проблема не только в статистике.
Несколько моментов на разных инсталляциях, кейс везде ~одинаковый - HA был подключен к удаленной базе на VPSке. Были проблемы с интернетом с клиентской стороны, но не просто недоступен, а высокий пинг и потери выше 50%, ну вроде и работает, а вроде и нет. HA успешно цеплялся к БД, но все операции производились с дикой задержкой и это, несмотря на документацию, влияло на работу всего HA - сенсоры и логика залипала с периодичностью в несколько секунд ( как выяснилось методом тыка позднее - это период равный db_retry_wait в конфиге рекордера ). Новые текущие значения появлялись в HA лишь после 1-2 секундного отлипания. Как сайд-эффект - росло потребление памяти, так как HA копил зомби-коннекты к БД. Правда, это касалось именно PG и на текущий момент в либе psycopg2 это уже исправлено. Да, пару секунд залипания не страшно и вроде бы незаметно, но очень неприятно, если речь о мгновенных сценариях, типа включения света ночью по датчикам, или ещё более неприятно на мгновенных реакциях на включение одной нагрузки чтобы отключить вторую нагрузку, чтобы не выбило автомат. Это вот реальные сценарии, которые страдали. Из интересных моментов - db_max_retries в конфигурации рекордера в данном случае оказался бесполезен, так как подключение формально происходило за db_retry_wait, но вот сама операция не могла завершиться за это время, но у себя на стенде я не смог воспроизвести такое же поведение, чтобы отловить проблему и сдать багулю. В логах, увы, каких-то пикантных подробностей выцепить на проблемных инсталляциях не удалось.
По этой причине от удаленной базы я отказался, хотя изначально идея была довольно интересная в хранении долговременной истории, и чтобы пользователь не заморачивался с ней.
А по поводу статистики, все, с чем я сталкивался, было исправлено. Но было два кейса, которые всплывали после недоступности базы: - Статистика была просто пустая после старта базы, хотя пока база была недоступна она вполне себе считалась. Решалось рестартом HA, данные, конечно, за период недоступности, пропали - Смешная ситуация с расчетом скользящего среднего за N минут. После восстановления базы, пока не пройдут эти самые N минут - сенсор оставался пустым, хотя HA как бы и имел историю за этот период. К слову, как раз скользящее среднее я использую для общей температуры в комнате, чтобы избежать пиков и пил, чтобы лишний раз не дергать кондер\обогреватель. Я без этой логики, конечно, не умру, но просто неприятно, если они туда сюда будут на каждый чих переключаться. С датчиками то +- все ок, просто бывают ситуации, когда из-за других факторов у них локально кратковременно может поменять температура ( приоткроется балкон на минуту, кто-то постоит рядом, или коты подышат в них ) и это не нужно учитывать "прям ща" И еще по мелочи находились за последние 5 лет, пока я с HA, разной степени неприятности. Обходные пути для проблем конечно были, но это просто немного неприятные моменты.
Тут важно отметить, что HA с того момента хорошо подкрутили и сделали его многопоточным (да и много багов позакрывали, в том числе со статистиками), что вроде как должно снизить риск появления таких ситуаций с залипанием. Однако это все равно не отменяет появления неопределенного поведения в ситуациях с удаленными БД и нестабильным коннектом. Как ни крути, этот кейс и в промышленных условиях вне темы HA часто всплывает и вызывает проблемы, как не обкладывай приложение проверками. И HA тут не будет исключением.
Опять же даже если у вас и есть что-то такое, то в чем проблема в той же автоматизации предусмотреть такую проблему?
Да есть, конечно, fallback-сценарии на основе текущих значений, в случае же отсутствия текущих - переводится в дефолтное состояние, как правило, в отключенное ( справедливо для мощных нагрузок, типа бойлеров, эл. обогревателей ). Это работает так, как и требуется, но это ведь костыль на всякий случай. Ну и опять же, в вышеописанной ситуации с мгновенными сценариями с залипаниями это и не помогло бы никак.
И да, мне уже подсказали что именно в контексте именно умного дома который сам строит алгоритмы своей работы на поведении жильцов статистика и история будет важна. но не в контексте ХА.
А почему не в контексте HA? Ничто же не мешает выстроить систему вокруг него. HA у меня выступает лишь UI для монитора и интегратором с девайсами. Абсолютно всю логику делает тот же NodeRed, все из Postgres реплицируется в clickhouse для долговременного хранения и просмотра в графане. Сейчас еще ко всему прочему думаю, как накинуть и ML на вентилятор для принятия решений. Пока первая проблематика, которую я хотел бы решить - иногда хочется температуру в комнатах немножко изменить ( жарковато или холодновато, хотя объективно t та же самая ), но непонятно, какие измеримые триггеры приводят к этому. Пока собираю инфу со всех датчиков и девайсов ( включая факт ручного изменения ) до ровного года и буду искать паттерны, по которым можно выносить решение. В идеале - не хочу писать новые сценарии ( хотя это один из выходов ), а возложить это не предварительный расчет, сделанный в кликхаусе с помощью mindsdb по всем сенсорам. Далее он будет NR'ом через апишку доставаться с кликхауса. Пока не знаю, стоит ли игра свеч и выгорит ли идея вообще, но попробовать хочется, но 200+ входных параметров в запросе уже немного пугают. Если не получится - ну просто красивые графички нарисую с зависимостями x)
Лично я такого ни в одном из чатов по ХА не встречал
спросив в одном из чатиков увлеченных уд
Может не в тех чатах обитаете?) Заходите на огонек в дискордный англо чат, тут часто проскакивают довольно специфичные и интересные вопросы с инсталляциями от ультра-гиков ( я иначе их назвать не могу ). Ру тг чаты по УД довольно унылы, имхо, и вопросы с решениями довольно пресные и типовые.
SQLite же изрядно насилует диск, но шансы получить консистентный файл БД на порядок выше
По сравнению с mysql\psql - нет, не выше. Шансы +- такие же, как и тех же mysql\psql, только в sqlite усугубляется тем, что он однофайловый. Я просто исхожу из собственной статистики использования этих трех баз, как на работе, так и в домашних условиях.
Но тут вы верно отметили, все еще зависит от настроек базы, в mysql конечно надо поиграться, но я давненько в ней не копался уже, с момента разделения на марию, может там получше стало. В psql с этим все довольно хорошо и по дефолту, правда, насколько я помню, psql в супервизоре вроде и нет в аддонах, но могу ошибаться.
Но если ты ставишь через эддоны,
Ну слушай, если бы я был настолько зеленым и ставил бы все через аддоны в супервизор установке, как предлагается разрабами - вряд ли бы у меня поднялся вопрос о том, какую базу использовать вообще, я бы и использовал то, что предлагает HA из коробки. К слову, он и не поднимался, когда я только начал копаться в HA. А что за страшные слова тут с mysql и psql - да пофиг) Работает - не трогай)
Ни разу, это самое настоящее избиение соломенного чучела.
Если же для вас претензии к стилю переписки с HR, и к почерку\знакам зодиака действительно равнозначны, то я не вижу смысла в дальнейшем диалоге с вами.
на осовании его переписке в телеграме
Да, я действительно сделал вывод на основании его переписки, и вы его подтвердили сами чуть выше:
Тут же у соискателя обычный легкий повседневный стиль общения.
Если бы HR отбирали по знаку зодиака, то тут действительно неадекватный отбор. Но тут ведь речь о конкретном идет - о наличии делового стиля при общении соискателя с будущим работодателем, прекратите вы уже наконец придумывать соломенных чучел, а то вы то с почерком приходите, то вот теперь со знаками зодиака.
Никто его не записывал головотяпы, обычная констатация факта, что это неприятное явление для меня, и небольшой плюсик для будущего руководителя с точки зрения HR.
Тут же у соискателя обычный легкий повседневный стиль общения.
Ну в этом то как раз и проблема. Должен быть деловой стиль, а не обычный легкий\ленивый\повседневный. Мы же не с друзьями общаемся, в конце концов, и пока еще не с коллегами. Когда возьмут - там уж подстроимся под рамки внутри компании.
Да. в целом, ничего ужасного в повседневном стиле нет, да и об уровне грамотности тоже сложно говорить. Но в этом заинтересован сам соискатель, чтобы показать себя с максимально хорошей стороны. Тем более на руководящую должность.
Чисто мое мнение - такого руководителя я у себя видеть не пожелал бы, знакомство с которым начиналось бы с одного вопроса, оформленного в двух сообщениях в "легком стиле". Я не граммар-наци, это просто неприятно, тем более, когда все окружение, даже друзья, зачастую пишут в деловом стиле, а руководитель, по рабочим вопросам, пишет как друган из моего 18-летия, который в спешке набирает сообщение на ходу по пути в магаз за пивасом. Тут важно уточнить, я допускаю просачивание такой повседневности уже в процессе работы, ситуации разные, например, руководителя вполне могут дернуть вне работы, а он дернет меня с телефона, пока идет вечером в пятницу за пивасиком, условно. Но это не постоянное явление.
Как там пишет HR это уже дело второе, хотя тоже неприятно отталкивает. Но это не значит, что нам надо подстраиваться под уровень HR.
p.s. Ну по почерку это уж совсем атас, конечно. Может быть в 20 веке это было бы справедливо, но сейчас придираться к нему неуместно все же.
А самое ужасное, что эта кликбейтная зараза, словно горячие пирожки, разлетается по разным каналам, которые не будут в фактчекинг. И Мишу Климарева (ЗаТелеком) успели надуть этой новостью.
Мне бы хотелось видеть в новости опровержение заголовку с выдержкой из постановления, чтобы не порождать в комментариях срач с кучей теорий про релокантов. В идеале, новости об изменениях в законодательстве должны писать люди, которые более-менее знакомы с ними, и с правилами операторов, ну или хотя бы способны не менять смысл источника настолько кардинально.
Ньюсмейкеру бы руки оторвать за эту новость, за кликбейт из ничего в прямом смысле. Не могу понять, это было сделано намеренно или по глупости?
Выдержка из новой редакции постановления по поводу расторжения:
51. Абонент вправе в любое время в одностороннем порядке расторгнуть договор при условии оплаты оказанных услуг телефонной связи.
Отсутствие использования услуг связи абонентом в период, установленный в договоре, но не менее 90 календарных дней, признается конклюдентными действиями, направленными на расторжение договора по инициативе абонента.
Тут ничего не сказано про регистрацию в сети. По факту про использование услуг и сейчас есть на уровне самих операторов, у всех. Единственное отличие в том, что это теперь зафиксировали и в ПОУТС и зафиксирован минимальный срок инактива, который оператор может сделать больше, но не меньше. То есть по факту для конечных пользователей ничего не поменялось - достаточно тратить деньги на услуги ( подключение тарифа с абонкой, платные исходящие смс\звонки, прием платных входящих в роуминге и т.п. ) и ваш номер будет активным и не будет расторгнут.
Поправлю сам себя, после просмотра новой редакции постановления.
Для конечных пользователей ничего не меняется, никаких "был в сети" там нет.
В новой редакции тексте постановления указано
51. Абонент вправе в любое время в одностороннем порядке расторгнуть договор при условии оплаты оказанных услуг телефонной связи.
Отсутствие использования услуг связи абонентом в период, установленный в договоре, но не менее 90 календарных дней, признается конклюдентными действиями, направленными на расторжение договора по инициативе абонента.
Тут ничего не сказано про регистрацию в сети. Ньюсмейкер либо криво прочитал это, либо криво донес. По факту это и сейчас есть на уровне самих операторов, у всех. Единственное отличие в том, что это теперь зафиксировали в ПОУТС и зафиксирован минимальный срок инактива, который оператор может сделать больше, но не меньше.
Самое уязвимое место не то, что оператор, а любой человек в любом месте, в т.ч. сама жертва.
В случае
т.е. не просто перевыпуска SIM, а именно тупо редиректа смс, в абсолютном большинстве случаев жертва сама дала такой карт-бланш, тут даже доступ к оператору не нужен никакой.
Самый популярный способ, которому уже 10+ лет - наличие на телефоне приложухи, которая мютит и перенаправляет текст смс куда надо, обычно также в виде смски ( что палится по детализации ). Причем, это может быть вполне легальное какое-то приложение, которое изначально делалось с добрыми намерениями, но которое "службы безопасности всех банков" активно юзают, как юзали раньше TeamViever ( или юзают до сих пор )
Чуть менее популярный - SMSPro у МТС, но тут узкий круг жертв выловить можно, у Т2 тоже недавно появилась услуга редиректа смс из ЛК. Причем, несмотря на то, что для подключения услуги нужен доступ к ЛК и, что при подключении услуги клиенту перед этим приходит смс жертве о факте редиректа и есть даже задержка подключения, мошенников это особо не останавливает. Жертва либо вовсе не замечает такой смски, что происходит чаще всего, либо мошенники легко разводят жертву. Судя по разным кейсам в новостях, это не является для них проблемой.
Немало хейта в комментах в сторону CF и поддержки "пострадавшего".
Но держите в голове важные детали, когда вы жалеете "пострадавшего" :
статья была написана заинтересованной стороной и что было там на самом деле - пока никто кроме этих сторон не знает Мы заведомо не знаем, насколько приврано в тексте
Заинтересованная сторона - казино с 4кк юзерами, которая экономила на CF, пользуясь ими буквально бесплатно, но при этом не удосужились заранее подумать о резервных площадках за счёт огромной экономии на CF. Типа риски с доменом они просчитывают, а риски инфры чот ну позабыли, ага ага.
Понятно, что CF тоже вполне может играть не совсем по правилам, и из статьи выходит, что шантажировал. Но с другой стороны, он продавец и вполне может выставлять свои хотелки по их же условиям, а ты или выполняй или уходи, И судя по временным промежуткам был какой-никакой срок, чтобы понять намек и переехать, или хотя бы резерв сделать, а вместо этого использовались беспонтовые детские угрозы уходом к другим, прекрасно понимая, что они пользуются "забесплатно" и притворяясь небольшим бизнесом. Так что кто тут ещё шантажист надо подумать.
Энивей, обе стороны нечисты наруку.
Это вам в сторону tracing копать надо, как мне кажется. точнее даже OpenTelemetry на сегодня.
У меня в proxmox живёт и truenas, и nextcloud ( ну там на самом деле все хуже - на трёх виртуалках у меня кубер и именно в нем nextcloud )
В целом, жизнеспособно. Диски в truenas прокинуты как есть. Оверхеда или проблем со скоростью дискового массива нет в моем случае. Но если будет возможность прокинуть железный raid контроллер в виртуалку truenas, то это будет, кмк, надёжнее.
Эта котолампа скорее похожа на сюжет какого-то сериала типа "След", где могут увеличить изображение в тысячу раз и увидеть номер автомобиля, который на фотке размером в три пикселя изначально был.
С каких пор любой случайный сотрудник может иметь доступ к изменению данных на UDR и HLR? Тем более в США. Либо в США с безопасностью мобильной связи все ещё хуже, чем в РФ, либо это дикая котолампа.
С каких пор у каких-то людей внутри твиттера есть права для изменения мыла и пароля, ну ладно, хотя это я могу допустить для саппорта, но почему у них существует доступ во внешнюю сеть из-за чего доступен левый сайт, и как они знали, как выглядят внутренние интерфейсы.
И у меня ещё много вопросов вообще.
Я чего-то не понимаю в этом мире видимо
В корне не согласен с этим утверждением.
Если смотреть именно по требованиям в вакансиях, то действительно может сложиться такое мнение, но если же смотреть по факту, то картина совсем обратная - современные джуны по уровню теории, и тем более практики, в среднем/по медиане хуже того, что было лет 15 назад. Причем, это справедливо почти для любого стека технологий.
Взять тот же JS - сегодняшние джуны-вкатуны зачастую изучают какой-то модный фреймворк, а саму базу JS им удается как-то избегать. Как следствие, они завязаны на этот фреймворк, их труднее перекинуть на проект с другим фреймворком. И довольно часто, возникает парадокс, на реакте приложение в целом относительно неплохо пишется, но как только помощника в виде фреймворка нет и надо зайти на уровень ниже, используя JS в голом виде, то они могут сломаться на ровном месте и напишут, скорее всего, какашку, либо будут сидеть целую неделю с задачей на пару часов. Это не шутка.
Плюс, тогдашние даже новички самостоятельно могли развернуть проект на серваке, админить, в случае проблем с окружением и закуском проекта самостоятельно находить решения. А сегодняшние JS(точнее даже react/vue) кодеры довольно часто перекидывают этот вопрос на админов/девопсов, если вдруг по их стандартному пути раскатки что-то пошло не так. Довольно редкие кадры соответствует тому уровню подготовки, что был 15 лет назад.
Да, среди них могут затесаться очень толковые ребята, которые тебе ещё и кишки реакта пропатчат, и на ангуляре без проблем и нытья покодят, ещё бонусом и на c++ пишут, ну и кубер оператор на го зафигачат, но их прям исчезающе мало. Если же говорить о длинных списках требований в вакансиях для джунов, то да, слышать о всем списке технологий и инструментов из вакансии вкатуны может и слышали, и даже кучу мемов с ними в рабочих чатах покидают без проблем, но это не означает автоматически, что они могут их с толком использовать, когда это действительно нужно, для решения бизнес-задач - таких, опять же, буквально единицы.
Так что тезис оратора выше вполне справедлив, если показать себя, то дальше будет сильно легче обойти толпу макак, потому как реально квалифицированных кадров действительно не хватает. Вопрос же трудоустройства и всратых собесов это отдельная многогранная тема, нередко не имеющая ничего общего с востребованностью кадров, самое главное пройти этот этап, на что, конечно, тоже нужны скиллы.
Последние два пункта решаются другой тулзой для синхры. В моем случае это FolderSync, емнип, он и на маке был.
Нативное клиентское приложение nextcloud действительно немного всратенько.
Из трунаса все работает норм, правда, стоит отметить, что у меня scale, не bsdшный трунас)
Работать лучше Яндекса на русском - это довольно сильное заявление, я вам скажу.
Вы действительно сможете сделать так, чтобы ассистент полностью понимал контекст и синонимы, без необходимости указывать ему точное название устройства в УД?
Например, из фразы "включи свет у входа" смог бы определить, что речь о прихожей, хотя в системе УД "прихожая" никак не помечена, что это "около входа"? Или при "включи левую лампу" он понимает, что речь о "левом светильнике" в той же комнате, где расположен ассистент? Или чтобы он понимал, что "кондей" и "кондёр" это кондиционер, а не падал бы в конвульсиях от невозможности найти такой девайс, или по "Убери в комнате" понимал бы, что речь о том, что надо запустить пылесос в зоне комнаты
Если да, то ждём-с. А то что-то пока что-то кроме Яндекса никто не смог сделать это более-менее красиво. Посоперничать могут разве что гугл ( но в русском он никакой ) и эпл ( ещё хуже ). Многие пытались и пытаются сделать это ни один год и до сих пор до их уровня даже и близко никто не дошел, а вы такими заявлениями разбрасываетесь. И чтобы вы не говорили ниже, а куча бабла решает, это точно такой же ресурс, который помогает и ускоряет процесс.
Внезапно, HA предлагает приложение, где можно создать автоматизации, предлагает опциональное облако с e2e для управления вашим инстансом HA, и голосового ассистента, работающего без интернета. Да, ассистент топорный, хуже Яндекса, но есть.
Единственное, чего HA пока не может предложить - подсказки на основе паттернов. Но я не уверен, что это в принципе возможно сделать одинаково полезно и удобно для всех пользователей. Да и насколько оно нужно.
Будто бы вам действительно было влом проресерчить вопрос :)
Но, если вы действительно сможете сделать голосового ассистента лучше того же Яндекса, да и ещё без требований доступа к инету, если вы действительно сможете сделать удобную систему УД - я только похлопаю вам.
Так вопрос же не только в стойкости пароля для перебора все таки, но и в том, что пароль может быть слит из самого сервиса. У нас никогда нет и не должно быть уверенности в том, что пароль на серверной стороне хотя бы пусть и без соли, но хешируется.
Да и у нас нет гарантий, что мы где нибудь сами не спалим этот пароль своими руками. Причем этот риск довольно высок даже у лютых гиков на опыте, а менять один слитый пароль в одном сервисе проще, чем бегать по всем.
И тут как раз и появляется нюанс, если пароль один на все сервисы, то до попытки залезть в другие сервисы после получения пароля остались считанные дни, а то и часы. И тут уже абсолютно не важно, насколько стойкий у вас будет простой и надёжный пароль для перебора.
Так что в идеале действительно желательно иметь разные пароли в сервисах. А выбор инструмента уже по желанию. Если вы можете запомнить кучу разных простых и надёжных паролей в голове и не забыть их после отпуска - никто ж вам не запрещает. Если вы не можете положиться на память, то менеджер паролей в целом закрывает этот вопрос. Также можно закладывать в пароль с одной "базой" определенную логику формирования, которая позволит его сделать в меру разным для разных сервисов, но запоминающимся для вас лично. Менеджер паролей в массах выбирается как в достаточной мере надёжное и простое решение. Правда, у меня к онлайновым доверия маловато все же.
А вы при этом на 100% уверены, что пароли в сервисах хранятся должным образом и при утечке одного не потерпите крах?)
Можно кстати использовать одну "базу" для пароля, при этом некоторая его часть меняется в зависимости от каких-то факторов. Будь то название сервиса, домен, логин или ещё какая-то метаинфа. Не в открытом полном виде, конечно, а по какой-то логике, например, последняя буква названия, количество символов в названии. При этом, логику эту знаете только вы. Также можно добавлять некоторую соль для более сложных паролей. Да хоть год последней смены паролей.
Это тоже позволяет запомнить только одну базу, при этом прям с этим же паролем не получится зайти везде сходу, а о наличии логики в пароле ещё надо догадаться. Но минус - это требует немного включать мозг иногда, не всегда на автоматизме набирать, наверное, получится. Ну и если использовать пасхалки по названию или домену, а сервис сделает ребрендинг, то об этом тоже надо помнить.
Тут я не могу поспорить. Просто обычно vi-адепты распространяющие в массы не упоминают эту важную деталь, но почему-то зацикливаются то и дело на хоткеи так, будто их нет нигде, крому vi-*
Какой смысл мне было бы вклиниваться в диалог по теме, которую я не знаю)
Да, накрутил,
и проблема в том, что в действительности это работает не совсем так, как я ожидаю из доки. Вы не учитываете, что в реальности могут быть баги и неотработанные ситуации, и описание на сайте не гарантия того, что не возникнет коллизий. Гляньте список багов в гитхабе, в тч на SQLAlchemy и, например psycopg2, если говорить про pg, будете приятно удивлены. В ситуации в вакууме вида "доступ до БД отвалился и вернулся" проблемы, конечно, вряд ли будут. Однако в реальности все сложнее и проблема не только в статистике.
Несколько моментов на разных инсталляциях, кейс везде ~одинаковый - HA был подключен к удаленной базе на VPSке.
Были проблемы с интернетом с клиентской стороны, но не просто недоступен, а высокий пинг и потери выше 50%, ну вроде и работает, а вроде и нет. HA успешно цеплялся к БД, но все операции производились с дикой задержкой и это, несмотря на документацию, влияло на работу всего HA - сенсоры и логика залипала с периодичностью в несколько секунд ( как выяснилось методом тыка позднее - это период равный db_retry_wait в конфиге рекордера ). Новые текущие значения появлялись в HA лишь после 1-2 секундного отлипания.
Как сайд-эффект - росло потребление памяти, так как HA копил зомби-коннекты к БД. Правда, это касалось именно PG и на текущий момент в либе psycopg2 это уже исправлено.
Да, пару секунд залипания не страшно и вроде бы незаметно, но очень неприятно, если речь о мгновенных сценариях, типа включения света ночью по датчикам, или ещё более неприятно на мгновенных реакциях на включение одной нагрузки чтобы отключить вторую нагрузку, чтобы не выбило автомат. Это вот реальные сценарии, которые страдали.
Из интересных моментов - db_max_retries в конфигурации рекордера в данном случае оказался бесполезен, так как подключение формально происходило за db_retry_wait, но вот сама операция не могла завершиться за это время, но у себя на стенде я не смог воспроизвести такое же поведение, чтобы отловить проблему и сдать багулю. В логах, увы, каких-то пикантных подробностей выцепить на проблемных инсталляциях не удалось.
По этой причине от удаленной базы я отказался, хотя изначально идея была довольно интересная в хранении долговременной истории, и чтобы пользователь не заморачивался с ней.
А по поводу статистики, все, с чем я сталкивался, было исправлено. Но было два кейса, которые всплывали после недоступности базы:
- Статистика была просто пустая после старта базы, хотя пока база была недоступна она вполне себе считалась. Решалось рестартом HA, данные, конечно, за период недоступности, пропали
- Смешная ситуация с расчетом скользящего среднего за N минут. После восстановления базы, пока не пройдут эти самые N минут - сенсор оставался пустым, хотя HA как бы и имел историю за этот период.
К слову, как раз скользящее среднее я использую для общей температуры в комнате, чтобы избежать пиков и пил, чтобы лишний раз не дергать кондер\обогреватель. Я без этой логики, конечно, не умру, но просто неприятно, если они туда сюда будут на каждый чих переключаться. С датчиками то +- все ок, просто бывают ситуации, когда из-за других факторов у них локально кратковременно может поменять температура ( приоткроется балкон на минуту, кто-то постоит рядом, или коты подышат в них ) и это не нужно учитывать "прям ща"
И еще по мелочи находились за последние 5 лет, пока я с HA, разной степени неприятности.
Обходные пути для проблем конечно были, но это просто немного неприятные моменты.
Тут важно отметить, что HA с того момента хорошо подкрутили и сделали его многопоточным (да и много багов позакрывали, в том числе со статистиками), что вроде как должно снизить риск появления таких ситуаций с залипанием. Однако это все равно не отменяет появления неопределенного поведения в ситуациях с удаленными БД и нестабильным коннектом. Как ни крути, этот кейс и в промышленных условиях вне темы HA часто всплывает и вызывает проблемы, как не обкладывай приложение проверками. И HA тут не будет исключением.
Да есть, конечно, fallback-сценарии на основе текущих значений, в случае же отсутствия текущих - переводится в дефолтное состояние, как правило, в отключенное ( справедливо для мощных нагрузок, типа бойлеров, эл. обогревателей ). Это работает так, как и требуется, но это ведь костыль на всякий случай. Ну и опять же, в вышеописанной ситуации с мгновенными сценариями с залипаниями это и не помогло бы никак.
А почему не в контексте HA? Ничто же не мешает выстроить систему вокруг него. HA у меня выступает лишь UI для монитора и интегратором с девайсами. Абсолютно всю логику делает тот же NodeRed, все из Postgres реплицируется в clickhouse для долговременного хранения и просмотра в графане.
Сейчас еще ко всему прочему думаю, как накинуть и ML на вентилятор для принятия решений.
Пока первая проблематика, которую я хотел бы решить - иногда хочется температуру в комнатах немножко изменить ( жарковато или холодновато, хотя объективно t та же самая ), но непонятно, какие измеримые триггеры приводят к этому. Пока собираю инфу со всех датчиков и девайсов ( включая факт ручного изменения ) до ровного года и буду искать паттерны, по которым можно выносить решение.
В идеале - не хочу писать новые сценарии ( хотя это один из выходов ), а возложить это не предварительный расчет, сделанный в кликхаусе с помощью mindsdb по всем сенсорам. Далее он будет NR'ом через апишку доставаться с кликхауса.
Пока не знаю, стоит ли игра свеч и выгорит ли идея вообще, но попробовать хочется, но 200+ входных параметров в запросе уже немного пугают.
Если не получится - ну просто красивые графички нарисую с зависимостями x)
Может не в тех чатах обитаете?) Заходите на огонек в дискордный англо чат, тут часто проскакивают довольно специфичные и интересные вопросы с инсталляциями от ультра-гиков ( я иначе их назвать не могу ). Ру тг чаты по УД довольно унылы, имхо, и вопросы с решениями довольно пресные и типовые.
По сравнению с mysql\psql - нет, не выше. Шансы +- такие же, как и тех же mysql\psql, только в sqlite усугубляется тем, что он однофайловый.
Я просто исхожу из собственной статистики использования этих трех баз, как на работе, так и в домашних условиях.
Но тут вы верно отметили, все еще зависит от настроек базы, в mysql конечно надо поиграться, но я давненько в ней не копался уже, с момента разделения на марию, может там получше стало. В psql с этим все довольно хорошо и по дефолту, правда, насколько я помню, psql в супервизоре вроде и нет в аддонах, но могу ошибаться.
Ну слушай, если бы я был настолько зеленым и ставил бы все через аддоны в супервизор установке, как предлагается разрабами - вряд ли бы у меня поднялся вопрос о том, какую базу использовать вообще, я бы и использовал то, что предлагает HA из коробки. К слову, он и не поднимался, когда я только начал копаться в HA. А что за страшные слова тут с mysql и psql - да пофиг) Работает - не трогай)
Ни разу, это самое настоящее избиение соломенного чучела.
Если же для вас претензии к стилю переписки с HR, и к почерку\знакам зодиака действительно равнозначны, то я не вижу смысла в дальнейшем диалоге с вами.
Да, я действительно сделал вывод на основании его переписки, и вы его подтвердили сами чуть выше:
В чем вопрос-то?
Если бы HR отбирали по знаку зодиака, то тут действительно неадекватный отбор. Но тут ведь речь о конкретном идет - о наличии делового стиля при общении соискателя с будущим работодателем, прекратите вы уже наконец придумывать соломенных чучел, а то вы то с почерком приходите, то вот теперь со знаками зодиака.
Никто его не записывал головотяпы, обычная констатация факта, что это неприятное явление для меня, и небольшой плюсик для будущего руководителя с точки зрения HR.
Ну в этом то как раз и проблема. Должен быть деловой стиль, а не обычный легкий\ленивый\повседневный. Мы же не с друзьями общаемся, в конце концов, и пока еще не с коллегами. Когда возьмут - там уж подстроимся под рамки внутри компании.
Да. в целом, ничего ужасного в повседневном стиле нет, да и об уровне грамотности тоже сложно говорить. Но в этом заинтересован сам соискатель, чтобы показать себя с максимально хорошей стороны. Тем более на руководящую должность.
Чисто мое мнение - такого руководителя я у себя видеть не пожелал бы, знакомство с которым начиналось бы с одного вопроса, оформленного в двух сообщениях в "легком стиле". Я не граммар-наци, это просто неприятно, тем более, когда все окружение, даже друзья, зачастую пишут в деловом стиле, а руководитель, по рабочим вопросам, пишет как друган из моего 18-летия, который в спешке набирает сообщение на ходу по пути в магаз за пивасом.
Тут важно уточнить, я допускаю просачивание такой повседневности уже в процессе работы, ситуации разные, например, руководителя вполне могут дернуть вне работы, а он дернет меня с телефона, пока идет вечером в пятницу за пивасиком, условно. Но это не постоянное явление.
Как там пишет HR это уже дело второе, хотя тоже неприятно отталкивает. Но это не значит, что нам надо подстраиваться под уровень HR.
p.s. Ну по почерку это уж совсем атас, конечно. Может быть в 20 веке это было бы справедливо, но сейчас придираться к нему неуместно все же.
А самое ужасное, что эта кликбейтная зараза, словно горячие пирожки, разлетается по разным каналам, которые не будут в фактчекинг. И Мишу Климарева (ЗаТелеком) успели надуть этой новостью.
Мне бы хотелось видеть в новости опровержение заголовку с выдержкой из постановления, чтобы не порождать в комментариях срач с кучей теорий про релокантов. В идеале, новости об изменениях в законодательстве должны писать люди, которые более-менее знакомы с ними, и с правилами операторов, ну или хотя бы способны не менять смысл источника настолько кардинально.
Ньюсмейкеру бы руки оторвать за эту новость, за кликбейт из ничего в прямом смысле. Не могу понять, это было сделано намеренно или по глупости?
Выдержка из новой редакции постановления по поводу расторжения:
Тут ничего не сказано про регистрацию в сети. По факту про использование услуг и сейчас есть на уровне самих операторов, у всех. Единственное отличие в том, что это теперь зафиксировали и в ПОУТС и зафиксирован минимальный срок инактива, который оператор может сделать больше, но не меньше.
То есть по факту для конечных пользователей ничего не поменялось - достаточно тратить деньги на услуги ( подключение тарифа с абонкой, платные исходящие смс\звонки, прием платных входящих в роуминге и т.п. ) и ваш номер будет активным и не будет расторгнут.
Поправлю сам себя, после просмотра новой редакции постановления.
Для конечных пользователей ничего не меняется, никаких "был в сети" там нет.
В новой редакции тексте постановления указано
Тут ничего не сказано про регистрацию в сети. Ньюсмейкер либо криво прочитал это, либо криво донес. По факту это и сейчас есть на уровне самих операторов, у всех. Единственное отличие в том, что это теперь зафиксировали в ПОУТС и зафиксирован минимальный срок инактива, который оператор может сделать больше, но не меньше.