Ну и как-то быстро они сдались. Или не уж то расчитывали, что за эти пару месяцев все бросят свои проекты и начнут заново на новом движке.
Судя по тексту статьи, они даже до релиза не добрались и сдались ещё на стадии открытой беты. То есть до того, как у них в принципе могли появиться крупные коммерческие клиенты. Прям классика грамотного менеджмента: начать делать продукт без изучения рынка и понимания потенциального спроса; не спланировать/заложить бюджет проекта наперед так, чтобы его хватило на время разработки и выхода на самоокупаемость; в итоге сдаться и отправить проект в забвение. Ну или причина та же, что и обычно: были бесплатные деньги, их осваивали пока давали.
Увы, единственный жизнеспособный вариант будет - использовать oid таблицы. А это уже 4 байта aka 32 бита. В противном случае получится решение, которое не подойдёт тем, у кого таблиц много/не будет иметь удобного-нативного способа напрямую соотнести таблицу с таким полем из UUID. Ну или мы возьмём много бит чтобы хватило всем и сильно на случайной части потеряем, облегчив подбор ключей перебором.
Да и смысл? Если вы записываете/выбираете значение, то вы и так уже знаете с какой таблицей вы работаете.
Угу. Только там оно было, ЕМНИП, 48-битным куском ВМЕСТО рандомных бит, что уже действительно сильно на случайность и стойкость к подбору влияет. А вот оставить ощутимое количество рандомных бит и небольшое поле для предотвращения коллизий - такого там нет.
Ну и централизованная координация не так страшна, как кажется. По-крайней мере её можно автоматизировать и делать на уровне хотя бы того же конфига СУБД однократно при запуске инстанса. А дальше у нас во время работы бесплатно гарантия отсутствия коллизий в распределенной системе без всяких проверок.
И, вдобавок, были реальные случаи совпадения MAC-адресов.
Вот поэтому я за ручное распределение всегда. Если вы делаете подобные штуки для гарантий уникальности, то лучше потратить немного времени и вручную задать значение, чем полагаться на то, что оно автоматом окажется не совпадающим с другими.
Мысль на грани идиотии для исключения коллизии в случае многих бэкэндов: небольшую часть из 62 случайных бит разрешить отдавать под фиксированный id бэкэнда (уникальный для каждого из них). Тогда даже если каким-то чудом совпадут временная и случайная часть битов, гарантированно уникальная фиксированная часть обеспечит отсутствие коллизии. Да, теряем на размере случайной части, но, если не увлекаться и условные 6-8 бит позволить откусывать, то выглядит всё ещё не так страшно. Впрочем это, очевидно, будет уже не совсем UUIDv7)
"L1" (что, кстати, в случае ethernet вообще не совсем верный термин т.к. стандарт не подразумевает строгого разделения на L1 и L2 и формализует одновременно оба уровня) вообще ничего не содержит и не инкапсулирует. Это способ модуляции сигнала.
Судя по тексту статьи, они даже до релиза не добрались и сдались ещё на стадии открытой беты. То есть до того, как у них в принципе могли появиться крупные коммерческие клиенты. Прям классика грамотного менеджмента: начать делать продукт без изучения рынка и понимания потенциального спроса; не спланировать/заложить бюджет проекта наперед так, чтобы его хватило на время разработки и выхода на самоокупаемость; в итоге сдаться и отправить проект в забвение.
Ну или причина та же, что и обычно: были бесплатные деньги, их осваивали пока давали.ВК за всё берется смело
Всё превращается в говно
А если за говно берётся
То просто тратит меньше сил
Три: пароль от сети заносится в keepass и проблема решена.
Увы, единственный жизнеспособный вариант будет - использовать oid таблицы. А это уже 4 байта aka 32 бита. В противном случае получится решение, которое не подойдёт тем, у кого таблиц много/не будет иметь удобного-нативного способа напрямую соотнести таблицу с таким полем из UUID. Ну или мы возьмём много бит чтобы хватило всем и сильно на случайной части потеряем, облегчив подбор ключей перебором.
Да и смысл? Если вы записываете/выбираете значение, то вы и так уже знаете с какой таблицей вы работаете.
Угу. Только там оно было, ЕМНИП, 48-битным куском ВМЕСТО рандомных бит, что уже действительно сильно на случайность и стойкость к подбору влияет. А вот оставить ощутимое количество рандомных бит и небольшое поле для предотвращения коллизий - такого там нет.
Ну и централизованная координация не так страшна, как кажется. По-крайней мере её можно автоматизировать и делать на уровне хотя бы того же конфига СУБД однократно при запуске инстанса. А дальше у нас во время работы бесплатно гарантия отсутствия коллизий в распределенной системе без всяких проверок.
Вот поэтому я за ручное распределение всегда. Если вы делаете подобные штуки для гарантий уникальности, то лучше потратить немного времени и вручную задать значение, чем полагаться на то, что оно автоматом окажется не совпадающим с другими.
Приоритеты власть имущих они такие, да)
Мысль на грани идиотии для исключения коллизии в случае многих бэкэндов: небольшую часть из 62 случайных бит разрешить отдавать под фиксированный id бэкэнда (уникальный для каждого из них). Тогда даже если каким-то чудом совпадут временная и случайная часть битов, гарантированно уникальная фиксированная часть обеспечит отсутствие коллизии. Да, теряем на размере случайной части, но, если не увлекаться и условные 6-8 бит позволить откусывать, то выглядит всё ещё не так страшно. Впрочем это, очевидно, будет уже не совсем UUIDv7)
Но есть запрет на их полеты!)
Я так всю жизнь летаю. Но есть нюанс: я пялюсь в одну точку с закрытыми глазами 😁
Не содержит и не инкапсулирует. Кодирует.
Слово "transparent" должно намекать.
И нет. Оно в реальности почти никому не нужно кроме очень узких кейсов.
"L1" (что, кстати, в случае ethernet вообще не совсем верный термин т.к. стандарт не подразумевает строгого разделения на L1 и L2 и формализует одновременно оба уровня) вообще ничего не содержит и не инкапсулирует. Это способ модуляции сигнала.
Хосспаде, любой адекватный фаервол умеет в transparent mode работать. В чем функциональная инновация то?
Ну тут механизм примерно тот же, но мощность мизерная. А вот радиомачты - реально "страшно, вырубай!" 😁
Вообще легко. Идёте поближе к радиомачте на много десятков киловатт излучаемой мощности и буквально дуговой разряд на трос ловите)
Возможно и необходимо ездить в отпуск. Но не на две недели когда у вас кот один сидит
Не бывают. Это химеры с XXY хромосомным набором
Самая ленивая отмазка на свете
Чем дальше читаю, тем больше понимаю, что номер 69 отделу дали не просто так.