Кто сканит акцизные марки в баре? Владелец? Сильно сомневаюсь.
Логистика качественного контрафакта сложна, если вы хотите продавать в тех же объёмах что завод производит, если вы хотите подмешивать паль к оригиналу, то берёте в долю конечных продавцов и они дальше глазом будут смотреть кому паль, кому не паль.
Алкоголь подделывают массово, нет никаких проблем сделать качественное всё, включая закупку пустых бутылок прямо с завода и подкуп технолога по запечатыванию для налаживания схожих линий.
Ну в основном стараются не писать на языке то, что на нём туго выходит. Поэтому кактус никто и не жуёт. Наоборот, наслаждение компактностью и продуманностью языка есть.
Если в бар продукция приходит через логистический центр, то там может отсутствовать такая штука как коробка произведённая в строго определенный бар. Какая была первая к выходу ту и погрузили.
Тем не менее, если завод обяжет логистический центр маркировать точку назначения груза перед отправкой, то затруднить скрытую поставку контрафакта станет труднее.
Единственное во всём этом проблема - как распространить метку на конкретную бутылку в коробке.
Ок. В баре договариваемся с барменом и покупаем аккуратно открытые пустые бутылки, наливаем туда контрафакт и поставляем по ящику в магазы. Как тут поможет блокчейн или PUF не понятно.
Проверка контрафакта при получении в магазе решается элементарно пломбированием коробок листами А4 с заводским QR кодом, содержащим всю необходимую инфу, начиная от этапов производства с пофамильными ответственными, заканчивая куда груз должен был быть доставлен.
На Go не очень правильно писать приложения требующие тяжёлые каркасы. Скажем так, если вам надо написать не микросервис/тулу на Go, то вы должны это очень грамотно архитектурно обосновать прежде чем начинать писать.
Даже бекенд сайта в котором будет чуть больше чем просто API уже начинает вызывать боль, если вы писали подобное до этого на "динамических языках".
Возьмём бутылку с бухлом. Выпиваем бухло, а вместо него заливаем качественный контрафакт и смешанно продаём с настоящим бухлом. Как вы от этого защититесь что блокчейном что PUF непонятно.
и меня не удовлетворило объяснение, что «компьютеры используют двоичную систему счисления, поэтому степень двойки подойдёт лучше всего».
Потому что один из наборов линий мультиплексора и демультиплексора и соответственно шифратора и дешифратора кратно степени 2, а это очень важный компонент железа.
Да, если у вас есть под рукой каталог небесных событий с указанием точного времени их в известном часовом поясе, то действительно можно определить смещение относительно гринвического меридиана.
И даже без часов, хотя простейшие водные соорудить можно, можно примерно прикинуть в каком секторе долгот вы находитесь, хотя вы скорее всего это и так подозревали, не телепортировали же вас на остров.
Но я тут подумал каталог с собой иметь не нужно. Нужно просто соорудить часы. И записывать наблюдаемые астрономические события с указанием времени. Потом эти записи положить в бутылку, если её прибило к берегу и отправить по течению. Если повезёт и бутылку выловят, то потом можно через Stellarium установить точку с которой были сделаны наблюдения.
Если вы оказались в одних трусах на необитаемом острове, то широту можно вычислить ночью по звёздному небу по углу между двумя прямыми палочками, одна из которых будет свисать вниз, а вторая указывать на центр вращения звёзд, который можно или знать или пронаблюдать в течении ночи.
А вот долготу вычислить без часов вообще никак нельзя, ибо она в принципе привязана к Гринвичу.
Ну например есть у меня много массивов элементов, но всегда в каждом будет не больше 1.2 млн штук. И я это выяснил на профилировании. При этом далеко не все из них и до миллиона доходят. Те что выйдут за миллион, будут жрать на 2 млн элементов и большая часть памяти будет в простое.
Действительно, эта информация выясняется по BIN (первые 6 цифр номера) в специализированных DB: https://www.bindb.com/bin-database
А как они определяют, что карта именно кредитная?
Кто сканит акцизные марки в баре? Владелец? Сильно сомневаюсь.
Логистика качественного контрафакта сложна, если вы хотите продавать в тех же объёмах что завод производит, если вы хотите подмешивать паль к оригиналу, то берёте в долю конечных продавцов и они дальше глазом будут смотреть кому паль, кому не паль.
Алкоголь подделывают массово, нет никаких проблем сделать качественное всё, включая закупку пустых бутылок прямо с завода и подкуп технолога по запечатыванию для налаживания схожих линий.
Бармен в баре получает инструкцию при открытии бутылок не сканировать QR код, чтобы потом пробку можно было использовать для контрафакта.
Ну в основном стараются не писать на языке то, что на нём туго выходит. Поэтому кактус никто и не жуёт. Наоборот, наслаждение компактностью и продуманностью языка есть.
Если в бар продукция приходит через логистический центр, то там может отсутствовать такая штука как коробка произведённая в строго определенный бар. Какая была первая к выходу ту и погрузили.
Тем не менее, если завод обяжет логистический центр маркировать точку назначения груза перед отправкой, то затруднить скрытую поставку контрафакта станет труднее.
Единственное во всём этом проблема - как распространить метку на конкретную бутылку в коробке.
Ок. В баре договариваемся с барменом и покупаем аккуратно открытые пустые бутылки, наливаем туда контрафакт и поставляем по ящику в магазы. Как тут поможет блокчейн или PUF не понятно.
Проверка контрафакта при получении в магазе решается элементарно пломбированием коробок листами А4 с заводским QR кодом, содержащим всю необходимую инфу, начиная от этапов производства с пофамильными ответственными, заканчивая куда груз должен был быть доставлен.
На Go не очень правильно писать приложения требующие тяжёлые каркасы. Скажем так, если вам надо написать не микросервис/тулу на Go, то вы должны это очень грамотно архитектурно обосновать прежде чем начинать писать.
Даже бекенд сайта в котором будет чуть больше чем просто API уже начинает вызывать боль, если вы писали подобное до этого на "динамических языках".
Не знаю как сейчас дела обстоят, но 3 года назад GORM было решением вида компромисс на компромисе, и, хотя оно работало, всё-таки переехали на sqlx.
Возьмём бутылку с бухлом. Выпиваем бухло, а вместо него заливаем качественный контрафакт и смешанно продаём с настоящим бухлом. Как вы от этого защититесь что блокчейном что PUF непонятно.
Потому что один из наборов линий мультиплексора и демультиплексора и соответственно шифратора и дешифратора кратно степени 2, а это очень важный компонент железа.
Я не понял как проделав все вышеописанные действия можно узнать долготу. Каталог нужен?
"Таинственный остров"
Да, если у вас есть под рукой каталог небесных событий с указанием точного времени их в известном часовом поясе, то действительно можно определить смещение относительно гринвического меридиана.
И даже без часов, хотя простейшие водные соорудить можно, можно примерно прикинуть в каком секторе долгот вы находитесь, хотя вы скорее всего это и так подозревали, не телепортировали же вас на остров.
Но я тут подумал каталог с собой иметь не нужно. Нужно просто соорудить часы. И записывать наблюдаемые астрономические события с указанием времени. Потом эти записи положить в бутылку, если её прибило к берегу и отправить по течению. Если повезёт и бутылку выловят, то потом можно через Stellarium установить точку с которой были сделаны наблюдения.
Жюль Верн в Детях капитана Гранта не согласится с вами
Если вы оказались в одних трусах на необитаемом острове, то широту можно вычислить ночью по звёздному небу по углу между двумя прямыми палочками, одна из которых будет свисать вниз, а вторая указывать на центр вращения звёзд, который можно или знать или пронаблюдать в течении ночи.
А вот долготу вычислить без часов вообще никак нельзя, ибо она в принципе привязана к Гринвичу.
Ну например есть у меня много массивов элементов, но всегда в каждом будет не больше 1.2 млн штук. И я это выяснил на профилировании. При этом далеко не все из них и до миллиона доходят. Те что выйдут за миллион, будут жрать на 2 млн элементов и большая часть памяти будет в простое.
Интересная тема с удвоением размера. Получается на очень толстых и плавно растущих массивах можно получить почти половинную потерю памяти под резерв.
И тогда надо писать свои кастомные append`ы, которые это дело нивелируют.