Всё ещё хотелось бы услышать не про экономию 8 байт на строку, а про влияние на эффективность. Предполагаю, что идёт на пользу :-), но вы почему-то ничего про это не написали.
Если человек не создал индекс для колонки, на которую ссылается – то он сам себе злобный дендромутант.
Причём даже есть он создал блум вместо индекса, но половина используемых строк есть – их всё равно придётся искать в таблице. Т.е. скорость увеличится в лучше случае вдвое – несопоставимо с эффектом от индекса (который из O(n) делает O(log n)).
Да неважно, сколько строк написано ИИ. Пока ИИ может галлюцинировать, а разработчик давать ему неполную/нечёткую задачу – важно, насколько разработчик разобрался в коде, который коммитит в репу.
При построении – не нужен. По сути, фильтр Блума – это эдакий легковесный "недоиндекс", который может быть применён ровно в одном случае: когда ситуация "нет ни одной подходящей записи" достаточно частая, чтобы не искать эту запись по индексу.
Но не вижу ни единой причины строить фильтр Блума и не строить индекс. Данные для их построения нужны ровно одни и те же, и если фильтр Блума показал возможное наличие записи – всё равно придётся её искать в таблице, что лучше сделать по индексу.
Нашёл ответы на оба вопроса, про обновление по вашей ссылке ("когда система устанавливает обновление приложения, она сравнивает сертификаты в новой версии с сертификатами в существующей версии. Система разрешает обновление, если сертификаты совпадают"), про удаление в https://developer.android.com/reference/android/Manifest.permission#DELETE_PACKAGES ("Starting in Build.VERSION_CODES.N, user confirmation is requested when the application deleting the package is not the same application that installed the package").
И, судя по всему, дополнительная тонкость: при попытке удаления приложения из второго профиля – оно не удаляется из первого, а значит, и приложение-замену с другим ключом поставить невозможно.
Ну вот мне, хоть убейте, непонятно, почему для случая из примера он может не существовать. Проверка "iforder.id == customer.order_id" – за гранью того, что я могу понять и простить.
И, насколько я понял, чуть погуглив по теме, если там нет индекса – то и фильтра Блума не будет.
Вы говорите не про срок отзыва, а про срок действия. Сертификат может быть на 30 лет, но отзываться за трое суток. Т.е. срок отзыва 72 часа, но ты не думаешь об этом годами.
Опять же: никакого "чтобы подтолкнуть их к автоматизации" не случится: данные сертификаты отзываются с концами, их надо выпускать заново, вновь удостоверяя для этого, что это именно твой сайт.
Спасибо! Это важный аспект. Надо также удостовериться, что он не имеет возможности приложение снести и поставить заново (понятно, что с потерей всех данных, но, скорей всего, столкнувшись с таким – просто залогинишься в приложении заново). Возможно, именно с этим случаем я столкнулся: при попытке обновить одно из установленных ранее в основном профиле (из apk, емнип) приложений он сказал, что обновление невозможно, и предложил его снести и поставить заново – но не смог :-)
Вообще у вас случайно нет ссылочки на какую-нибудь доку, где кратко разъясняется специфика установки/обновления (вот та самая проверка ключа – что делается при установке из apk, если приложение уже есть? какой permission отвечает за возможность удаления других приложений? и т.п.) и доку, разъясняющую специфику второго пространства (запускаются ли фоновые процессы из него или только доходят пуши и т.п.?)
Сегодня наконец собрался поиграться с такой конфигурацией. Выглядит так, будто есть фундаментальная проблема: rustore во втором пространстве может поставить любое приложение, и оно обновится (на версию из рустора) в основном пространстве.
Похоже, для тех, кто ищет безопасности – это всё-таки не подойдёт. Ну а пока просто отозвал у рустора разрешение на установку из неизвестных источников.
В этом случае у юзера нет возможности перевыпустить сертификат.
В общем, мало-мальски осмысленная схема проверки готовности CA к отзыву сертификатов – "тайные покупатели". Клиенты, которые будут выпускать сертификат, а потом в случайный момент времени его отзывать и проверять, что отзыв состоялся. А отзывать у случайных юзеров – это как стирать случайные файлы на диске пользователя. Пусть привыкает бэкапить.
Впрочем, возможно, Бен просто не умеет выражать свои мысли, и эти случайные 30 сертификатов – это сертификаты из специального тестового пула, а не кастомерские.
Кажется, он не понимает саму идею отзыва сертификата. Отзыв идёт снизу вверх – именно юзер оповещает УЦ о необходимости отзыва сертификата, не наоборот.
Разумеется. Покупали их, потому что форма, вес (возможно, выставленный грузиками) и поведение кнопок с колесом им удобны.
Т.е. у этих геймерских мышек, помимо свистоперделок, были нужные им фичи – которых не было у не-геймерских.
Так же, как я покупал геймерский ноут не ради свистоперделок (красную подсветку клавы пришлось стерпеть), а потому что за эти деньги ничего другого с нужными параметрами просто не было.
Я сам не геймер, меня простая Magic Mouse на маке или ещё более простая Logitech M170 на винде вполне устраивает, но часть коллег покупает себе (не для игр) геймерские мыши. Да что там – я сам в своё время геймерский ноутбук купил – просто потому, что по параметрам он больше подходил для работы.
Всё ещё хотелось бы услышать не про экономию 8 байт на строку, а про влияние на эффективность. Предполагаю, что идёт на пользу :-), но вы почему-то ничего про это не написали.
Если человек не создал индекс для колонки, на которую ссылается – то он сам себе злобный дендромутант.
Причём даже есть он создал блум вместо индекса, но половина используемых строк есть – их всё равно придётся искать в таблице. Т.е. скорость увеличится в лучше случае вдвое – несопоставимо с эффектом от индекса (который из O(n) делает O(log n)).
Ага, объяснение сложным языком простых вещей...
А в чём смысл кроить на этих байтах? Сейчас SSD относительно дешёвые, уже даже не вспоминают про решения типа Stacker и DoubleSpace.
А про влияние на быстродействие базы вы не написали.
Да неважно, сколько строк написано ИИ. Пока ИИ может галлюцинировать, а разработчик давать ему неполную/нечёткую задачу – важно, насколько разработчик разобрался в коде, который коммитит в репу.
При построении – не нужен. По сути, фильтр Блума – это эдакий легковесный "недоиндекс", который может быть применён ровно в одном случае: когда ситуация "нет ни одной подходящей записи" достаточно частая, чтобы не искать эту запись по индексу.
Но не вижу ни единой причины строить фильтр Блума и не строить индекс. Данные для их построения нужны ровно одни и те же, и если фильтр Блума показал возможное наличие записи – всё равно придётся её искать в таблице, что лучше сделать по индексу.
Ага, спасибо, даже на русском.
Нашёл ответы на оба вопроса, про обновление по вашей ссылке ("когда система устанавливает обновление приложения, она сравнивает сертификаты в новой версии с сертификатами в существующей версии. Система разрешает обновление, если сертификаты совпадают"), про удаление в https://developer.android.com/reference/android/Manifest.permission#DELETE_PACKAGES ("Starting in Build.VERSION_CODES.N, user confirmation is requested when the application deleting the package is not the same application that installed the package").
И, судя по всему, дополнительная тонкость: при попытке удаления приложения из второго профиля – оно не удаляется из первого, а значит, и приложение-замену с другим ключом поставить невозможно.
Ну вот мне, хоть убейте, непонятно, почему для случая из примера он может не существовать. Проверка "if order.id == customer.order_id" – за гранью того, что я могу понять и простить.
И, насколько я понял, чуть погуглив по теме, если там нет индекса – то и фильтра Блума не будет.
Кстати, я таки проверил: сертификат, установленный во втором профиле, ставится именно для юзера, в основном не виден и не влияет на браузер в нём.
Вы говорите не про срок отзыва, а про срок действия. Сертификат может быть на 30 лет, но отзываться за трое суток. Т.е. срок отзыва 72 часа, но ты не думаешь об этом годами.
Опять же: никакого "чтобы подтолкнуть их к автоматизации" не случится: данные сертификаты отзываются с концами, их надо выпускать заново, вновь удостоверяя для этого, что это именно твой сайт.
Спасибо! Это важный аспект. Надо также удостовериться, что он не имеет возможности приложение снести и поставить заново (понятно, что с потерей всех данных, но, скорей всего, столкнувшись с таким – просто залогинишься в приложении заново).
Возможно, именно с этим случаем я столкнулся: при попытке обновить одно из установленных ранее в основном профиле (из apk, емнип) приложений он сказал, что обновление невозможно, и предложил его снести и поставить заново – но не смог :-)
Вообще у вас случайно нет ссылочки на какую-нибудь доку, где кратко разъясняется специфика установки/обновления (вот та самая проверка ключа – что делается при установке из apk, если приложение уже есть? какой permission отвечает за возможность удаления других приложений? и т.п.) и доку, разъясняющую специфику второго пространства (запускаются ли фоновые процессы из него или только доходят пуши и т.п.?)
Сегодня наконец собрался поиграться с такой конфигурацией. Выглядит так, будто есть фундаментальная проблема: rustore во втором пространстве может поставить любое приложение, и оно обновится (на версию из рустора) в основном пространстве.
Похоже, для тех, кто ищет безопасности – это всё-таки не подойдёт. Ну а пока просто отозвал у рустора разрешение на установку из неизвестных источников.
В этом случае у юзера нет возможности перевыпустить сертификат.
В общем, мало-мальски осмысленная схема проверки готовности CA к отзыву сертификатов – "тайные покупатели". Клиенты, которые будут выпускать сертификат, а потом в случайный момент времени его отзывать и проверять, что отзыв состоялся. А отзывать у случайных юзеров – это как стирать случайные файлы на диске пользователя. Пусть привыкает бэкапить.
Впрочем, возможно, Бен просто не умеет выражать свои мысли, и эти случайные 30 сертификатов – это сертификаты из специального тестового пула, а не кастомерские.
Кажется, он не понимает саму идею отзыва сертификата. Отзыв идёт снизу вверх – именно юзер оповещает УЦ о необходимости отзыва сертификата, не наоборот.
Разумеется. Покупали их, потому что форма, вес (возможно, выставленный грузиками) и поведение кнопок с колесом им удобны.
Т.е. у этих геймерских мышек, помимо свистоперделок, были нужные им фичи – которых не было у не-геймерских.
Так же, как я покупал геймерский ноут не ради свистоперделок (красную подсветку клавы пришлось стерпеть), а потому что за эти деньги ничего другого с нужными параметрами просто не было.
Я сам не геймер, меня простая Magic Mouse на маке или ещё более простая Logitech M170 на винде вполне устраивает, но часть коллег покупает себе (не для игр) геймерские мыши. Да что там – я сам в своё время геймерский ноутбук купил – просто потому, что по параметрам он больше подходил для работы.
Странно. Или это и не геймерская модель?
Было. И ксероксы регистрировать надо было, насколько я помню.
По нынешним временам сигнал легко было бы поймать на SDR (китайский DVB-T свисток за 10 баксов и комп с софтиной), но тех сетей уже нету.