Так ок, у нас есть DEK (симметричный), есть KEK (симметричный) по KDF, мы зашифровали клиентский приватный ключ (асимметричный) с помощью KEK (симметричный) по PBKDF2 (пароль знает только пользователь) допустим... Но что с нашим приватным ключом (асимметричный)? Он так же в открытую лежит на статическом хостинге? Или он тоже зашифрован, но данные расшифровки лежат рядом?
В этой схеме просто теряется смысл, по сути любой клиент имеет у себя в наличии сразу два приватных ключа... И вектор атаки очевидно - кража зашифрованного клиентского ключа + пароля для его расшифровки (соц. инженерия, фишинг, зловредные расширения), а серверный приватный ключ уже есть.
Тут без динамической части ну никак не обойтись в принципе, кто-то должен выступать второй стороной ответственной за ключ и хранящей его в тайне.
class может наследовать только классы, прототипом же может выступать любой объект
Вот тут я поправлю, класс может наследовать не только классы, но и функции.
Дело в том, что class это конструкция, которая по факту выполняет роль синтаксического сахара. Внутри это функция с прототипом равным содержимому класса. Вот например:
class User {
constructor(name, age) {
this.name = name;
this.age = age;
}
sayHello() {
console.log(`Hello, my name is ${this.name}!`);
}
}
Если переписать без конструкции class вы получите этого:
function User(name, age) {
this.name = name;
this.age = age;
}
User.prototype = {
constructor: User,
sayHello() {
console.log(`Hello, my name is ${this.name}!`);
}
};
Если проверить тип класса из первого примера вы увидите, что результатом будет function.
По этому фактически классы (функции) наследуют функции.
Вообще давайте будем откровенны TOTP (RFC 6238 - май 2011) само по себе является расширением HOTP (RFC 4226 - декабрь 2005), которое просто заменяет инкрементируемый счётчик на временные интервалы (тот же счётчик, только автоматически инкрементируемый в соответствии с временем).
Сама суть HOTP/TOTP в том, что мы просто на просто хешируем счетчик с применением секрета, причём да изначально речь ведётся относительно HMAC-SHA1 и базово библиотеки/приложения HOTP/TOTP реализуют именно его (ну может +SHA256, если повезёт), однако допустимо использование HMAC-SHA256/HMAC-SHA512 да в целом любых HMAC-* хоть HMAC-SHA3-256. Т.е. уже один TOTP другому TOTP рознь как минимум из-за того, что можно менять алгоритм хеширования при сохранении общих принципов.
Далее у нас во всей этой теме с генерацией одноразового кода присутствует секрет, а им нужно обменяться! В простом случае этот секрет просто закодирован в base64 в uri в QR коде. А что если можно поделиться секретом более безопасно, даже явно не раскрывая секрета? Например, можно использовать ECDH с эфемерными ключами - всего две временные пары ключей, в открытую передаются только открытые части, но по результату у обеих сторон есть секрет.
А ещё можно сам одноразовый код отправлять, либо как уже упомянуто по клику на PUSH уведомление (на соответствующую сессионную ссылку из метаданных пуша) или эту ссылку можно ещё показать пользователю в виде QR кода (кстати, а вот и подход Яндекса).
А ещё самое банальное при всей совместимости и базовой реализации - не все приложения базово поддерживающие TOTP умеют в отличные от 6 значений коды, или даже в буквенные коды. (Ладно буквенные коды будем считать расширением, но возможность генерить коды более 6 знаков заложена ещё в HOTP, главное влезть динамическим окном в размерность хеша).
Так вот это к чему я, своё приложение это возможность поменять алгоритм хеширования (даже на экзотический) и/или поменять/обезопасить обмен секретом, а может даже облегчить жизнь пользователю, самостоятельно отправляя одноразовый код на сессионную ссылку из QR. И в определённых случаях это имеет достаточный смысл (сделать явно не как у всех - HMAC-SHA1/256 + QR с секретом).
А на счёт Whatsapp, Telegram - там OTP, но не TOTP/HOTP. У Google Messenger кстати тоже QR код с временным одноразовым значением, но он не для авторизации в аккаунте, а для пеиринга устройств во внутреннем pubsub.
Кстати на счёт Google, да TOTP на доп. факторе у них вполне стандартный, но Google точно так же как Яндекс экспериментирует с собственными транспортами для уже Passkeys (раньше Secure key). TOTP в данном случае уже не так интересен, особенно когда есть по свежее и по интереснее подход полностью на ключах.
А вообще конечно с развитием FIDO/WebAuthn и формированием Passkeys вот этот TOTP может стать просто на просто резервным способом (как одноразовые коды на бумажке) на случай потери доступа к материалам ключей (хотя они ведь будут синхронизироваться).
Просто интересно, если вам вдруг скажут, что ваши слова были неуместны, вы тоже будете обращаться к гражданскому кодексу?
Ну скажут и скажут, что толку слова уже произнесены, возможно в следующий раз такой ситуации не случится.
Тогда к чему этот разговор про пользовательское соглашение? Речь об эмоциональном восприятии программы, естественно, здесь никто никому ничего не обязан юридически.
В этом и суть мы говорим о программе/сервисе предоставляемом на конкретных условиях, условия заранее оглашены, другое дело на сколько человек в них вдавался. Далее эмоциональное тон программы формируется под конкретную аудиторию, а точнее часть этой аудитории (если хотите "среднее по больнице"), если этот тон не меняется в программе, значит всё хорошо (эмоциональное восприятие соответствует заложенному ожиданию) и всё работает как ожидают разработчики/компания владелец. То, что каждый уже по разному может воспринять тон и это вызовет какую-то не ожидаемую разработчиками эмоциональную реакцию уж извините, но это как с багами да и в целом идеалами - всем угодить не возможно т.к. как минимум все возможные случаи предусмотреть просто не выйдет.
А дальше говорил про нейтральный язык. И нет, нейтральное обращение обидеть не может. Просто по определению: оно нейтральное.
Какое бы нейтральное общение не было, но оно тоже может обидеть, мало говорить сухо/нейтрально без эмоциональной окраски, нужно ещё выбирать формулировки в целом учитывать контекст. Просто банально пример такой: Вот придёт к вам абсолютно нейтральная бумажка об отъеме земли в пользу государства с целью дальнейшей передачи, например РЖД для строительства новой очень важной федеральной магистрали, я сомневаюсь, что она вызовет у вас исключительно радостные эмоции или вообще не вызовет никаких.
Если во всяких мотивирующих лозунгах (в голове крутится "твори, выдумывай, пробуй!") такое обращение выглядит вполне уместным, то при продаже – вряд ли.
Но ведь это же "твори, выдумывай, пробуй!" может быть и при продаже, даже не то что в голове крутиться, а именно так и продаваться.
В общем, есть роли и есть принятый для этих ролей стиль общения. Идти против него неразумно, создаёшь о себе плохое впечатление.
В этом плане у нас с вами нет противоречий на самом деле. Всё опять таки сходится к конечному общему образу бренда (если возвращаться к компаниям), просто вот те же уже упомянутые мной Nike могут спокойно использовать тон на "ты" именно в формате "твори, выдумывай, пробуй!" и это воспринимается вполне естественно причём они именно продают в первую очередь.
незнакомец резко вторгся в моё личное пространство
О боже незнакомец в час пик в Московском метро не так посмотрел на меня, а ещё в толкучке задел, грубейшим образом нарушив моё личное пространство.
По резкому сокращению дистанции с клиентом: речи о том, что так должны делать все нет, но и нет речи, что так не может никто делать. Есть сферы где сокращение дистанции вполне может быть быстрым, есть где так не выйдет. В конце концов люди разные и по разному могут реагировать на любые вещи, но всё же упор делается на преобладающую массу.
В любом случае, напоминаю, что мои сообщения описывают тон общения бренда с клиентом в рамках построения имиджа/характера бренда в купе со всеми остальными подходами и т.д. Общая составляющая играет очень важную роль, если общий образ бренда не совместим с обращением на "ты" естественно такой тон будет восприниматься не очень хорошо.
Задача в сокращении дистанции общения, повышение доверия и привлекательности не более.
К тому же грубо говоря все притворяются теми кем не являются хотя бы немного. Это как в любой сфере обслуживания необходимо выглядеть дружелюбно/вежливо/привлекательно для клиента в не зависимости от фактического отношения. По сути все сервисы/ПО своего рода такая же сфера обслуживания (естественно со своими целями).
Любые лишние ёрничанья могут оказаться неуместными в какой-либо ситуации (а мы не знаем, какая ситуация у пользователя — она может быть абсолютно любая).
На этот случай в пользовательском соглашении обычно прописана замечательная строчка про "сервис предоставляется КАК ЕСТЬ и может не соответствовать ожиданиям пользователя", ну естественно и не обязаны соответствовать любым ожиданиям, а то знаете ли, даже на "карцелярит" можно обидеться.
В приводимом мной случае "ты" идёт вместе с дружелюбностью, показывается равенство и/или обращение к одному конкретному лицу (персонализация), а не группе лиц. Всё же с друзьями мы обычно общаемся в основном на "ты". Обычно на "вы" мы обращаемся с целью показать уважение (по отношению к старшим/не знакомым или в официально-деловой обстановке) и/или охватить большую группу собеседников (тем самым отказываясь от персонализации).
Конечно "ты" может использоваться как уничижение, кем-то кто считает себя сильнее (не обязательно физически). Хотя и "вы" может быть применено в достаточно уничижительном предложении/контексте, что всё уважение просто теряет свой смысл и не играет роли. В этом плане оба обращения в целом одинаковы.
Однако возвращаясь к компаниям, в подавляющем большинстве они позиционируют себя уважительно/дружелюбно, ведь основная цель это привлечение клиентов (в основном с целью заработка). Конечно существуют отдельные можно сказать "концептуальные" бренды, которые строят свой имидж от противоположного, но в основном такие бренды скорее местечковые и имеют очень узкую клиентскую базу.
Я также не согласен со статьёй т.к. в статье упор делается только на официально-деловой, сухой, если хотите язык. И что главное этот сухой язык позиционируется как единственно верный. Просто для примера, представьте если все интерфейсы, все сайты будут применять, например юридический язык и трактовки. На сколько будет удобно пользоваться таким ПО? Даже нет, задам такой вопрос: как много людей постоянно читают и перечитывают разные юридические документы сервисов и ПО (Terms of Service, EULA, Privacy Policy, Cookies Policy, etc.)?
Сухой язык имеет место быть и имеет определённые контексты применения, на которые кстати в статье есть ссылки как усиление доводов (Та же покупка билета или банковский перевод). Однако, у каждой компании имеется свой бренд, даже так у каждого продукта может быть самостоятельный бренд. Бренд это позиционирование компании/продукта, можно сказать имидж/характер, который строится из множества факторов: сфера работы, сфера применения, контексты применения, логотипы, цветовые гаммы, текстовые стилистики (тон общения с клиентами) и т.д. Главная задача при построении бренда - добиться доверия, стать привлекательным для клиента.
Так вот многие компании для брендов выбирают дружелюбный стиль/тон общения, отсюда кстати и обращения на "ты", а не "вы", те же простые разговорные и смягчающие приёмы по типу "Gah" (Эх), "Oops" (Упс), "Hi" (Привет) и т.д. Вот для примера два бренда, которые применяют именно дружелюбный тон: Uber, Nike. Более того даже банки применяют дружелюбный стиль, например тот же Сбербанк использует дружелюбный стиль в молодежных продуктах и продуктах для детей, обращаясь на "ты" и это не из-за того, что Сбербанк "взрослый дядечка" в отношении с ними, а из-за того, что он их друг/сверстник (на равне).
Тут скорее должен быть вопрос как себя позиционирует компания или как она позиционирует конкретный продукт, какой контекст взаимодействия, на сколько контекст допускает свободный стиль. И главное нужно так же разделять зоны влияния, примеры с браузерами используют дружелюбный язык т.к. они в данном случае являются своего рода помощниками/посредниками с которыми вы общаетесь повседневно, они вам помогают получать доступ к различным сайтам, большая часть которых всё же имеет развлекательный характер.
"Мнение компании" - это, в конечном итоге, просто инкапсуляция мнения точно таких же людей, как и те, которым вы это мнение противопоставляете.
Только мнение людей из компании как правило подкреплено конкретным видением на позиционирование своего бренда и проведённой аналитикой в т.ч. по фокус группам. Если интерфейс использует дружелюбный язык и обращается на "ты", значит аудиторию (или большую её часть) всё устраивает, более того интересующие показатели достигают желаемых значений.
Если не ошибаюсь этот редирект будет работать 3 года (гарантия трафика для Дзена), столько же Яндекс не может вносить кардинальных изменений в DeliveryClub как бренд и сервис (гарантия существования и "конкуренции"). Могу предположить, что к концу этого гарантийного срока может появиться покупатель для DeliveryClub (тот же Сбер) либо же со временем он сольётся с Я.Едой.
URL это URI. В URI обязательными частями являются только scheme и path, части authority, query, fragment опциональные. Если опциональные части не проходят по формату - они игнорируются, если точнее интерпретируются как часть обязательной части (при прохождение по требованиям этой части). Тоже самое происходит и в формате опциональной части authority (тут обязательный только host).
Получается данный URI разбивается так:
host
┌─┴┐
http://http://http://@http://http://?http://#http://
└─┬┘ └──┬──┘└──────────┬───────────┘└───┬──┘└───┬──┘
scheme authority path query fragment
В итоге поведение Python, JavaScript, Go, .NET и браузеров является правильным и следует RFC (браузеры в дополнение ещё убирают лишние части, собственно по этому "съелось" двоеточие у не обязательного порта), поведение curl не соответствует RFC в полной мере.
Давайте предположим, что люди нацелены на добро в первую очередь. Ваш сотрудник или автор статьи в интернете критикует технологии не для того, чтобы ущемить вашу волю и право выбора.
Если бы все были идеальны и всегда желали добра, а главное всегда критиковали технологии с единственной благой целью, но увы нет. Да даже если так, желая только добра можно столько всего кардинально противоположного наворотить, что выглядеть будет как целенаправленное вредительство.
Конкретно в этой статье посыл именно из ряда, "ради добра прям советую даже не используй это", хоть конечно критика затрагивала не только сам Go, другим языкам тоже досталось, однако главный объект критики в статье именно Go и что главное по всему тексту он прям вообще ни для чего не годится, только вот Google и вон те ещё ребята.
Критик делится собственным опытом решения проблем, часто с помощью альтернатив, чтобы в конечном итоге экономить вам время в поиске истины.
Самое интересное, у критика решение проблем сошлось только к самому простому решению - предложение альтернативы, проще этого разве что вообще сказать "вам это не нужно". Какого-то прям глубокого разбора "проблем" и их решения тут не было.
Более того автор в тексте ссылается на команду разработчиков, говорит что они профи в Go, шарят за внутрянку и прочее, по этому им можно и простительно использовать Go. А ведь этой ссылкой автор признаёт, что он далеко не такой же профи в Go, что внутрянку он не изучал, в сравнении вон с теми ребятами. Но при этом его позиция выстроена так, как будто он разобрался в недрах Go и предлагаемой альтернативы на столько, что вот такие есть слабые места и вот почему так получилось, что они слабые.
Опять таки как я уже писал, ровно таким же образом можно критиковать вообще любую технологию, посмотрев на неё сверху. Однако айсберг маленький только над водой, а почему у айсберга такая форма, а не другая и прочее это вообще не нужно разбирать как будто и главное это вообще ни на что не влияет.
Часто технологии применяются потому, что они созданы компаниями, считающимися авторитетными. Без каких-либо объективных причин десятки проектов содержат, но не могут использовать эффективно: круглые люки, микросервисы, ангуляры, куберы и т.д.
Давайте тогда быть честными, частовсегда технологии созданы кем-то и как правило это крупные компании/организации, считающиеся авторитетными. И что главное почему-то этими технологиями все пользуются только опираясь на авторитетность создателей без каких то других объективных причин и это не в десятках проектов, а буквально в каждом и ни где это не используется максимально эффективно.
Критические замечания направлены на разрушение этой апелляции к авторитету, чтобы каждый мог реально сам решить что использовать, на основе объективных аргументов, а не популярности компании изготовителя.
Если мы будем так разрушать каждую апелляцию к авторитету на право и на лево, тогда каждый должен полностью независимо с нуля вести сначала изучение физических объектов и процессов, потом самостоятельно на выше изученном создавать свои вычислительные машины, концепции (почему вообще байт код и почему двоичный?), языки и т.д. Это будет уже не прогресс, а топтание на одном месте, даже больше похоже на челлендж из разряда найди все возможные способы достижения цели. Ну серьёзно.
Особенно это актуально для разработчиков, которые занимают рядовые позиции и вынуждены работать с тем, что им спускают архитекторы и технические директора, которые эмоционально оценивают своё производство на уровне гугла, амазона или фейсбука.
А это уже про обратную связь, вы ведь можете пообщаться с архитектором, с тех. диром, предложить свой взгляд, приведя достаточно убедительные аргументы, если вы действительно разбираетесь в том почему ваше предложение лучше выбранного.
Поймите, даже архитекторы и технические директора не всё знают, по тому, что действительно прям каждую технологию потрогать в принципе не возможно. Ну и главное, как будто рядовые разработчики совсем не эмоциональные и без каких либо амбиций...
Ещё раз я согласился с тем, что статьи такого формата имеют место быть, но и указал недостаток такого формата, в первую очередь это негативный окрас по отношению к рассматриваемой технологии с посылом "не трогай", потеря объективности т.к. в погоне за поиском и приведением недостатков приводятся универсальные недостатки, применимые ко многим технологиям сразу в т.ч. к тем, которые тут же позиционируются как альтернатива.
Ещё раз, автор попробовал, нашел какие-то не устраивающие его места, решил поделиться своим опытом работы с технологией, ок покажи конкретные примеры, без ссылок на абстрактные случаи. Если у тебя и правда добрая цель и ты делишься опытом, а не просто своим негативным отношением, то поделись решением, если нашел его, не нашел решение, ну хотя бы разобрался почему тут так, а не как ожидалось, расскажи об этом.
В целом соглашусь смысл статей вполне имеет место быть, только мне лично одно не нравится в этих статьях - утверждение с посылом "вы не гугл, вам это не светит, не нужно и вообще сидите на своём месте".
Т.е. ровно так же можно про любой язык говорить да и в целом про библиотеку/инструмент/подход/идею/etc. Хоть про Rust из разряда у вас не Servo, не блокчейн/etс и вообще не экспериментируйте, вон есть C. Зачем вам TypeScript, вы не Microsoft. Не используйте React, вы не Facebook. У вас JavaScript, ой ну его нафиг прототипное наследование... К чему придраться и на чём сделать упор подобной критики всегда найдётся.
В общем посыл не из разряда изучите/оцените, если подходит применяйте, а из разряда даже если вам подошло, вы не гугл - это не для вас, срочно всё заменяйте на any. А если вы об этом только слышали то тем более это не для вас, даже не пытайтесь.
Я считаю каждый сам должен решать что использовать, зачем, как и вообще на сколько это кому-то нужно. Не нужно постоянно всех отговаривать и тем более пытаться продать "альтернативу, которая вообще лучше".
Go решил задачи Google (на самом деле далеко не только их), которые были изначально поставлены, язык развивается как и всё, появляются новые ниши применения, к которым язык адаптируется (может быть медленно), но всё же и это нормально.
Касаемо различных технологий из Google, которыми многие пользуются и от которых достаточно много пытаются отговаривать (а это именно так) тоже отдельно хочется сказать. Неужели ни кто, посмотрев на Starlark/Bazel/Protocol Buffers/FlatBuffers/Android/Fuchsia/Kubernetes/gRPC/etc до сих пор не понял, что подход Google это максимальная автоматизация и куча codegen...
Подход Google к слову достаточно логичен не только из-за их масштаба, а в целом из того факта, что цель программирования это автоматизация всего и вся в т.ч. самого программирования. Сделать автоматизацию автоматизации увы не возможно т.е. универсальная генерация кода под любую поставленную задачу увы не достижима, ровно как и идеал.
Но сам факт генерации кода пусть и не полный тот же GitHub Copilot (нравится или нет) или IntelliSense/IntelliCode могут достаточно сильно ускорить процесс написания кода, а следовательно и решения задач автоматизации, что является двигателем прогресса по крайней мере в IT. Причём кодо-генерация в целом может удешевлять будущие разработки: напиши один раз универсальный генератор для того же распространённого CRUD и экономь время и деньги на создание однотипных конструкций на языке ANY_LANG_PLACEHOLDER (естественно до первой встречи со специфичным использованием/применением).
В общем и целом потрогали, поиграли с чем то, не подошло, учли, если захотели поделились. Не нужно свой опыт перекладывать на всех и тем более как-то отговаривать подобными статьями с единственной целью - сказать: вам это не нужно я уверен 100% и вот 100500 фактов почему, некоторые факты будут с натяжкой и вы можете их даже не считать отрицательными (особенно с учётом отличного багажа опыта и практики от того, что у автора), но в данном контексте они прям 100% отрицательные "даю зуб".
А так получилась статья из разряда Little-endian vs Big-Endian, Binary vs Ternary (уже Quad, привет квантовые компьютеры), A vs B, etc. Как говорится вам шашечки или ехать, в итоге ни то, ни другое, а только философское рассуждение на тему что лучше и лучше ли оно вообще. Если философствовать то есть один ответ: мы все работая с любым набором инструментов/языков/техник/подходов делаем всё не правильно по тому, что мы даже не в состоянии определить, что правильно. Мы в науках то даже не уверены на сколько применяемые сейчас подходы в той же физике верны и применимы... За пройденную историю уже не раз видели как то, что мы считали идеалом оказывалось совсем не идеалом, да и в целом точка зрения оказывалась только под одним углом, а под другим оказывается всё работает совсем по другому.
По сути так и есть Wide-Column - частный случай Key-Value. Причём многие почему-то рассматривают ключи как какой-то один идентификатор, хотя ключи также как и значения могут иметь структуру. @keich ниже привёл примеры и оставил ссылку на статью в этом же блоге.
Собственно иногда от Key-Value даже остаётся только Key (какое-нибудь дерево B/R/LSM), в котором есть как техническая информация для сканирования, так и само значение (например, различные индексы, графы в триплетах и т.д.).
Собственно таже Amazon DynamoDB база Key-Value, при работе с которой внешне может быть даже похоже на Wide-Column/Document Oriented.
Равенства конечно никакого не привносит. Возможность добежать куда-то и гору зависимостей - да. Технического и организационного "долга".
Я чуть дальше поправил, что своего рода технологический нейтралитет. Гора зависимости и техдолг возможно, однако эту гору разгребаете не вы одни, а всё сообщество, если оно конечно же желает разгребать.
В конечном счёте гора зависимостей и техдолг у вас всё-равно будут, даже если вы будете делать всё сами. Особенно зависимость от единичных сотрудников, единственных знающих как всё работает на самом деле. Так можно и проект потерять с уходом сотрудников.
Тут речь про изменение модели мироустройства и дальнейший развал колониальной системы, а не про то, как определяется курс валюты. Грубо говоря более развитые страны сейчас начнут меньше потреблять, потому что меняется финансовая система и остальной мир перестает чувствовать себя объектом.
Про какой развал колониальной системы вы ведёте речь? Уж опять таки извините за прямоту, но пока существует физическое деление территории на моя/твоя ничего не изменится, причём вариант социализации территории не решает этого вопроса, а просто делегирует права владения землёй на уровень выше (государство). А деление территории на моя/твоя никуда не уйдёт, ведь это деление опять таки извините за прямоту на уровне животных инстинктов.
И уж меньшее потребление развитыми странами не повлияет на процессы развития других стран, развитие страны ограниченно её моделью управления, когда модель самостоятельности и независимости исчерпывает себя, она меняется на модель рыночную - обмен благами и кооперация. Собственно СССР тоже был кооперацией, объединяя народы, да и РФ с одним из типов федеративности про тоже и США с другим типом федеративности. Да даже ЕС, если отбросить "закреплённую" независимость стран участниц по сути федеративная система.
После того, как эти "хорошие" страны, показали, что частная собственность больше не незыблема, мир не вернется назад. Офшорки скорее всего никто больше не будет держать в США или на Кипре.
Кому показали? И что именно? То, что страна в которой зарегистрирована головная компания имеет большее влияние над компанией, чем страны в которых только дочки? Или что? Так это и не секрет, например опять же Нидерланды, вас не смущает вообще как такое может быть, что небольшая монархия внезапно благополучна для бизнеса и конкретно для сетевой инфраструктуры всего ЕС?
Просто пока одни плюются и всячески пытаются избегать взаимоотношений и рынка в целом, другие превращают этот рынок в свой инструмент, создавая привлекательные условия. Все эти компании никто силком регистрироваться на Кипрах и США не заставлял, они сами там зарегистрировались по тому, что условия более выгодные. Также как никто не заставлял строить заводы производящие основную массу микроэлектроники в Тайване. Просто были созданы условия, благодаря которым на самом деле тот же Тайвань имеет административный ресурс относительно одной конкретной мировой сферы. Или США, имеющие административный ресурс по отношению к многим компаниям.
Давайте перестанем обижаться, за то, что сами отказываемся возглавить одну из сфер, пытаясь быть везде, а по итогу получая ничего в сравнении с остальными.
Каких-то международных успехов за ним в последнее время не замечено. А все "успехи" в последние годы - чисто нерыночные методы, административный и финансовый ресурс, а не прорывные технологии.
Разве, а как же поисковые технологии, а как же свои облака, а как же машинное обучение, ведь Яндекс одна из компаний продвигающих у нас это направление. А как же те же машины с автопилотом, которые к слову результат работы сотрудников Яндекс, Uber, Nvidia и огромного количества аутсорсеров и краудфайнда? А как же в конце концов голосовые помощники и устройства умного дома? Причём что Алиса, что Салют сделаны по сути одними и теми же людьми.
Вы наверное меня не поняли. Имеется в виду, что судя по последним событиям менеджмент Яндекса ... несмотря на то, что 95% своей выручки и персонала в РФ, занимает анти-российскую позицию (я смягчаю слова). Можно называть это по-разному, разными эпитетами и словами на -изм, но суть не меняется.
Вы меня сами изначально не поняли, Яндекс всегда занимал оппозиционную сторону. Как бы регистрация в Нидерладнах одно из "Правил ведения IT бизнеса в России" (если кратко не вести бизнес в РФ). Да по сути Яндекс зависит от РФ, но по идеологии Яндекс всегда были международной компанией и стараются расти в этом направлении.
И наше государство это прекрасно понимает, настолько что даже пыталось контролировать через золотой пакет акций у Сбера. Контроль в том или ином виде получен. Однако куда неожиданно оказалось, что Сбер будучи всегда под контролем государства внезапно пытается уменьшать этот контроль и потенциально инструмент, которым контролировали Яндекс может стать по круче Яндекса в этом плане.
Немного натягиваю сову на глобус, но если мой сотрудник начнет кидать зигу, рассуждать про превосходство одной расы или культуры над другими, осквернять память наших предков и все в таком же духе я больше не буду находиться с ним в "правовых отношениях".
И если он при этом начнет систематически не выполнять работу … то просто гнать ссаными тряпками вполне легально, даже ничего не нарушая.
Знаете, ваш пример и правда про натягивание совы на глобус, в случае с Яндексом такого огромного глобуса хотите вы или нет не было. Если бы было и это реально приносило убытки достаточно даже имиджевых Яндекс бы разорвал отношения. Однако Яндекс показательно подчёркивает, что отношение любых сотрудников компании кроме гендира к любым вещам является сугубо личным отношением и не применим к позиции Яндекса. Да очень гибко, однако в этом и суть.
Понимаете, как ниже про примеры с айфонами я вам ответил, что если пытаться так судить вы сами не замечая начинаете идти по осуждаемой дорожке. Пожалуй не буду приводить примеры, они потенциально чреваты.
Ну а что касается систематически не выполнять работу, так это совсем стандартный элемент отношений работодатель - сотрудник. Видимо сотрудник выполнял свою работу.
Пока выглядит так, что число розовых поней и единорогов пойдет на спад.
К сожалению я вижу обратное, что наоборот число розовых поней и единорогов растёт, у каждого свои, но общие черты у всех одинаковые. Вот только проблема, все эти пони уже были и странно, что этого не замечают, наверное они как-то по особому на них смотрят.
Нужно быть оптимистичными-реалистами, а не мечтать о не достижимых высотах. А что главное понимать, чем дальше тем больше будет входных параметров, влияющих на всю происходящую картину.
Все эти системы не особо работают сами по себе. Но иногда кто-то настолько охреневает и забывает правила приличия, что надо что-то делать, да.
Все эти системы особо не работают, если большая часть забивает на соблюдение установленных правил. Да правила придуманные, но все с ними согласились когда вводили. А так снова из разряда философии, валюты, государства, торговые отношения, обмен информацией и не только всё держится на этих выдуманных правилах и если большинство перестанет соблюдать эти правила, всё выше указанное перестанет существовать. Так, что просто подумайте в глобальном смысле об этих довольно привычных вещах, которые на самом деле особо не работают.
Мое личное мнение доведенное до молекул тут такое - делаешь что-то объективно полезное для общества или сам используешь - используй. Зарабатываешь бабло (или экономишь бабло) - плоти.
А если эта объективная полезность держится на заработке бабла (условный робин-гуд, зарабатываю бабло, чтобы вливать в опенсорс в целом, не обязательно даже в вас. Например, проводя рекламу опенсорс движения за счёт заработанных денег, тем самым косвенно поддерживая вас и направляя вам же денежные потоки)? Или вы рассматриваете модель государственности, когда всё, что приносит деньги на всех этапах обязано облагаться налогами/пошлинами/отчислениями/данью и т.д.?
Нет на самом деле я прекрасно понимаю желание зарабатывать, тем более владея исключительными правами на произведение. Собственно так работает куча индустрий, но заметьте везде всё не идеально и везде всегда есть недовольные.
Эта ветка уже превращается больше в разбор философских вопросов, что есть норма и нормальна ли норма, а главное всегда ли один раз принятая норма будет оставаться нормой...
Это всё философские вопросы если честно. Мой аргумент про не содержание датасета в модели обученной на нём опирается на общепринятые в т.ч. законодательно зафиксированные правовые отношения.
В этом случае датасет ничто иное как отвёртка, с помощью которой собирают айфоны (модели). Собирают ли этой отвёрткой айфоны с применением детского труда это отдельный вопрос, который на самом деле не должен влиять на запрет отвёрток.
Ровно как с подобным примером про нож, ножами знаете ли не только еду готовят, но и преступления совершают, однако совершение преступления с применением холодного оружия не должно влиять на нож как инструмент приготовления еды.
Тут вопрос скорее в чьих руках и с какой целью инструменты. Собственно суть некоммерческого датасета просто обозначает, что его нельзя продавать, его раздают безвозмездно (аля всем по отвёртке для сборки айфонов).
А про принятия анти-человеческой и двуличной сущности давайте не говорить, в мире столько видов летального оружия и не каждое оружие разрабатывалось как оружие.
А то такими скользкими дорожками можно дойти и до запретов целых наций из-за того, что они обслуживают вполне конкретные отношения и идут на сделку со своей совестью. Мы всё это проходили уже и не раз.
Ну как указали в одном из комментариев авторское право не распространяется на алгоритмы как таковой, так что ваша модель будучи алгоритмом в реалиях страны и так общедоступна, а вот конкретная реализация защищена.
Что касается датасета, ImageNet нельзя продавать, однако модели натренированные на нём продавать можно т.к. модели не содержат этот датасет. Модель это алгоритм, если хотите какая-то функция имеющая входящие данные, константы и дающая какой-то результат. Тренируя модель вы просто подбираете константы для формулы, не более. По этому коммерческий статус датасета не влияет на коммерческий статус модели.
Если посмотреть на то, кто является мейнтейнером всех таких популярных вещей, в 9 случаев из 10 это просто сотрудники корпораций (или foundations, которые финансируются теми же корпорациями) на пейролле и ни к какому "подхватить" это не имеет отношения. Не вешайте лапшу на уши, пожалуйста. Живите в реальном мире.
FOSS это такой же инструмент конкурентной борьбы, и ни каким поням и розовым очкам отношения он не имеет.
Мейнтенер это одно, однако вклад вносится сообществом и да розовых очков у меня нет, я прекрасно понимаю, что FOSS используется как инструмент конкурентной борьбы. Тот же Kubernetes это конкурентная борьба с Amazon. Однако у любой борьбы есть временные рамки, и это хорошо, когда продукт конкурентной борьбы двух сторон доступен остальным. Это привносит своего рода технологического равенства, если точнее равенства конечно же не будет, но хотя бы нейтралитет будет достигнут. Маленькая компания совершенно спокойно может применять то, на что крупная компания со своим многолетним опытом потратила не один год, вместо того, чтобы самостоятельно с нуля идти по схожей тропинке и в итоге не дойти.
В этом смысле можете воспринимать корпорации как некая абстракция подобно государствам, только в одном случае границы и рамки идеологические и мнимые, в другом ограничены физически в первую очередь.
Вы все еще верите в них? Может дорасти надо все-таки вам?
Вас не смущает, что международные отношения (если убрать громкие слова заканчивающиеся на суффикс -изм) - это чисто мир агентов из мира Макиавелли? Право сильного простым словом. Вы совсем не читаете новостей, и не следили за военными конфликтами второй половины XX века?
Про периферию, центр, неэквивалентный обмен вы тоже не слышали?
Я верю в международные отношения и не перестану верить. В первую очередь вопрос скорее ответный с чего извините я вдруг должен перестать верить во взаимодействие между разными сторонами? Ведь это взаимодействие существует всю историю человечества, в разное время конечно же по своему отличающееся однако международное взаимодействие.
Да даже любая страна в т.ч. РФ результат международного взаимодействия, не было бы международных отношений с Византией не было бы и весомой части культуры в т.ч. религиозной. Не было бы международных отношений со странами ЕС, не было бы морфлота в том виде в котором он есть и не отдавалась бы дань тому же Петру I за это.
Про суффикс -изм это вы к Капитализму, ок а вас не смущает, что Капитализм всегда был даже в Социолизме во времена Империй и т.д. Вас в целом не смущает, что Капитализм это по сути рыночные отношения - обмен благами. Мы вам шкуру медведя, вы на мёд. Мы вам нефть, вы нам валюту.
Я вам скажу одно всё это уже было и не раз, естественно не прям 100% в таком виде, но всё это было где-то на планете. Стоит просто учить историю (как забавно, ведь об этом весь 21-век у нас учат в школах) и главное изучать её со всех сторон, ведь история она не одногранна по тому, что это отношения разных сторон. Хотите узнать что было в действительности, изучите все стороны их позиции, проблемы, что двигало ими, усредните полученную информацию, всё что получится по итогу и есть происходящие события. Вы удивитесь сколько вещей происходит по случайности и недопониманию.
Про неэквивалентный обмен, знаете может вы удивитесь, но любая валюта торгуется спекулятивно (т.е. попытка завысить или занизить её реальную цену). Так, что мир не такой простой как кажется и все стороны играют по одинаковым правилам. Другое дело, что в разные временные периоды это не выгодно афишировать.
Насчет Яндекса ничего хорошего сказать не могу, а вот то, что до недавнего времени оформлять компании было принято на Кипре или в США - это досадно. Но это сейчас уже изменилось.
Знаете, самое интересно, это правило пошло у нас не просто так, а зарождение этого всего было ещё в последние годы существования СССР (хотя бы в умах). И это правило вполне логичное для своего времени и честно сказать я пока не уверен завершено ли это время.
Более того, компании рано или поздно всё-равно получат регистрацию на Кипре/США/Нидерланды etc. Это будет либо дочка либо головная компания, на самом деле не важно. Важно то, что это происходит при желании работать международно, а не в одной стране. А конкретно эти указанные страны имеют хорошие характеристики, покрывая достаточно крупный список стран одним махом.
Да и Яндекс не просто так был зарегистрирован в Нидерландах чуть ли не со своего основания. И не просто так имеет свою модель, пусть не всегда работающую как задумано.
Не всегда весь мир можно свести к 3 планам на все случаи жизни.
Несомненной, но стоить быть чуть более открытыми и дружелюбными.
Тут речь была про вполне конкретного человека, который 2 месяца занимался деятельностью, за которое его осудили ... а Яндексу было ок, и он платил эти 2 месяца ему зарплату. Не наводит на мысли?
Так, давайте будем честны Яндекс по тем же причинам, почему изначально зарегистрирован в Нидерландах далеко не держится за конкретную страну (хотя по факту и зависит). И сотрудники конкретно в Яндексе имеют кардинально противоположные мнения по разным вещам даже между собой. Есть и те кто митингует и ничего, вы не отказываетесь от использования Я.Браузера, поиска и других сервисов.
Более того не можете игнорировать занятую ими технологическую позицию по IT в целом. Более того даже в каком-то смысле заинтересованы, не смотря на ряд нюансов. (Пожалуй под Вы в данном случае можно рассматривать в целом даже наше Правительство). Так, что какие вопросы?
А про выплату зарплаты извините, но с конкретным человеком конкретная компания была в правовых отношениях работодателя и сотрудника, отношения держались, а значит условия должны были выполняться.
Ещё раз, вы ведь разработчик, у вас должно быть развито абстрактное мышление. Так вот у нас имеется один уровень абстракции в виде государства, имеется другой уровень абстракции в виде компании и что интересно оба уровня абстракции используют один и тот же ресурс в своих целях - люди и их деньги. И вроде как государство контролирует компании, но компании на столько преисполнились, что стали международными (даже не по факту, а по уровню мышления) т.е. для компаний абстракция государства в определённом смысле подразмылась, да они выполняют условия государств, но теперь это не одно государство и приходится всё усреднять. В этом плане компании имеют в своём мышлении мыслимые границы, а не физически. А вот государства построенные на физических границах в первую очередь не очень довольны тем, что их как бы "размыли". По сути вроде абстракция компания подчиняется абстракции государство, а вроде они борятся за один ресурс и относительно этого ресурса как бы на одном уровне, а не в зависимости.
Открою вам страшный секрет. Нормальные EE клиенты про эти все игрушки даже не слышали. Реальный мир живет по другим правилам.
В наших реалиях возможно, однако со временем всё же (сейчас и так имеются единичные EE клиенты) это всё будет меняться, так что будьте готовы к изменениям. Мир не стоит на месте.
Открою вам еще один секрет. Им просто похер. Не прибито гвоздями - тянем. В этом основной мой посыл.
Я вам задам вопрос, если им похер, то и вам похер? Если да, тогда зачем заигрывать в отношения когда всем не похер, зачем кого-то пытаться судить если всем в конечном счёте похер? Или имеет смысл начать с себя и на своём примере показывать, что вам не всё равно и что юридическая система не просто так существует и работает не на отъебись и по тому, что сегодня "луна в венере" по этому сегодня такое постановление? Если всем становится похер на какие-то правила, то эти правила перестают соблюдаться.
Тут думаю вы правы. Заниматься разработкой таких лицензий бессмысленно, думаю надо просто поменять на что-то типа CC BY-NC-SA 4.0.
Единственное до сих пор мне не понятно, почему выбор падает на лицензии ограничивающие выбор лицензии, а не совместимость лицензий. Сложно сказать лучше ли CC BY-NC-SA чем AGPL кроме удовлетворению запрета на коммерческое использование.
Я вам в своей ветке выше уже написал, ознакомьтесь со случаем MongoDB и возьмите их лицензию SSPL, тем более она открытая (править нельзя, распространять и использовать можно). Их модель ближе к тому, чего вы хотите добиться. AGPL совсем не подходит, сменить лицензию вы можете (от авторских и исключительных прав вы не отказались в AGPL), но она будет распространяться на коммиты с лицензией и последующие. Т.е. вы не сможете ссылаться на SSPL по отношению к коду, который изначально был покрыт AGPL, но вот новый код и продукт в целом с этим новым кодом уже будет под SSPL. Тут как бы уже косяк с вашей стороны, что вы не ознакомились с AGPL как следует и применили. Хотя на самом деле можете и попробовать сослаться на SSPL, может и сработает это уже зависит от юрисдикции и принятых норм в конкретной юрисдикции. Так, что международная лицензия может сработать совсем по другому.
И просто совет, будьте спокойнее и подходите к таким вещам по серьёзнее. В OSS не смотря на количество лицензий выбор самой лицензии легче не стал. Если ваша цель FOSS, то сейчас это либо MIT, либо BSD, либо Apache-2.0 (в одном случае патенты покрываются, в другом нет). Но ваша цель это COSS скорее коммерческий опен-сорс, в таком случае увы нет подходящей большинству широко-известной лицензии тут уже либо искать среди единиц, либо написать свою. Вы в этом плане где-то по середине на графе от Public Domain (отказ от всех прав) до Закрытых/Внутренних исходных кодов. AGPL больше в стороне Public Domain.
Так ок, у нас есть DEK (симметричный), есть KEK (симметричный) по KDF, мы зашифровали клиентский приватный ключ (асимметричный) с помощью KEK (симметричный) по PBKDF2 (пароль знает только пользователь) допустим... Но что с нашим приватным ключом (асимметричный)? Он так же в открытую лежит на статическом хостинге? Или он тоже зашифрован, но данные расшифровки лежат рядом?
В этой схеме просто теряется смысл, по сути любой клиент имеет у себя в наличии сразу два приватных ключа... И вектор атаки очевидно - кража зашифрованного клиентского ключа + пароля для его расшифровки (соц. инженерия, фишинг, зловредные расширения), а серверный приватный ключ уже есть.
Тут без динамической части ну никак не обойтись в принципе, кто-то должен выступать второй стороной ответственной за ключ и хранящей его в тайне.
Вот тут я поправлю, класс может наследовать не только классы, но и функции.
Дело в том, что class это конструкция, которая по факту выполняет роль синтаксического сахара. Внутри это функция с прототипом равным содержимому класса. Вот например:
Если переписать без конструкции class вы получите этого:
Если проверить тип класса из первого примера вы увидите, что результатом будет function.
По этому фактически классы (функции) наследуют функции.
Вообще давайте будем откровенны TOTP (RFC 6238 - май 2011) само по себе является расширением HOTP (RFC 4226 - декабрь 2005), которое просто заменяет инкрементируемый счётчик на временные интервалы (тот же счётчик, только автоматически инкрементируемый в соответствии с временем).
Сама суть HOTP/TOTP в том, что мы просто на просто хешируем счетчик с применением секрета, причём да изначально речь ведётся относительно HMAC-SHA1 и базово библиотеки/приложения HOTP/TOTP реализуют именно его (ну может +SHA256, если повезёт), однако допустимо использование HMAC-SHA256/HMAC-SHA512 да в целом любых HMAC-* хоть HMAC-SHA3-256. Т.е. уже один TOTP другому TOTP рознь как минимум из-за того, что можно менять алгоритм хеширования при сохранении общих принципов.
Далее у нас во всей этой теме с генерацией одноразового кода присутствует секрет, а им нужно обменяться! В простом случае этот секрет просто закодирован в base64 в uri в QR коде. А что если можно поделиться секретом более безопасно, даже явно не раскрывая секрета? Например, можно использовать ECDH с эфемерными ключами - всего две временные пары ключей, в открытую передаются только открытые части, но по результату у обеих сторон есть секрет.
А ещё можно сам одноразовый код отправлять, либо как уже упомянуто по клику на PUSH уведомление (на соответствующую сессионную ссылку из метаданных пуша) или эту ссылку можно ещё показать пользователю в виде QR кода (кстати, а вот и подход Яндекса).
А ещё самое банальное при всей совместимости и базовой реализации - не все приложения базово поддерживающие TOTP умеют в отличные от 6 значений коды, или даже в буквенные коды. (Ладно буквенные коды будем считать расширением, но возможность генерить коды более 6 знаков заложена ещё в HOTP, главное влезть динамическим окном в размерность хеша).
Так вот это к чему я, своё приложение это возможность поменять алгоритм хеширования (даже на экзотический) и/или поменять/обезопасить обмен секретом, а может даже облегчить жизнь пользователю, самостоятельно отправляя одноразовый код на сессионную ссылку из QR. И в определённых случаях это имеет достаточный смысл (сделать явно не как у всех - HMAC-SHA1/256 + QR с секретом).
А на счёт Whatsapp, Telegram - там OTP, но не TOTP/HOTP. У Google Messenger кстати тоже QR код с временным одноразовым значением, но он не для авторизации в аккаунте, а для пеиринга устройств во внутреннем pubsub.
Кстати на счёт Google, да TOTP на доп. факторе у них вполне стандартный, но Google точно так же как Яндекс экспериментирует с собственными транспортами для уже Passkeys (раньше Secure key). TOTP в данном случае уже не так интересен, особенно когда есть по свежее и по интереснее подход полностью на ключах.
А вообще конечно с развитием FIDO/WebAuthn и формированием Passkeys вот этот TOTP может стать просто на просто резервным способом (как одноразовые коды на бумажке) на случай потери доступа к материалам ключей (хотя они ведь будут синхронизироваться).
Ну скажут и скажут, что толку слова уже произнесены, возможно в следующий раз такой ситуации не случится.
В этом и суть мы говорим о программе/сервисе предоставляемом на конкретных условиях, условия заранее оглашены, другое дело на сколько человек в них вдавался. Далее эмоциональное тон программы формируется под конкретную аудиторию, а точнее часть этой аудитории (если хотите "среднее по больнице"), если этот тон не меняется в программе, значит всё хорошо (эмоциональное восприятие соответствует заложенному ожиданию) и всё работает как ожидают разработчики/компания владелец. То, что каждый уже по разному может воспринять тон и это вызовет какую-то не ожидаемую разработчиками эмоциональную реакцию уж извините, но это как с багами да и в целом идеалами - всем угодить не возможно т.к. как минимум все возможные случаи предусмотреть просто не выйдет.
Какое бы нейтральное общение не было, но оно тоже может обидеть, мало говорить сухо/нейтрально без эмоциональной окраски, нужно ещё выбирать формулировки в целом учитывать контекст. Просто банально пример такой: Вот придёт к вам абсолютно нейтральная бумажка об отъеме земли в пользу государства с целью дальнейшей передачи, например РЖД для строительства новой очень важной федеральной магистрали, я сомневаюсь, что она вызовет у вас исключительно радостные эмоции или вообще не вызовет никаких.
Но ведь это же "твори, выдумывай, пробуй!" может быть и при продаже, даже не то что в голове крутиться, а именно так и продаваться.
В этом плане у нас с вами нет противоречий на самом деле. Всё опять таки сходится к конечному общему образу бренда (если возвращаться к компаниям), просто вот те же уже упомянутые мной Nike могут спокойно использовать тон на "ты" именно в формате "твори, выдумывай, пробуй!" и это воспринимается вполне естественно причём они именно продают в первую очередь.
О боже незнакомец в час пик в Московском метро не так посмотрел на меня, а ещё в толкучке задел, грубейшим образом нарушив моё личное пространство.
По резкому сокращению дистанции с клиентом: речи о том, что так должны делать все нет, но и нет речи, что так не может никто делать. Есть сферы где сокращение дистанции вполне может быть быстрым, есть где так не выйдет. В конце концов люди разные и по разному могут реагировать на любые вещи, но всё же упор делается на преобладающую массу.
В любом случае, напоминаю, что мои сообщения описывают тон общения бренда с клиентом в рамках построения имиджа/характера бренда в купе со всеми остальными подходами и т.д. Общая составляющая играет очень важную роль, если общий образ бренда не совместим с обращением на "ты" естественно такой тон будет восприниматься не очень хорошо.
Задача в сокращении дистанции общения, повышение доверия и привлекательности не более.
К тому же грубо говоря все притворяются теми кем не являются хотя бы немного. Это как в любой сфере обслуживания необходимо выглядеть дружелюбно/вежливо/привлекательно для клиента в не зависимости от фактического отношения. По сути все сервисы/ПО своего рода такая же сфера обслуживания (естественно со своими целями).
На этот случай в пользовательском соглашении обычно прописана замечательная строчка про "сервис предоставляется КАК ЕСТЬ и может не соответствовать ожиданиям пользователя", ну естественно и не обязаны соответствовать любым ожиданиям, а то знаете ли, даже на "карцелярит" можно обидеться.
В приводимом мной случае "ты" идёт вместе с дружелюбностью, показывается равенство и/или обращение к одному конкретному лицу (персонализация), а не группе лиц. Всё же с друзьями мы обычно общаемся в основном на "ты". Обычно на "вы" мы обращаемся с целью показать уважение (по отношению к старшим/не знакомым или в официально-деловой обстановке) и/или охватить большую группу собеседников (тем самым отказываясь от персонализации).
Конечно "ты" может использоваться как уничижение, кем-то кто считает себя сильнее (не обязательно физически). Хотя и "вы" может быть применено в достаточно уничижительном предложении/контексте, что всё уважение просто теряет свой смысл и не играет роли. В этом плане оба обращения в целом одинаковы.
Однако возвращаясь к компаниям, в подавляющем большинстве они позиционируют себя уважительно/дружелюбно, ведь основная цель это привлечение клиентов (в основном с целью заработка). Конечно существуют отдельные можно сказать "концептуальные" бренды, которые строят свой имидж от противоположного, но в основном такие бренды скорее местечковые и имеют очень узкую клиентскую базу.
Ну всё несколько сложнее...
Я также не согласен со статьёй т.к. в статье упор делается только на официально-деловой, сухой, если хотите язык. И что главное этот сухой язык позиционируется как единственно верный. Просто для примера, представьте если все интерфейсы, все сайты будут применять, например юридический язык и трактовки. На сколько будет удобно пользоваться таким ПО? Даже нет, задам такой вопрос: как много людей постоянно читают и перечитывают разные юридические документы сервисов и ПО (Terms of Service, EULA, Privacy Policy, Cookies Policy, etc.)?
Сухой язык имеет место быть и имеет определённые контексты применения, на которые кстати в статье есть ссылки как усиление доводов (Та же покупка билета или банковский перевод). Однако, у каждой компании имеется свой бренд, даже так у каждого продукта может быть самостоятельный бренд. Бренд это позиционирование компании/продукта, можно сказать имидж/характер, который строится из множества факторов: сфера работы, сфера применения, контексты применения, логотипы, цветовые гаммы, текстовые стилистики (тон общения с клиентами) и т.д. Главная задача при построении бренда - добиться доверия, стать привлекательным для клиента.
Так вот многие компании для брендов выбирают дружелюбный стиль/тон общения, отсюда кстати и обращения на "ты", а не "вы", те же простые разговорные и смягчающие приёмы по типу "Gah" (Эх), "Oops" (Упс), "Hi" (Привет) и т.д. Вот для примера два бренда, которые применяют именно дружелюбный тон: Uber, Nike. Более того даже банки применяют дружелюбный стиль, например тот же Сбербанк использует дружелюбный стиль в молодежных продуктах и продуктах для детей, обращаясь на "ты" и это не из-за того, что Сбербанк "взрослый дядечка" в отношении с ними, а из-за того, что он их друг/сверстник (на равне).
Тут скорее должен быть вопрос как себя позиционирует компания или как она позиционирует конкретный продукт, какой контекст взаимодействия, на сколько контекст допускает свободный стиль. И главное нужно так же разделять зоны влияния, примеры с браузерами используют дружелюбный язык т.к. они в данном случае являются своего рода помощниками/посредниками с которыми вы общаетесь повседневно, они вам помогают получать доступ к различным сайтам, большая часть которых всё же имеет развлекательный характер.
Только мнение людей из компании как правило подкреплено конкретным видением на позиционирование своего бренда и проведённой аналитикой в т.ч. по фокус группам. Если интерфейс использует дружелюбный язык и обращается на "ты", значит аудиторию (или большую её часть) всё устраивает, более того интересующие показатели достигают желаемых значений.
Если не ошибаюсь этот редирект будет работать 3 года (гарантия трафика для Дзена), столько же Яндекс не может вносить кардинальных изменений в DeliveryClub как бренд и сервис (гарантия существования и "конкуренции"). Могу предположить, что к концу этого гарантийного срока может появиться покупатель для DeliveryClub (тот же Сбер) либо же со временем он сольётся с Я.Едой.
URL это URI. В URI обязательными частями являются только scheme и path, части authority, query, fragment опциональные. Если опциональные части не проходят по формату - они игнорируются, если точнее интерпретируются как часть обязательной части (при прохождение по требованиям этой части). Тоже самое происходит и в формате опциональной части authority (тут обязательный только host).
Получается данный URI разбивается так:
В итоге поведение Python, JavaScript, Go, .NET и браузеров является правильным и следует RFC (браузеры в дополнение ещё убирают лишние части, собственно по этому "съелось" двоеточие у не обязательного порта), поведение curl не соответствует RFC в полной мере.
Если бы все были идеальны и всегда желали добра, а главное всегда критиковали технологии с единственной благой целью, но увы нет. Да даже если так, желая только добра можно столько всего кардинально противоположного наворотить, что выглядеть будет как целенаправленное вредительство.
Конкретно в этой статье посыл именно из ряда, "ради добра прям советую даже не используй это", хоть конечно критика затрагивала не только сам Go, другим языкам тоже досталось, однако главный объект критики в статье именно Go и что главное по всему тексту он прям вообще ни для чего не годится, только вот Google и вон те ещё ребята.
Самое интересное, у критика решение проблем сошлось только к самому простому решению - предложение альтернативы, проще этого разве что вообще сказать "вам это не нужно". Какого-то прям глубокого разбора "проблем" и их решения тут не было.
Более того автор в тексте ссылается на команду разработчиков, говорит что они профи в Go, шарят за внутрянку и прочее, по этому им можно и простительно использовать Go. А ведь этой ссылкой автор признаёт, что он далеко не такой же профи в Go, что внутрянку он не изучал, в сравнении вон с теми ребятами. Но при этом его позиция выстроена так, как будто он разобрался в недрах Go и предлагаемой альтернативы на столько, что вот такие есть слабые места и вот почему так получилось, что они слабые.
Опять таки как я уже писал, ровно таким же образом можно критиковать вообще любую технологию, посмотрев на неё сверху. Однако айсберг маленький только над водой, а почему у айсберга такая форма, а не другая и прочее это вообще не нужно разбирать как будто и главное это вообще ни на что не влияет.
Давайте тогда быть честными,
частовсегда технологии созданы кем-то и как правило это крупные компании/организации, считающиеся авторитетными. И что главное почему-то этими технологиями все пользуются только опираясь на авторитетность создателей без каких то других объективных причин и это не в десятках проектов, а буквально в каждом и ни где это не используется максимально эффективно.Если мы будем так разрушать каждую апелляцию к авторитету на право и на лево, тогда каждый должен полностью независимо с нуля вести сначала изучение физических объектов и процессов, потом самостоятельно на выше изученном создавать свои вычислительные машины, концепции (почему вообще байт код и почему двоичный?), языки и т.д. Это будет уже не прогресс, а топтание на одном месте, даже больше похоже на челлендж из разряда найди все возможные способы достижения цели. Ну серьёзно.
А это уже про обратную связь, вы ведь можете пообщаться с архитектором, с тех. диром, предложить свой взгляд, приведя достаточно убедительные аргументы, если вы действительно разбираетесь в том почему ваше предложение лучше выбранного.
Поймите, даже архитекторы и технические директора не всё знают, по тому, что действительно прям каждую технологию потрогать в принципе не возможно. Ну и главное, как будто рядовые разработчики совсем не эмоциональные и без каких либо амбиций...
Ещё раз я согласился с тем, что статьи такого формата имеют место быть, но и указал недостаток такого формата, в первую очередь это негативный окрас по отношению к рассматриваемой технологии с посылом "не трогай", потеря объективности т.к. в погоне за поиском и приведением недостатков приводятся универсальные недостатки, применимые ко многим технологиям сразу в т.ч. к тем, которые тут же позиционируются как альтернатива.
Ещё раз, автор попробовал, нашел какие-то не устраивающие его места, решил поделиться своим опытом работы с технологией, ок покажи конкретные примеры, без ссылок на абстрактные случаи. Если у тебя и правда добрая цель и ты делишься опытом, а не просто своим негативным отношением, то поделись решением, если нашел его, не нашел решение, ну хотя бы разобрался почему тут так, а не как ожидалось, расскажи об этом.
В целом соглашусь смысл статей вполне имеет место быть, только мне лично одно не нравится в этих статьях - утверждение с посылом "вы не гугл, вам это не светит, не нужно и вообще сидите на своём месте".
Т.е. ровно так же можно про любой язык говорить да и в целом про библиотеку/инструмент/подход/идею/etc. Хоть про Rust из разряда у вас не Servo, не блокчейн/etс и вообще не экспериментируйте, вон есть C. Зачем вам TypeScript, вы не Microsoft. Не используйте React, вы не Facebook. У вас JavaScript, ой ну его нафиг прототипное наследование... К чему придраться и на чём сделать упор подобной критики всегда найдётся.
В общем посыл не из разряда изучите/оцените, если подходит применяйте, а из разряда даже если вам подошло, вы не гугл - это не для вас, срочно всё заменяйте на any. А если вы об этом только слышали то тем более это не для вас, даже не пытайтесь.
Я считаю каждый сам должен решать что использовать, зачем, как и вообще на сколько это кому-то нужно. Не нужно постоянно всех отговаривать и тем более пытаться продать "альтернативу, которая вообще лучше".
Go решил задачи Google (на самом деле далеко не только их), которые были изначально поставлены, язык развивается как и всё, появляются новые ниши применения, к которым язык адаптируется (может быть медленно), но всё же и это нормально.
Касаемо различных технологий из Google, которыми многие пользуются и от которых достаточно много пытаются отговаривать (а это именно так) тоже отдельно хочется сказать. Неужели ни кто, посмотрев на Starlark/Bazel/Protocol Buffers/FlatBuffers/Android/Fuchsia/Kubernetes/gRPC/etc до сих пор не понял, что подход Google это максимальная автоматизация и куча codegen...
Подход Google к слову достаточно логичен не только из-за их масштаба, а в целом из того факта, что цель программирования это автоматизация всего и вся в т.ч. самого программирования. Сделать автоматизацию автоматизации увы не возможно т.е. универсальная генерация кода под любую поставленную задачу увы не достижима, ровно как и идеал.
Но сам факт генерации кода пусть и не полный тот же GitHub Copilot (нравится или нет) или IntelliSense/IntelliCode могут достаточно сильно ускорить процесс написания кода, а следовательно и решения задач автоматизации, что является двигателем прогресса по крайней мере в IT. Причём кодо-генерация в целом может удешевлять будущие разработки: напиши один раз универсальный генератор для того же распространённого CRUD и экономь время и деньги на создание однотипных конструкций на языке ANY_LANG_PLACEHOLDER (естественно до первой встречи со специфичным использованием/применением).
В общем и целом потрогали, поиграли с чем то, не подошло, учли, если захотели поделились. Не нужно свой опыт перекладывать на всех и тем более как-то отговаривать подобными статьями с единственной целью - сказать: вам это не нужно я уверен 100% и вот 100500 фактов почему, некоторые факты будут с натяжкой и вы можете их даже не считать отрицательными (особенно с учётом отличного багажа опыта и практики от того, что у автора), но в данном контексте они прям 100% отрицательные "даю зуб".
А так получилась статья из разряда Little-endian vs Big-Endian, Binary vs Ternary (уже Quad, привет квантовые компьютеры), A vs B, etc. Как говорится вам шашечки или ехать, в итоге ни то, ни другое, а только философское рассуждение на тему что лучше и лучше ли оно вообще. Если философствовать то есть один ответ: мы все работая с любым набором инструментов/языков/техник/подходов делаем всё не правильно по тому, что мы даже не в состоянии определить, что правильно. Мы в науках то даже не уверены на сколько применяемые сейчас подходы в той же физике верны и применимы... За пройденную историю уже не раз видели как то, что мы считали идеалом оказывалось совсем не идеалом, да и в целом точка зрения оказывалась только под одним углом, а под другим оказывается всё работает совсем по другому.
По сути так и есть Wide-Column - частный случай Key-Value. Причём многие почему-то рассматривают ключи как какой-то один идентификатор, хотя ключи также как и значения могут иметь структуру. @keich ниже привёл примеры и оставил ссылку на статью в этом же блоге.
Собственно иногда от Key-Value даже остаётся только Key (какое-нибудь дерево B/R/LSM), в котором есть как техническая информация для сканирования, так и само значение (например, различные индексы, графы в триплетах и т.д.).
Собственно таже Amazon DynamoDB база Key-Value, при работе с которой внешне может быть даже похоже на Wide-Column/Document Oriented.
Я чуть дальше поправил, что своего рода технологический нейтралитет. Гора зависимости и техдолг возможно, однако эту гору разгребаете не вы одни, а всё сообщество, если оно конечно же желает разгребать.
В конечном счёте гора зависимостей и техдолг у вас всё-равно будут, даже если вы будете делать всё сами. Особенно зависимость от единичных сотрудников, единственных знающих как всё работает на самом деле. Так можно и проект потерять с уходом сотрудников.
Про какой развал колониальной системы вы ведёте речь? Уж опять таки извините за прямоту, но пока существует физическое деление территории на моя/твоя ничего не изменится, причём вариант социализации территории не решает этого вопроса, а просто делегирует права владения землёй на уровень выше (государство). А деление территории на моя/твоя никуда не уйдёт, ведь это деление опять таки извините за прямоту на уровне животных инстинктов.
И уж меньшее потребление развитыми странами не повлияет на процессы развития других стран, развитие страны ограниченно её моделью управления, когда модель самостоятельности и независимости исчерпывает себя, она меняется на модель рыночную - обмен благами и кооперация. Собственно СССР тоже был кооперацией, объединяя народы, да и РФ с одним из типов федеративности про тоже и США с другим типом федеративности. Да даже ЕС, если отбросить "закреплённую" независимость стран участниц по сути федеративная система.
Кому показали? И что именно? То, что страна в которой зарегистрирована головная компания имеет большее влияние над компанией, чем страны в которых только дочки? Или что? Так это и не секрет, например опять же Нидерланды, вас не смущает вообще как такое может быть, что небольшая монархия внезапно благополучна для бизнеса и конкретно для сетевой инфраструктуры всего ЕС?
Просто пока одни плюются и всячески пытаются избегать взаимоотношений и рынка в целом, другие превращают этот рынок в свой инструмент, создавая привлекательные условия. Все эти компании никто силком регистрироваться на Кипрах и США не заставлял, они сами там зарегистрировались по тому, что условия более выгодные. Также как никто не заставлял строить заводы производящие основную массу микроэлектроники в Тайване. Просто были созданы условия, благодаря которым на самом деле тот же Тайвань имеет административный ресурс относительно одной конкретной мировой сферы. Или США, имеющие административный ресурс по отношению к многим компаниям.
Давайте перестанем обижаться, за то, что сами отказываемся возглавить одну из сфер, пытаясь быть везде, а по итогу получая ничего в сравнении с остальными.
Разве, а как же поисковые технологии, а как же свои облака, а как же машинное обучение, ведь Яндекс одна из компаний продвигающих у нас это направление. А как же те же машины с автопилотом, которые к слову результат работы сотрудников Яндекс, Uber, Nvidia и огромного количества аутсорсеров и краудфайнда? А как же в конце концов голосовые помощники и устройства умного дома? Причём что Алиса, что Салют сделаны по сути одними и теми же людьми.
Вы меня сами изначально не поняли, Яндекс всегда занимал оппозиционную сторону. Как бы регистрация в Нидерладнах одно из "Правил ведения IT бизнеса в России" (если кратко не вести бизнес в РФ). Да по сути Яндекс зависит от РФ, но по идеологии Яндекс всегда были международной компанией и стараются расти в этом направлении.
И наше государство это прекрасно понимает, настолько что даже пыталось контролировать через золотой пакет акций у Сбера. Контроль в том или ином виде получен. Однако куда неожиданно оказалось, что Сбер будучи всегда под контролем государства внезапно пытается уменьшать этот контроль и потенциально инструмент, которым контролировали Яндекс может стать по круче Яндекса в этом плане.
Знаете, ваш пример и правда про натягивание совы на глобус, в случае с Яндексом такого огромного глобуса хотите вы или нет не было. Если бы было и это реально приносило убытки достаточно даже имиджевых Яндекс бы разорвал отношения. Однако Яндекс показательно подчёркивает, что отношение любых сотрудников компании кроме гендира к любым вещам является сугубо личным отношением и не применим к позиции Яндекса. Да очень гибко, однако в этом и суть.
Понимаете, как ниже про примеры с айфонами я вам ответил, что если пытаться так судить вы сами не замечая начинаете идти по осуждаемой дорожке. Пожалуй не буду приводить примеры, они потенциально чреваты.
Ну а что касается систематически не выполнять работу, так это совсем стандартный элемент отношений работодатель - сотрудник. Видимо сотрудник выполнял свою работу.
К сожалению я вижу обратное, что наоборот число розовых поней и единорогов растёт, у каждого свои, но общие черты у всех одинаковые. Вот только проблема, все эти пони уже были и странно, что этого не замечают, наверное они как-то по особому на них смотрят.
Нужно быть оптимистичными-реалистами, а не мечтать о не достижимых высотах. А что главное понимать, чем дальше тем больше будет входных параметров, влияющих на всю происходящую картину.
Все эти системы особо не работают, если большая часть забивает на соблюдение установленных правил. Да правила придуманные, но все с ними согласились когда вводили. А так снова из разряда философии, валюты, государства, торговые отношения, обмен информацией и не только всё держится на этих выдуманных правилах и если большинство перестанет соблюдать эти правила, всё выше указанное перестанет существовать. Так, что просто подумайте в глобальном смысле об этих довольно привычных вещах, которые на самом деле особо не работают.
А если эта объективная полезность держится на заработке бабла (условный робин-гуд, зарабатываю бабло, чтобы вливать в опенсорс в целом, не обязательно даже в вас. Например, проводя рекламу опенсорс движения за счёт заработанных денег, тем самым косвенно поддерживая вас и направляя вам же денежные потоки)? Или вы рассматриваете модель государственности, когда всё, что приносит деньги на всех этапах обязано облагаться налогами/пошлинами/отчислениями/данью и т.д.?
Нет на самом деле я прекрасно понимаю желание зарабатывать, тем более владея исключительными правами на произведение. Собственно так работает куча индустрий, но заметьте везде всё не идеально и везде всегда есть недовольные.
Эта ветка уже превращается больше в разбор философских вопросов, что есть норма и нормальна ли норма, а главное всегда ли один раз принятая норма будет оставаться нормой...
Это всё философские вопросы если честно. Мой аргумент про не содержание датасета в модели обученной на нём опирается на общепринятые в т.ч. законодательно зафиксированные правовые отношения.
В этом случае датасет ничто иное как отвёртка, с помощью которой собирают айфоны (модели). Собирают ли этой отвёрткой айфоны с применением детского труда это отдельный вопрос, который на самом деле не должен влиять на запрет отвёрток.
Ровно как с подобным примером про нож, ножами знаете ли не только еду готовят, но и преступления совершают, однако совершение преступления с применением холодного оружия не должно влиять на нож как инструмент приготовления еды.
Тут вопрос скорее в чьих руках и с какой целью инструменты. Собственно суть некоммерческого датасета просто обозначает, что его нельзя продавать, его раздают безвозмездно (аля всем по отвёртке для сборки айфонов).
А про принятия анти-человеческой и двуличной сущности давайте не говорить, в мире столько видов летального оружия и не каждое оружие разрабатывалось как оружие.
А то такими скользкими дорожками можно дойти и до запретов целых наций из-за того, что они обслуживают вполне конкретные отношения и идут на сделку со своей совестью. Мы всё это проходили уже и не раз.
Ну как указали в одном из комментариев авторское право не распространяется на алгоритмы как таковой, так что ваша модель будучи алгоритмом в реалиях страны и так общедоступна, а вот конкретная реализация защищена.
Что касается датасета, ImageNet нельзя продавать, однако модели натренированные на нём продавать можно т.к. модели не содержат этот датасет. Модель это алгоритм, если хотите какая-то функция имеющая входящие данные, константы и дающая какой-то результат. Тренируя модель вы просто подбираете константы для формулы, не более. По этому коммерческий статус датасета не влияет на коммерческий статус модели.
Мейнтенер это одно, однако вклад вносится сообществом и да розовых очков у меня нет, я прекрасно понимаю, что FOSS используется как инструмент конкурентной борьбы. Тот же Kubernetes это конкурентная борьба с Amazon. Однако у любой борьбы есть временные рамки, и это хорошо, когда продукт конкурентной борьбы двух сторон доступен остальным. Это привносит своего рода технологического равенства, если точнее равенства конечно же не будет, но хотя бы нейтралитет будет достигнут. Маленькая компания совершенно спокойно может применять то, на что крупная компания со своим многолетним опытом потратила не один год, вместо того, чтобы самостоятельно с нуля идти по схожей тропинке и в итоге не дойти.
В этом смысле можете воспринимать корпорации как некая абстракция подобно государствам, только в одном случае границы и рамки идеологические и мнимые, в другом ограничены физически в первую очередь.
Я верю в международные отношения и не перестану верить. В первую очередь вопрос скорее ответный с чего извините я вдруг должен перестать верить во взаимодействие между разными сторонами? Ведь это взаимодействие существует всю историю человечества, в разное время конечно же по своему отличающееся однако международное взаимодействие.
Да даже любая страна в т.ч. РФ результат международного взаимодействия, не было бы международных отношений с Византией не было бы и весомой части культуры в т.ч. религиозной. Не было бы международных отношений со странами ЕС, не было бы морфлота в том виде в котором он есть и не отдавалась бы дань тому же Петру I за это.
Про суффикс -изм это вы к Капитализму, ок а вас не смущает, что Капитализм всегда был даже в Социолизме во времена Империй и т.д. Вас в целом не смущает, что Капитализм это по сути рыночные отношения - обмен благами. Мы вам шкуру медведя, вы на мёд. Мы вам нефть, вы нам валюту.
Я вам скажу одно всё это уже было и не раз, естественно не прям 100% в таком виде, но всё это было где-то на планете. Стоит просто учить историю (как забавно, ведь об этом весь 21-век у нас учат в школах) и главное изучать её со всех сторон, ведь история она не одногранна по тому, что это отношения разных сторон. Хотите узнать что было в действительности, изучите все стороны их позиции, проблемы, что двигало ими, усредните полученную информацию, всё что получится по итогу и есть происходящие события. Вы удивитесь сколько вещей происходит по случайности и недопониманию.
Про неэквивалентный обмен, знаете может вы удивитесь, но любая валюта торгуется спекулятивно (т.е. попытка завысить или занизить её реальную цену). Так, что мир не такой простой как кажется и все стороны играют по одинаковым правилам. Другое дело, что в разные временные периоды это не выгодно афишировать.
Знаете, самое интересно, это правило пошло у нас не просто так, а зарождение этого всего было ещё в последние годы существования СССР (хотя бы в умах). И это правило вполне логичное для своего времени и честно сказать я пока не уверен завершено ли это время.
Более того, компании рано или поздно всё-равно получат регистрацию на Кипре/США/Нидерланды etc. Это будет либо дочка либо головная компания, на самом деле не важно. Важно то, что это происходит при желании работать международно, а не в одной стране. А конкретно эти указанные страны имеют хорошие характеристики, покрывая достаточно крупный список стран одним махом.
Да и Яндекс не просто так был зарегистрирован в Нидерландах чуть ли не со своего основания. И не просто так имеет свою модель, пусть не всегда работающую как задумано.
Несомненной, но стоить быть чуть более открытыми и дружелюбными.
Так, давайте будем честны Яндекс по тем же причинам, почему изначально зарегистрирован в Нидерландах далеко не держится за конкретную страну (хотя по факту и зависит). И сотрудники конкретно в Яндексе имеют кардинально противоположные мнения по разным вещам даже между собой. Есть и те кто митингует и ничего, вы не отказываетесь от использования Я.Браузера, поиска и других сервисов.
Более того не можете игнорировать занятую ими технологическую позицию по IT в целом. Более того даже в каком-то смысле заинтересованы, не смотря на ряд нюансов. (Пожалуй под Вы в данном случае можно рассматривать в целом даже наше Правительство). Так, что какие вопросы?
А про выплату зарплаты извините, но с конкретным человеком конкретная компания была в правовых отношениях работодателя и сотрудника, отношения держались, а значит условия должны были выполняться.
Ещё раз, вы ведь разработчик, у вас должно быть развито абстрактное мышление. Так вот у нас имеется один уровень абстракции в виде государства, имеется другой уровень абстракции в виде компании и что интересно оба уровня абстракции используют один и тот же ресурс в своих целях - люди и их деньги. И вроде как государство контролирует компании, но компании на столько преисполнились, что стали международными (даже не по факту, а по уровню мышления) т.е. для компаний абстракция государства в определённом смысле подразмылась, да они выполняют условия государств, но теперь это не одно государство и приходится всё усреднять. В этом плане компании имеют в своём мышлении мыслимые границы, а не физически. А вот государства построенные на физических границах в первую очередь не очень довольны тем, что их как бы "размыли". По сути вроде абстракция компания подчиняется абстракции государство, а вроде они борятся за один ресурс и относительно этого ресурса как бы на одном уровне, а не в зависимости.
В наших реалиях возможно, однако со временем всё же (сейчас и так имеются единичные EE клиенты) это всё будет меняться, так что будьте готовы к изменениям. Мир не стоит на месте.
Я вам задам вопрос, если им похер, то и вам похер? Если да, тогда зачем заигрывать в отношения когда всем не похер, зачем кого-то пытаться судить если всем в конечном счёте похер? Или имеет смысл начать с себя и на своём примере показывать, что вам не всё равно и что юридическая система не просто так существует и работает не на отъебись и по тому, что сегодня "луна в венере" по этому сегодня такое постановление? Если всем становится похер на какие-то правила, то эти правила перестают соблюдаться.
Единственное до сих пор мне не понятно, почему выбор падает на лицензии ограничивающие выбор лицензии, а не совместимость лицензий. Сложно сказать лучше ли CC BY-NC-SA чем AGPL кроме удовлетворению запрета на коммерческое использование.
Я вам в своей ветке выше уже написал, ознакомьтесь со случаем MongoDB и возьмите их лицензию SSPL, тем более она открытая (править нельзя, распространять и использовать можно). Их модель ближе к тому, чего вы хотите добиться. AGPL совсем не подходит, сменить лицензию вы можете (от авторских и исключительных прав вы не отказались в AGPL), но она будет распространяться на коммиты с лицензией и последующие. Т.е. вы не сможете ссылаться на SSPL по отношению к коду, который изначально был покрыт AGPL, но вот новый код и продукт в целом с этим новым кодом уже будет под SSPL. Тут как бы уже косяк с вашей стороны, что вы не ознакомились с AGPL как следует и применили. Хотя на самом деле можете и попробовать сослаться на SSPL, может и сработает это уже зависит от юрисдикции и принятых норм в конкретной юрисдикции. Так, что международная лицензия может сработать совсем по другому.
И просто совет, будьте спокойнее и подходите к таким вещам по серьёзнее. В OSS не смотря на количество лицензий выбор самой лицензии легче не стал. Если ваша цель FOSS, то сейчас это либо MIT, либо BSD, либо Apache-2.0 (в одном случае патенты покрываются, в другом нет). Но ваша цель это COSS скорее коммерческий опен-сорс, в таком случае увы нет подходящей большинству широко-известной лицензии тут уже либо искать среди единиц, либо написать свою. Вы в этом плане где-то по середине на графе от Public Domain (отказ от всех прав) до Закрытых/Внутренних исходных кодов. AGPL больше в стороне Public Domain.