очень трудно - там не линейная зависимость потемнения от времени. Скорее очень резкая. (и что самое печальное это зависит больше от бумаги, и она даже может плавать от партии к партии) Но если знатно упороться к калибровкой (которую проводить после каждой заправки новой бумаги из партии), то несколько уровней выжать можно. (все равно надежней использовать дизеринг, даже если какие то 3-4 уровня серого выжать получиться)
напишите про то как сделать в средние века автогенератор на одной электронной лампе с помощью запаивания в стакан ее содержимого и поглощения воздуха методом добавления белого фосфора... особенный смак вас ждет в познании первого простейшего метода получения белого фосфора... после чего в принципе из ардуино и ламы можно сделать нормальное радио - и взорвать нахрен всю военную логистику конкурирующих государств имея хотя бы единственный однонаправленный КВ передатчик километров на 100 (из размышлений что ардуина у вас в средневековье доступна одна) а для приемника в принципе хватит и ламп которые от радиостанции разнесены по гарнизонам во все направления. Стоит ли сомниваться что продемонстрировав такую систему кому надо вы почти наверняка получите карьерно такой уровень, которого и за жизнь не добиться в современности (будете в сопровождении дружины только иногда путешествовать по городам, для оснащения новых точек приема)
то то я смотрю с (в ВОСЕМЬ раз меньшим) 2Кб базовая ATmege328p может зафигачить синтез VGA сигнала софтверно (еще и с периферией в качестве клавиатуры) https://www.youtube.com/watch?v=-ZABNgYb6TQ
Таким образом, движение прямой дискретно — прямая в любой момент времени либо на сайте, либо в нижней точке окружности
к сожалению это следствие ни из чего не ясно. Понятно только что если бы кто-то составил полный order таких событий, их бы можно было проверить. Но нет в описании и намека как как это событие круга должно быть найдено самостоятельно (разве что попиксельно сдвигаясь и еще с каким-то epsilon сравнивая попадания)
важно еще заметить что даже для сетки пикселей это будет выполнятся реже чем вам кажется потому что для того что бы параболы попали все в одну точку (а не пиксель) у них есть довольно ограниченное кол-во групповых наборов координат (которые при рисовке параболы бы приходили точно в один пиксель)
но в любом случае на самом деле "дообработка" большего числа точек даже если такое случится не сильно меняет алгоритм просто алгоритм должен стать чуть более жадным, хотя его жадность и будет реализовываться на практике 1/плотность_точек случаев (point_per_pexel - т.е. очень редко)
смотря какой RAID 0 не отменяет, остальные в том или ином виде обеспечивают прирост отказоустойчивости, разнясь в скоростных характеристиках - для малого кол-ва дисков оченб экономичен RAID 5 - можно поставить 3 диска получить для данных полный объем двух из них, защиту от отказа любого одного из дисков (без сильной потери скорости чтения в момент пока испорченный диск не будет заменен)
кстати т.к. этот каскад использует полуволну для переключения принимая 16Mhz clock он поднимет до 32Mhz скорость пикселей так что на него надо выдать не 16Mhz а 8Mhz с PWM - но два таких делающих 4pin->2pin можно рекурсивно объединить уже тактируя второй уровень от clock и сделать 8pin->2pin т.е. уже учетверение частоты (clock можно вывести на ногу фьюзом) тогда можно даже 480p сделать для 2bpp (может быть круто именно что для терминала) - ну а для особо упорных альтренативным билдером прошивки частоты тактирования можно поднять до 20Mhz (столько ATMega328P допускает) и получить максимально 640p даже (это может привдить к ошибкам работы такой ардуины со сторонними либами, но не со встроенными) // сетка тайлов при этом не увеличится т.к. задана возможностями памяти, но зато тайлы станут 12p 2bpp или 16p 2bpp соответственно
я все удивляюсь почему не сделают програмно аппаратное решение, с мультиплексором для поднятия частоты. Не безызвестный VGAX делает на стоковой (16Mhz) ардуине 120px по ширине (используя при этом только 2 бита на цвет из 8 битов порта), один каскад даже на паре КТ315 легко работает на этих частотах в качестве быстрого и очень дешевого мультиплексора для удвоения частоты (а именно запихивания 4х бит с порта в две жилы с разделением по времени - я это проверял) - да памяти на ардуине маловато 2К это практически полностью уходит на 120х60х2bpp видеобуфер... а с удвоением получиться 240х60х2bpp, но - если реализовать тайловый буфер для символов то 2К это 80х25 - прямо стандартный VGA термнал (ладно там всего 48байт остается, но сделать тогда 40х25 CGA терминал точно можно, причем причем на цветность ограничений уже не будет можно до 4bpp поднять - стандартные 16 CGA цветов) - дальше нахрен 60fps ардуине? Вместо этого можно интерлейсить строки получая между каждой время на какой-то процессинг (вплоть до буферизации строки для ее повторения) в 240p при 40 символах влазит по 6px на тайл (на букву 5px нужен еще 1 px на разделитель) - маловато, но минимально достаточно даже для букв типа Ж Ш - дальше, располагая 40х25 тайловым буфером знаимающим чуть меньше половины памяти при хранении 256 видов тайлов и 6p тайлами (по высоте не ограничены) уже можно всякие аля "змейки"/"пакманы" на этом псевдографически писать. - ПОЧЕМУ до сих пор ни кто не осилил открытыый тайловый движ под ардуину (кроме товарища который писанул на нем свою игрулю) я когда повозился и понял что это возможно (лет 5 назад) понял ну значит скоро появиться... но его все нет. Не уж-то ни у кого из тех кто знает что это можно сделать нет времени???
3. важно еще отмечать что 100% монотонность и не нужна, а лишь в верхней части, она нужна для оптимизаций пагинации БД не более, а в реалиях нашей планеты нельзя закладываться что синхронизация часов на нодах в кластере будет точнее 20мс (так что микросекунда может смениться раз 20 пока страница в БД еще будет принимать похожие микросекунды от соседних нод) - а непредсказуемость же нужна НЕ в счетчике, а просто в последних битах в 64 - и методы конгруэнтно их замапить из логически последовательно возрастающих значений есть.
Так что формат еще может быть лучше. - проблему коллизий во всех реализациях на кластерах вообще стоит решать не раздуванием точности микросекунд, а явным внесением за меткой времени довольно короткого id'шника ноды, тогда не придется плясять с косвенными методами уменьшения коллизий. (единственное для чего это не подойдет, так это p2p кластеры, в остальных случаях все ноды так или иначе сами токенизируют свои доступы друг к другу, вопрос лишь в том что бы дать им уникально различимые токены нод) - Тамстамп же (старший блок бит) стоит резать с точностью 16мс (все равно распределенно гарантировать точнее стабильно нельзя), оставшаяся часть вполне допустимо может использовать переполнение микросекунд, а счетчик логически представляться как их доли, но все ниже 16мс точности с т.з. математики можно конгруэнтно захешировать. - Более того (младший блок бит, вместе с частью переполняемых микросекунд, счетчиком их долей, идентифактором нод, и остальными битами) можно хешировать не только с рандомным хвостом, но и со значащим (MAC-48, соль), просто необходимо их конгруэнтно захэшировать, - по сути ко всем битам хвоста с т.з. главного свойства монотонности предъявляется лишь требование быть уникальными, как это обеспечиться не важно. Поля типа МАC которые могут там лежать лишь для того что бы быть проверенными, могут лежать XOR'ом (или более умными методами поверх друг друга) - трэйд ин тут будет заключаться только в специфике ограничений вашего проекта генерировать на одной ноде множества uuid быстро
- вы банально даже если захешируете биты с залезанием на несколько младших бит микросекунд у вас ничего не сломается... если на тамстамп где то и операются то чаще всего отбрасывая до секунд (может так статься что даже уменьшиться вероятность коллизий, т.к. хорошие хэш функции математически дают гарантии очень низкой вероятности коллизий, - вполне возможно лучше чем худший случай пляски с счетчиками в попытке снизить ее в распределенной архитектуре. Если случился глобальный пик генерации, - Хэш функция же с гарантированной вероятностью равномерно размажет коллизии в интервал нескольким мс)
так то есть реализации который позволяют исключить колизии ВООБЩЕ. (и при том оставить лексографичность порядка она вся обеспечивается таймстампом который отщипывает 48бит из 128, еще 80 остается на рандом) для этого всего то надо ВСЕ ноды сколько одна нода может в миллисекунду навыдать идов? ну 65536 - 16бит еще (и этого достаточно если оно так в среднем, потому что реализация переполнения счетчика может реализоваваться переполнением в микросекунды, только тогда не сбрасывать его по переполнению а более грамотно отслеживать) остается 64бита - сколько у вас нод на проекте может быть ну тысяча... ну 10бит отщипнуть и проинитить номером ноды) - остается 54бита на рандом. Вам мало для безопасности? ну реализуйте еще случайный инкремент счетчика во время выдачи с некоторой плавающей в некотором диапазоне вероятностью, (счетчик можно интерпретировать вообще как доли микросекунд в этом случае, так у вас получиться рассинхрон в пикосекундах), перебирать нужно будет не зная точного момента - вообще исключив коллизии id'ом ноды, становиться сомнительно что UUID'ам нужно придерживаться точности микросекунд даже (вообще тут говорили уже что на точное время из их таймстампов лучше не опираться, у вас между нод оно не точнее 20мс будет плавать) - ну вот и жрем все младшие биты интеллектуальным инкрементером (который обеспечивает точность таймстампа в +-5мс от локальных часов) "случайных" бит будет даже больше чем в UUIDv7 только часть этой случайности будет зависить от плаванья таймстампа (что в общем задачу перебора ни фига не облегчает) а ГПСЧ рандом еще дополнительно лежит так же в хвосте - ну или если вместо рандома хотите вязаться еще и к MAC-48 то он вам в явном виде в UUID ведь не нужен... ну вкладываем его (+6бит соли) в оставшиеся 54бита и берем от них хэш (для всех не знающих целевой МАС они превращаются в 54бита рандома), для атак изнутри целевой локалки, ну все равно радужных таблиц под эту соль нет и времени плавающего не известно
вижу что просто посчитать кол-во двоек в 255! их там 7*1 + 6*2 + 5*4 + 4*8 + 3*16 + 2*32 + 1*64 = 247 штук, а исходя из предположения должно быть 255*log(255) ~ 2038 если же взять 256! - то их стант больше всего на 8 штук,
так что в целом их видимо примерно всегда в ~ logN раз меньше чем должно бы быть, что бы делить "всегда пополам" NlogN способами, так что я бы сказал скорее "дерево чаще всего не строго бинарно" (если вообще близко к разбиению пополам)
вижу грациозное применение формулы приближения Стирлинга, но остается не вполне ясно, почему предполагается ("дерево строго бинарно") что из одного шага сравнения "попарно различимой" пары, которых существует N*(N-1) (далее m) вариантов, алгоритм извлекает уточняющую информацию строго для того, что бы сократить пространство вариантов вдвое. (Хотя закостенелая программерская интуиция и подсказывает что это должно быть так, но математика протестует о превышении предположений)
Есть ведь бородатая задачка найти за два взвешивания одну из 9 монет более легкую. Условие у нас определенно только бинарно может ветвить алгоритм, но разве это гарантирует, что ТО куда оно ветвиться (совершаемые действия) при этом не представляет отсев например двух третей где не лежит нужная перестановка.
ряд П(a) для a = от m до m-N*logN (минимальное кол-во раз-сравнений которое мы предполагаем N*logN - перемножаются значения максимально несущую информацию из оставшихся комбинаций) в этом случае должен бы дать точнехонько N! ... но тогда (даже не вычисляя это численно) можно предположить, что ли зря Стирлинг так мучался?
Это я не к тому что не правильно, а к тому что неясно из краткого вашего пояснения почему это предполагается так. Если согласиться с тем что количество вариантов за шаг проверки уполовинивается в среднем еще проще, то с тем, что оно строго уполовинивается какую бы пару мы не сравнили - уже гораздо сложнее. Это бы означало, что любая пара делит множество пополам разными способами, и для этого в факториале должно бы присутствовать в качестве множителя 2**( N*logN) (очень дохрена двоек сомножителей - есть ли их там столько, сомнительно, хотя чувствуется можно как-то посчитать)
тот случай когда КТ315 мог работать в куче недокументированных режимов, денистора, стабилитрона, термо и даже ИК датчика, но не мог будучи поставленным в типовую схему гарантировать повторяемость, без калибровки номиналов обвязки. Т.е. для любительской схемы кладезь... но для конвейерного производства жуть
современный стационарный процессор вообще работает не так как предполагает его ассемблер... это прямо таки прочертило не всем понятную черту, почему например решение класса "малина" тотально ограничено в работе пинов, в сравнении даже с решением класса "ардуино"
косательно сабжа выглядит ОЧЕНЬ неправдоподобным что юбуст "взломали"... будто взломали собственные админы... ибо... предположим в тг мошенники, но тогда что за команда осталась на родном расширении? которое указует мол идите в тг... получается что осталось то у основной команды??? (назовем их владельцами) видимо только акк хром расширения, в который админы/взломщики оперативно залили обнову с указивкой на тг и тут же натравили орду подписчиков, что б те вынести акк хром расширения - что бы основная команда не успели даже это стереть...
результат? - крайне подозрительные действия админов/взломщиков и потеря управления над аудиторией владельцами...
вердикт - владельцы не оправятся у них жестко увели аудиторию... админы/взломщики - тоже, будучи знавшим виды в корпоративной среде, я бы сказал они откусили кусок который им не проглотить (говорю как разраб кстати) - стандартное поведение молодых и амбициозных пусть быть может как даже знатных и талантливых разрабов... - но явно ни кто из них не менеджер, плюют на репутационые риски, дискредитировали сами себя (если они так поступили с теми кто им очевидно платил деньги, страшно подумать что они уготовят завтра нам этих денег не получив) зная таких я бы сказал скорее менеджеры восстановят репы и новую команду... - а новое расширение кстати просит разрешение к просмотру всех сайтов (глобальный прокси) - я лично не хочу ему доверяться, оно новое и со старта зарекомендовало себя как разрушители...
заминусили за "делаешь vpn через прокси" - это смешение понятий. Если прокси в общем понятии, то частным случаем его является vpn (а не "делается через"), либо еcли имеется ввиду частное понятие умолчально означающее HTTP/S проксирование (вообще тьма протоколов проксирования есть, ну да есть еще универсальный SOCKS4/4.5/5 но в этом случае такой сервис надо кого-то просить поднимать) и становиться неясно предлогается иметь возможность иметь "кого-то там", или предлогается поиметь его комп тайно... т.к. если покупается серв, нет ни какого смысла в проксях, если можно просто кинуть сразу vpn, (а HTTP/SOCKS прокси платные ни кто серьезный не продает - в этом нет смысла)
Концептуально прокси это вообще всегда ТО что открывает метаданные запроса (потому что смысл прокси состоит в том что бы обеспечивать дополнительный функционал из контекста, например кэширование для быстрой локальной отдачи частых данных)
прокси в роли vpn это вообще обрезанная технология живущая сейчас только если вы хотите соседу по локалке кинуть проксю что бы поделить с ним один инет на двоих без роутера (не знаю уж у кого сейчас нет роутера...)
забавнее всего, что повсеместный переход на HTTPS практически исключил полезность прокси серверов для их основной функции, но крупные поставщики контента (ютуб/вконтакт) делают реверс проксирование сами... покупая датацентры во многих регионах (или по всему миру) и перекладывают эту функцию на них, баллансируя обращения к IP-адресам сотен своих региональных зеркал конкретно их и можно банить что будет приводить к "замедлениям"
но проблема в том, что вообще говоря IP'ы и тем более подсети датацентров банить на уровне DNS'ов это смертельно для всего национального IT - вспоминаем сколько РКН нанес ущерба РФ компаниям (и это уже посчитали и атата ему сделали), так что теперь блокировка технически осуществляется только на уровне вашего локального провайдера, который вы и пытаетесь обойти, такими путями, которые банить наиболее болезненно в виду их слишком широкой отраслевой направленности. VPN же трафик в частности такой (ввиду того что им не может прекратить пользоваться как минимум банкинг) он скрывает все пакеты в единственное шифрованное соединение. А HTTP/SOCKS вообще палиться по сигнатурам хотя бы DNS пакетов.
забавный сюжет, но я как то гипотетически думал это почти не реально количественно... в том смысле, что из-за того что в таком процессоре бы пришлось дублировать коды по всяким схемам коррекции (ну это то что в действительности делается для космического класса электроники - что бы любой отдельно взятый бит в нем мог с довольно высокой вероятностью сбоить и алгоритмы бы это исправляли) - в такой схеме вычислитель резко растет в числе физических гейтов... так что конечно людей можно использовать куда эффективнее обучив некоторой более высокоуровневой схеме... например методом конечных разностей считать полиномы (примерно как это делали бедняги математики вычисляющие Пи) и при том придумать коллективную схему с простой коррекцией дублированием расчетов с тремя и более исполнителями (доминирующий в группе ответ считают верным) - на полиномах можно эффективно собрать сразу перцептрон - основной построительный блок НС (в этом ведь у них была проблема,аналитическая неразрешимость задачи трех тел) - вот такая коллективизация будет даже вполне реалистичной (по крайней мере она будет в десятки тысяч раз эффективнее предложенной сценарстами... но кинематографически оно будет больше похоже на то что показано в коллективной рассшифровке Энигмы в к/ф "Игра в имитацию"... более того такой подход реально исторически проверен)
с т.з. отношения к классу процессоров это был бы специализированный процессор с блоком ускорения НС
если кто то питает иллюзии по поводу незыблемости лидеров IDE рынка, то важно включить глобально экономическое мышление, и заметить, что IDE не хлеб (а лишь приправа к нему) - процессы без IDE не остановятся а лишь замедлятся (и кто то будет сильно замотивирован это исправлять ибо пропала конкуренция) - а в условиях когда контора фактически нанесла колоссальный ущерб техпроцессам она в глазах всего свободного мира получит "черную метку"... очень сочувствую, но тот факт что в это время у них на горле стоял гегемон особо ни кто скидку не сделает... бизнес есть бизнес как говориться - при этом IDE лидерство это не ядерный реактор... в наше время полным полно открытого кода который делает ВСЕ то же что и лидерский, просто этот код разрознен и не прошел такого контроля интеграции... - По сути собрать его в единое целое и хорошенько оттестировать не требуется гуру программистов, вполне рядовая agile разработка пусть и объемная, но ни какого RnD нет - такое cейчас можно целиком собрать как из кирпичей, было бы время и желание - лидерская IDE это по большей части тренд сообщества разработчиков... теперь когда он сломан (как и каждый такой раз) сразу возникают как грибы альтернативные проекты
вот увидите через 2-3 года глобальный рынок для JB будет утрачен - разработчики очень честолюбивые люди, они с огромным трудом терпят (если вообще могут) системные конфликты
кстати по этой причине все IT конторы максимально сопротивлялись всяческой отмене - потому что невозможно гадить со 100% прицельностью... обязательно и себе поднасрешь... - JB конечно можно только пожалеть, им очевидно гегемонские рейдеры на горло наступают - ведь JB вышла из РФ... (и она вполне понимает как долго у них есть времени), пока это повторят снова, в условиях свободной экономики
очень трудно - там не линейная зависимость потемнения от времени. Скорее очень резкая. (и что самое печальное это зависит больше от бумаги, и она даже может плавать от партии к партии) Но если знатно упороться к калибровкой (которую проводить после каждой заправки новой бумаги из партии), то несколько уровней выжать можно. (все равно надежней использовать дизеринг, даже если какие то 3-4 уровня серого выжать получиться)
напишите про то как сделать в средние века автогенератор на одной электронной лампе с помощью запаивания в стакан ее содержимого и поглощения воздуха методом добавления белого фосфора... особенный смак вас ждет в познании первого простейшего метода получения белого фосфора... после чего в принципе из ардуино и ламы можно сделать нормальное радио - и взорвать нахрен всю военную логистику конкурирующих государств имея хотя бы единственный однонаправленный КВ передатчик километров на 100 (из размышлений что ардуина у вас в средневековье доступна одна) а для приемника в принципе хватит и ламп которые от радиостанции разнесены по гарнизонам во все направления. Стоит ли сомниваться что продемонстрировав такую систему кому надо вы почти наверняка получите карьерно такой уровень, которого и за жизнь не добиться в современности (будете в сопровождении дружины только иногда путешествовать по городам, для оснащения новых точек приема)
то то я смотрю с (в ВОСЕМЬ раз меньшим) 2Кб базовая ATmege328p может зафигачить синтез VGA сигнала софтверно (еще и с периферией в качестве клавиатуры) https://www.youtube.com/watch?v=-ZABNgYb6TQ
к сожалению это следствие ни из чего не ясно. Понятно только что если бы кто-то составил полный order таких событий, их бы можно было проверить. Но нет в описании и намека как как это событие круга должно быть найдено самостоятельно (разве что попиксельно сдвигаясь и еще с каким-то epsilon сравнивая попадания)
важно еще заметить что даже для сетки пикселей это будет выполнятся реже чем вам кажется потому что для того что бы параболы попали все в одну точку (а не пиксель) у них есть довольно ограниченное кол-во групповых наборов координат (которые при рисовке параболы бы приходили точно в один пиксель)
но в любом случае на самом деле "дообработка" большего числа точек даже если такое случится не сильно меняет алгоритм просто алгоритм должен стать чуть более жадным, хотя его жадность и будет реализовываться на практике 1/плотность_точек случаев (point_per_pexel - т.е. очень редко)
смотря какой RAID 0 не отменяет, остальные в том или ином виде обеспечивают прирост отказоустойчивости, разнясь в скоростных характеристиках - для малого кол-ва дисков оченб экономичен RAID 5 - можно поставить 3 диска получить для данных полный объем двух из них, защиту от отказа любого одного из дисков (без сильной потери скорости чтения в момент пока испорченный диск не будет заменен)
и даже монетизация у этого есть - можно будет примитивные вообще каскады мультиплексора для ардуины за 100-200р толкать как "софтверный VGA щилд"
я вообще полагаю девбордеры могли бы тогда в будущем оснастить таким каскадом осуществляющим 8pin->4pin (порт удвоенной частоты) выводом.
была бы стоковая ардуина с ТАЙЛОВЫМ движком (что то типа пико-8 на ней бы заколосилось)
вот схемотехника мультиплексора которая была проверенна аппаратно на VGAX
https://www.falstad.com/circuit/circuitjs.html?cct=$+1+0.000005+14.235633750745258+54+5+43 t+240+160+240+192+0+1+-9.148915590723593+-4.999999996545533+100 t+240+288+240+256+0+-1+-0.23550799392262536+-0.6538718449901015+100 r+256+192+304+192+0+470 r+256+256+304+256+0+470 r+240+160+240+112+0+30000 r+192+112+192+160+0+50000 w+240+288+192+288+0 w+192+160+192+288+0 w+224+192+128+192+0 R+304+256+320+256+0+1+7+2.5+2.5+0+0.5 R+240+112+320+112+1+2+200+5+0+0+0.5 R+304+192+320+192+0+1+13+2.5+2.5+0+0.5 g+128+192+96+192+0 w+224+192+224+256+0 w+192+112+240+112+0 o+12+32+0+4099+0.0000762939453125+0.0125+0+2+12+3
(сам VGAX при этом особо не перебирался, просто было проверено что пиксели по ширине там нормально можно съежить вдвое)
кстати т.к. этот каскад использует полуволну для переключения принимая 16Mhz clock он поднимет до 32Mhz скорость пикселей так что на него надо выдать не 16Mhz а 8Mhz с PWM
- но два таких делающих 4pin->2pin можно рекурсивно объединить уже тактируя второй уровень от clock и сделать 8pin->2pin т.е. уже учетверение частоты (clock можно вывести на ногу фьюзом) тогда можно даже 480p сделать для 2bpp (может быть круто именно что для терминала)
- ну а для особо упорных альтренативным билдером прошивки частоты тактирования можно поднять до 20Mhz (столько ATMega328P допускает) и получить максимально 640p даже (это может привдить к ошибкам работы такой ардуины со сторонними либами, но не со встроенными)
// сетка тайлов при этом не увеличится т.к. задана возможностями памяти, но зато тайлы станут 12p 2bpp или 16p 2bpp соответственно
я все удивляюсь почему не сделают програмно аппаратное решение, с мультиплексором для поднятия частоты. Не безызвестный VGAX делает на стоковой (16Mhz) ардуине 120px по ширине (используя при этом только 2 бита на цвет из 8 битов порта), один каскад даже на паре КТ315 легко работает на этих частотах в качестве быстрого и очень дешевого мультиплексора для удвоения частоты (а именно запихивания 4х бит с порта в две жилы с разделением по времени - я это проверял)
- да памяти на ардуине маловато 2К это практически полностью уходит на 120х60х2bpp видеобуфер... а с удвоением получиться 240х60х2bpp, но - если реализовать тайловый буфер для символов то 2К это 80х25 - прямо стандартный VGA термнал (ладно там всего 48байт остается, но сделать тогда 40х25 CGA терминал точно можно, причем причем на цветность ограничений уже не будет можно до 4bpp поднять - стандартные 16 CGA цветов)
- дальше нахрен 60fps ардуине? Вместо этого можно интерлейсить строки получая между каждой время на какой-то процессинг (вплоть до буферизации строки для ее повторения) в 240p при 40 символах влазит по 6px на тайл (на букву 5px нужен еще 1 px на разделитель) - маловато, но минимально достаточно даже для букв типа Ж Ш
- дальше, располагая 40х25 тайловым буфером знаимающим чуть меньше половины памяти при хранении 256 видов тайлов и 6p тайлами (по высоте не ограничены) уже можно всякие аля "змейки"/"пакманы" на этом псевдографически писать.
- ПОЧЕМУ до сих пор ни кто не осилил открытыый тайловый движ под ардуину (кроме товарища который писанул на нем свою игрулю) я когда повозился и понял что это возможно (лет 5 назад) понял ну значит скоро появиться... но его все нет. Не уж-то ни у кого из тех кто знает что это можно сделать нет времени???
3. важно еще отмечать что 100% монотонность и не нужна, а лишь в верхней части, она нужна для оптимизаций пагинации БД не более, а в реалиях нашей планеты нельзя закладываться что синхронизация часов на нодах в кластере будет точнее 20мс (так что микросекунда может смениться раз 20 пока страница в БД еще будет принимать похожие микросекунды от соседних нод)
- а непредсказуемость же нужна НЕ в счетчике, а просто в последних битах в 64 - и методы конгруэнтно их замапить из логически последовательно возрастающих значений есть.
Так что формат еще может быть лучше.
- проблему коллизий во всех реализациях на кластерах вообще стоит решать не раздуванием точности микросекунд, а явным внесением за меткой времени довольно короткого id'шника ноды, тогда не придется плясять с косвенными методами уменьшения коллизий. (единственное для чего это не подойдет, так это p2p кластеры, в остальных случаях все ноды так или иначе сами токенизируют свои доступы друг к другу, вопрос лишь в том что бы дать им уникально различимые токены нод)
- Тамстамп же (старший блок бит) стоит резать с точностью 16мс (все равно распределенно гарантировать точнее стабильно нельзя), оставшаяся часть вполне допустимо может использовать переполнение микросекунд, а счетчик логически представляться как их доли, но все ниже 16мс точности с т.з. математики можно конгруэнтно захешировать.
- Более того (младший блок бит, вместе с частью переполняемых микросекунд, счетчиком их долей, идентифактором нод, и остальными битами) можно хешировать не только с рандомным хвостом, но и со значащим (MAC-48, соль), просто необходимо их конгруэнтно захэшировать, - по сути ко всем битам хвоста с т.з. главного свойства монотонности предъявляется лишь требование быть уникальными, как это обеспечиться не важно. Поля типа МАC которые могут там лежать лишь для того что бы быть проверенными, могут лежать XOR'ом (или более умными методами поверх друг друга)
- трэйд ин тут будет заключаться только в специфике ограничений вашего проекта генерировать на одной ноде множества uuid быстро
- вы банально даже если захешируете биты с залезанием на несколько младших бит микросекунд у вас ничего не сломается... если на тамстамп где то и операются то чаще всего отбрасывая до секунд (может так статься что даже уменьшиться вероятность коллизий, т.к. хорошие хэш функции математически дают гарантии очень низкой вероятности коллизий, - вполне возможно лучше чем худший случай пляски с счетчиками в попытке снизить ее в распределенной архитектуре. Если случился глобальный пик генерации, - Хэш функция же с гарантированной вероятностью равномерно размажет коллизии в интервал нескольким мс)
так то есть реализации который позволяют исключить колизии ВООБЩЕ. (и при том оставить лексографичность порядка она вся обеспечивается таймстампом который отщипывает 48бит из 128, еще 80 остается на рандом) для этого всего то надо ВСЕ ноды
сколько одна нода может в миллисекунду навыдать идов? ну 65536 - 16бит еще (и этого достаточно если оно так в среднем, потому что реализация переполнения счетчика может реализоваваться переполнением в микросекунды, только тогда не сбрасывать его по переполнению а более грамотно отслеживать) остается 64бита
- сколько у вас нод на проекте может быть ну тысяча... ну 10бит отщипнуть и проинитить номером ноды)
- остается 54бита на рандом. Вам мало для безопасности? ну реализуйте еще случайный инкремент счетчика во время выдачи с некоторой плавающей в некотором диапазоне вероятностью, (счетчик можно интерпретировать вообще как доли микросекунд в этом случае, так у вас получиться рассинхрон в пикосекундах), перебирать нужно будет не зная точного момента
- вообще исключив коллизии id'ом ноды, становиться сомнительно что UUID'ам нужно придерживаться точности микросекунд даже (вообще тут говорили уже что на точное время из их таймстампов лучше не опираться, у вас между нод оно не точнее 20мс будет плавать) - ну вот и жрем все младшие биты интеллектуальным инкрементером (который обеспечивает точность таймстампа в +-5мс от локальных часов) "случайных" бит будет даже больше чем в UUIDv7 только часть этой случайности будет зависить от плаванья таймстампа (что в общем задачу перебора ни фига не облегчает) а ГПСЧ рандом еще дополнительно лежит так же в хвосте
- ну или если вместо рандома хотите вязаться еще и к MAC-48 то он вам в явном виде в UUID ведь не нужен... ну вкладываем его (+6бит соли) в оставшиеся 54бита и берем от них хэш (для всех не знающих целевой МАС они превращаются в 54бита рандома), для атак изнутри целевой локалки, ну все равно радужных таблиц под эту соль нет и времени плавающего не известно
вижу что просто посчитать кол-во двоек в 255!
их там 7*1 + 6*2 + 5*4 + 4*8 + 3*16 + 2*32 + 1*64 = 247 штук,
а исходя из предположения должно быть 255*log(255) ~ 2038
если же взять 256! - то их стант больше всего на 8 штук,
так что в целом их видимо примерно всегда в ~ logN раз меньше чем должно бы быть, что бы делить "всегда пополам" NlogN способами, так что я бы сказал скорее "дерево чаще всего не строго бинарно" (если вообще близко к разбиению пополам)
вижу грациозное применение формулы приближения Стирлинга, но остается не вполне ясно, почему предполагается ("дерево строго бинарно") что из одного шага сравнения "попарно различимой" пары, которых существует N*(N-1) (далее m) вариантов, алгоритм извлекает уточняющую информацию строго для того, что бы сократить пространство вариантов вдвое. (Хотя закостенелая программерская интуиция и подсказывает что это должно быть так, но математика протестует о превышении предположений)
Есть ведь бородатая задачка найти за два взвешивания одну из 9 монет более легкую. Условие у нас определенно только бинарно может ветвить алгоритм, но разве это гарантирует, что ТО куда оно ветвиться (совершаемые действия) при этом не представляет отсев например двух третей где не лежит нужная перестановка.
ряд П(a) для a = от m до m-N*logN (минимальное кол-во раз-сравнений которое мы предполагаем N*logN - перемножаются значения максимально несущую информацию из оставшихся комбинаций) в этом случае должен бы дать точнехонько N!
... но тогда (даже не вычисляя это численно) можно предположить, что ли зря Стирлинг так мучался?
Это я не к тому что не правильно, а к тому что неясно из краткого вашего пояснения почему это предполагается так. Если согласиться с тем что количество вариантов за шаг проверки уполовинивается в среднем еще проще, то с тем, что оно строго уполовинивается какую бы пару мы не сравнили - уже гораздо сложнее. Это бы означало, что любая пара делит множество пополам разными способами, и для этого в факториале должно бы присутствовать в качестве множителя 2**( N*logN) (очень дохрена двоек сомножителей - есть ли их там столько, сомнительно, хотя чувствуется можно как-то посчитать)
тот случай когда КТ315 мог работать в куче недокументированных режимов, денистора, стабилитрона, термо и даже ИК датчика, но не мог будучи поставленным в типовую схему гарантировать повторяемость, без калибровки номиналов обвязки. Т.е. для любительской схемы кладезь... но для конвейерного производства жуть
современный стационарный процессор вообще работает не так как предполагает его ассемблер... это прямо таки прочертило не всем понятную черту, почему например решение класса "малина" тотально ограничено в работе пинов, в сравнении даже с решением класса "ардуино"
косательно сабжа выглядит ОЧЕНЬ неправдоподобным что юбуст "взломали"... будто взломали собственные админы... ибо... предположим в тг мошенники, но тогда что за команда осталась на родном расширении? которое указует мол идите в тг... получается что осталось то у основной команды??? (назовем их владельцами) видимо только акк хром расширения, в который админы/взломщики оперативно залили обнову с указивкой на тг и тут же натравили орду подписчиков, что б те вынести акк хром расширения - что бы основная команда не успели даже это стереть...
результат? - крайне подозрительные действия админов/взломщиков и потеря управления над аудиторией владельцами...
вердикт - владельцы не оправятся у них жестко увели аудиторию...
админы/взломщики - тоже, будучи знавшим виды в корпоративной среде, я бы сказал они откусили кусок который им не проглотить (говорю как разраб кстати) - стандартное поведение молодых и амбициозных пусть быть может как даже знатных и талантливых разрабов...
- но явно ни кто из них не менеджер, плюют на репутационые риски, дискредитировали сами себя (если они так поступили с теми кто им очевидно платил деньги, страшно подумать что они уготовят завтра нам этих денег не получив) зная таких я бы сказал скорее менеджеры восстановят репы и новую команду...
- а новое расширение кстати просит разрешение к просмотру всех сайтов (глобальный прокси)
- я лично не хочу ему доверяться, оно новое и со старта зарекомендовало себя как разрушители...
только в linux'е в той стране где сайт не забанен...
заминусили за "делаешь vpn через прокси" - это смешение понятий. Если прокси в общем понятии, то частным случаем его является vpn (а не "делается через"), либо еcли имеется ввиду частное понятие умолчально означающее HTTP/S проксирование (вообще тьма протоколов проксирования есть, ну да есть еще универсальный SOCKS4/4.5/5 но в этом случае такой сервис надо кого-то просить поднимать) и становиться неясно предлогается иметь возможность иметь "кого-то там", или предлогается поиметь его комп тайно... т.к. если покупается серв, нет ни какого смысла в проксях, если можно просто кинуть сразу vpn, (а HTTP/SOCKS прокси платные ни кто серьезный не продает - в этом нет смысла)
Концептуально прокси это вообще всегда ТО что открывает метаданные запроса (потому что смысл прокси состоит в том что бы обеспечивать дополнительный функционал из контекста, например кэширование для быстрой локальной отдачи частых данных)
прокси в роли vpn это вообще обрезанная технология живущая сейчас только если вы хотите соседу по локалке кинуть проксю что бы поделить с ним один инет на двоих без роутера (не знаю уж у кого сейчас нет роутера...)
забавнее всего, что повсеместный переход на HTTPS практически исключил полезность прокси серверов для их основной функции, но крупные поставщики контента (ютуб/вконтакт) делают реверс проксирование сами... покупая датацентры во многих регионах (или по всему миру) и перекладывают эту функцию на них, баллансируя обращения к IP-адресам сотен своих региональных зеркал конкретно их и можно банить что будет приводить к "замедлениям"
но проблема в том, что вообще говоря IP'ы и тем более подсети датацентров банить на уровне DNS'ов это смертельно для всего национального IT - вспоминаем сколько РКН нанес ущерба РФ компаниям (и это уже посчитали и атата ему сделали), так что теперь блокировка технически осуществляется только на уровне вашего локального провайдера, который вы и пытаетесь обойти, такими путями, которые банить наиболее болезненно в виду их слишком широкой отраслевой направленности. VPN же трафик в частности такой (ввиду того что им не может прекратить пользоваться как минимум банкинг) он скрывает все пакеты в единственное шифрованное соединение. А HTTP/SOCKS вообще палиться по сигнатурам хотя бы DNS пакетов.
забавный сюжет, но я как то гипотетически думал это почти не реально количественно... в том смысле, что из-за того что в таком процессоре бы пришлось дублировать коды по всяким схемам коррекции (ну это то что в действительности делается для космического класса электроники - что бы любой отдельно взятый бит в нем мог с довольно высокой вероятностью сбоить и алгоритмы бы это исправляли) - в такой схеме вычислитель резко растет в числе физических гейтов... так что конечно людей можно использовать куда эффективнее обучив некоторой более высокоуровневой схеме... например методом конечных разностей считать полиномы (примерно как это делали бедняги математики вычисляющие Пи) и при том придумать коллективную схему с простой коррекцией дублированием расчетов с тремя и более исполнителями (доминирующий в группе ответ считают верным) - на полиномах можно эффективно собрать сразу перцептрон - основной построительный блок НС (в этом ведь у них была проблема,аналитическая неразрешимость задачи трех тел) - вот такая коллективизация будет даже вполне реалистичной (по крайней мере она будет в десятки тысяч раз эффективнее предложенной сценарстами... но кинематографически оно будет больше похоже на то что показано в коллективной рассшифровке Энигмы в к/ф "Игра в имитацию"... более того такой подход реально исторически проверен)
с т.з. отношения к классу процессоров это был бы специализированный процессор с блоком ускорения НС
если кто то питает иллюзии по поводу незыблемости лидеров IDE рынка, то важно включить глобально экономическое мышление, и заметить, что IDE не хлеб (а лишь приправа к нему)
- процессы без IDE не остановятся а лишь замедлятся (и кто то будет сильно замотивирован это исправлять ибо пропала конкуренция)
- а в условиях когда контора фактически нанесла колоссальный ущерб техпроцессам она в глазах всего свободного мира получит "черную метку"... очень сочувствую, но тот факт что в это время у них на горле стоял гегемон особо ни кто скидку не сделает... бизнес есть бизнес как говориться
- при этом IDE лидерство это не ядерный реактор... в наше время полным полно открытого кода который делает ВСЕ то же что и лидерский, просто этот код разрознен и не прошел такого контроля интеграции...
- По сути собрать его в единое целое и хорошенько оттестировать не требуется гуру программистов, вполне рядовая agile разработка пусть и объемная, но ни какого RnD нет - такое cейчас можно целиком собрать как из кирпичей, было бы время и желание
- лидерская IDE это по большей части тренд сообщества разработчиков... теперь когда он сломан (как и каждый такой раз) сразу возникают как грибы альтернативные проекты
вот увидите через 2-3 года глобальный рынок для JB будет утрачен
- разработчики очень честолюбивые люди, они с огромным трудом терпят (если вообще могут) системные конфликты
кстати по этой причине все IT конторы максимально сопротивлялись всяческой отмене
- потому что невозможно гадить со 100% прицельностью... обязательно и себе поднасрешь...
- JB конечно можно только пожалеть, им очевидно гегемонские рейдеры на горло наступают
- ведь JB вышла из РФ... (и она вполне понимает как долго у них есть времени), пока это повторят снова, в условиях свободной экономики