Именно. Подобная штука не гарантирует защиту, а лишь добавляет ещё один эшелон обороны, усложняя жизнь мошенникам и уменьшая вероятность их успеха. Раньше пользователь просто пролистывал, а теперь он видит нечто, вызывающее прилив кортизола и создающее препятствия для дальнейших шагов (так как просто нажать ок не получится). Мошенникам придётся придумать и ввести дополнительные шаги в свои схемы (уговаривать + объяснять как это преодолеть), повышая её хрупкость.
Тут имхо важно не только донести опасность на информационном и эмоциональном уровнях, но и сделать это максимально просто, не апеллируя к понятиям, которые требуют от пользователя компетенций.
А на какой процент это улучшит ситуацию это уже другой вопрос, надо проводить исследования, причём в разных социальных группах, в разных психологических состояниях и при разном воздействии/давлении.
Что интересно — в VB6 то, что скомпилировано в псевдокод (P‑Code) на современных компах работает гораздо быстрее, чем то, что скомпилировано в Native Code. Чуть ли не на порядок. По крайней мере так было на всех компах, где я тестил (Win7/8/8.1/11).
Равномерное движение относительно, ускоренное движение абсолютно. Ускорение можно узнать в локальной системе отсчёта с помощью всяких акселерометров‑весов с маятниками, то есть ускорение не зависит от системы отсчёта.
Если в клиенте какая‑нибудь уязвимость, то такое может быть. Банально может быть неофициальный телеграмоватсапов клиент с 50 бекдорами. В официальных клиентах же нет бекдоров, правда?
Многие пользователи не понимают внутреннюю кухню устройств. Они не понимают и не вникают в составляющие части системы и их взаимосвязи. Что там ОС, приложения и разрешения какие то. Для многих людей это не система с внутренними отношениями, а единый цельный объект.
Поэтому, когда оно начинает задавать вопросы про разрешения, человек не понимает что происходит, потому что в его понятийном аппарате нет тех штук, взаимоотношение которых описано на экране. Плюс люди не понимают важность ИБ. В итоге человек воспринимает это как помеху и просто её пролистывает. Как рекламу.
В данном случае оно может объяснить, что такое constrexpr, что такое size_t и что за синтаксис с 0x для совсем уж новичков. Хотя в статьях, где присутствуют подобные штуки, новички редко обитают.
Можно просто справа вверху иконку сделать и всё, при наведении появляется тултип «Объяснить код с SourceCraft».
Кнопка справа вверху
Если на первых порах надо привлечь внимание, то можно чтобы она периодически (то есть не всё время) ненавязчиво сияла, подпрыгивала или покачивалась. Ну или жонглировала черными штуками используя оранжевокрасные как руки, если заморачиваться. Главное не перегнуть палку, чтобы не раздражало.
Еще можно объяснение выстраивать учитывая профиль того, кто читает. Если у него там 735 статей про написание драйверов на С, то азы ему объяснять не надо, надо сразу к делу и с терминологией. А если видно, что он новичок и/или у него другая профессия — то надо разжевывать, и тому подобное.
5090 в 2,3 раза быстрее RTX 4090 и может выдавать 350+ FPS в играх, особенно с применением DLSS 4.
Инпутлаговое нарисованное MFG же. Играть можно, но не во всё. В BF6 и синглплеерах это можно вытерпеть, в CS с его сумасшедшими таймингами — нет.
На сегодняшний день это бескомпромиссное решение для профессионалов, стримеров и энтузиастов, которым нужен максимум в 4K.
Оно и 12К тянет вполне, даже в нативе (BF6 и Metro Exodus 12K выдавали где‑то 40–50 фпс), и GPT OSS 120b тянет 15 токенов/сек (а Qwen 3 Coder 30b вообще 192 т/с). В 3ds max можно почти в реалтайме рендерить Арнольдом прямо во вьюпорте. У меня даже получалось рендерить 16K (15360×8640) изображения на GPU, что раньше было за гранью. Ещё тут не 2, как у предыдущих карточек, а 3 аппаратных видеоэнкодера — можно поставить какой‑нибудь ffmpeg/Premiere кодировать видео и параллельно продолжать работать/играть.
Но: ИМХО, самая главная сила у неё не в ядрах и +100500 фпс, как заявляет маркетинг, а в большем количестве памяти, потому что малейшая её нехватка для любой задачи существенно просаживает производительность. Тот же Deathloop у меня жрет ~30 Гб VRAM, то есть впритык. Если с ним параллельно запустить хоть что‑то маленькое, FPS сажается раз в 10 и начинаются лютые лаги. Соответственно, на 4090 он уже бы просто не заработал.
PS. Вроде как карточке уже джейлбрейкнули интерконнект, чтобы если их несколько штук втыкаешь для ИИ, они могли между собой общаться напрямую (не полонценный Nvlink, просто ускорение взаимодействия через PCIE). Разумеется, гарантия после такого отправляется в помойку.
Будет написано на новом модном фраемворке, в котором иконка будет храниться в виде промпта который будет на каждой прорисовке отправляться в облако Azue вместе с вашими файлами, чтобы их ИИ отрисовал современную стильную дизайнерскую пиктограмму, каждый пиксель которой будет отправлен отдельным json пакетом.
Есть такое, она довольно поверхностно объясняет, и больше про то, какую задачу код решает, а не как именно он это делает и почему именно так. Фактически это выглядит как перевод с языка программирования на русский.
Однако мне понравилось, что он понимает контекст статьи, даже если она довольно большая (затестил на своей про подсветку на 500 вт), связывает смысл кода с решаемой задачей и понимает довольно хитрые приёмы.
Код с двойными указателями
public bool Render(IBooffer1D<RenderLedValueType> values)
{
if (E.IsInvalid(values) || E.IsInvalid(this))
return false;
using var sc = DisposeProtectedScope;
if (sc.IsFailed())
return false;
using var sc1 = values.DisposeProtectedScope;
if (sc1.IsFailed())
return false;
DisposeProtectedScopeToken preprocessedValuesDisposeToken = default;
if (Preprocess(values, out var preprocessedValues))
{
if (preprocessedValues != values)
if (!E.IsInvalid(preprocessedValues))
{
preprocessedValuesDisposeToken = preprocessedValues.DisposeProtectedScope;
values = preprocessedValues;
}
}
using (preprocessedValuesDisposeToken)
unsafe
{
if (values.TryGetPointers(out var source_begin, out var source_end))
{
var mapPack = addressMap.Value;
var location = (double2)pepector.Create(Installation.Bounds).xy;
var size = (double2)pepector.Create(Installation.Bounds).zw - location;
canvasLocker.EnterWriteLock();
try
{
for (int mapIndex = 0; mapIndex < mapPack.MapCount; mapIndex++)
{
if (mapPack.TryGetMapPointers(mapIndex, out var begin, out var count, out var end, out var end4))
{
var end8 = begin + count / 8 * 8;
var ptr = begin;
var source_ptr = source_begin;
while (ptr < end8)
{
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
**ptr++ = *source_ptr++;
}
while (ptr < end)
**ptr++ = *source_ptr++;
}
}
}
finally
{
canvasLocker?.ExitWriteLock();
}
}
{
if (addressMap.Value.TryGetAllMapPointers(out var allBegin, out var count, out var end, out var end4))
{
AfterRender(_canvas.Value, allBegin, count, end, end4);
}
}
}
return true;
}
Метод Render принимает на вход объект values типа IBooffer1D<RenderLedValueType> и выполняет рендеринг данных на светодиодную установку.
В начале метода происходит проверка входных данных на валидность с помощью метода E.IsInvalid. Если данные невалидны, метод возвращает false. Затем создаётся защищённая область (DisposeProtectedScope), которая предотвращает выгрузку объекта во время рендеринга.
Далее происходит предварительная обработка данных с помощью метода Preprocess, который может изменить входные данные. Затем выполняется основной цикл рендеринга, который копирует данные из буфера values в целевые адреса, используя указатели.
После завершения рендеринга вызывается метод AfterRender, который выполняет дополнительные операции после рендеринга. В конце метода возвращается true, что означает успешное выполнение рендеринга.
Этот код демонстрирует использование ручного управления памятью и оптимизаций для обеспечения высокой производительности рендеринга на светодиодную установку.
Но вот на этом фрагменте я понял, что коменты в коде оно не читает.
Вычисление прозрачности картинки на основе яркости с использованием SIMD
static readonly Vector512<ushort> _rgb_koefficients = Vector512.Create(
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0,
(ushort)38, (ushort)77, (ushort)13, (ushort)0
);
static readonly Vector512<ushort> _channelRegrouping = Vector512.Create(
(ushort)0, (ushort)4, (ushort)8, (ushort)12, (ushort)16, (ushort)20, (ushort)24, (ushort)28, //Красные
(ushort)1, (ushort)5, (ushort)9, (ushort)13, (ushort)17, (ushort)21, (ushort)25, (ushort)29, //Зелёные
(ushort)2, (ushort)6, (ushort)10, (ushort)14, (ushort)18, (ushort)22, (ushort)26, (ushort)30, //Синие
(ushort)3, (ushort)7, (ushort)11, (ushort)15, (ushort)19, (ushort)23, (ushort)27, (ushort)31 //Пофиг
);
static readonly Vector256<byte> _byte_unrar_indices = Vector256.Create(
(byte)31, (byte)31, (byte)31, (byte)0,
(byte)31, (byte)31, (byte)31, (byte)1,
(byte)31, (byte)31, (byte)31, (byte)2,
(byte)31, (byte)31, (byte)31, (byte)3,
(byte)31, (byte)31, (byte)31, (byte)4,
(byte)31, (byte)31, (byte)31, (byte)5,
(byte)31, (byte)31, (byte)31, (byte)6,
(byte)31, (byte)31, (byte)31, (byte)7
);
static readonly Vector256<byte> _rgb_alpha_masks = Vector256.Create(
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF,
0, 0, 0, 0xFF
);
private static byte* _avx512_byte_Avx512BW(byte* ptr, byte* end_vec)
{
//Прогружаем маски и прочую шелуху в регистры
var rgb_koefficients = _rgb_koefficients;
var channelRegrouping = _channelRegrouping;
var byte_unrar_indices = _byte_unrar_indices;
var rgb_alpha_masks = _rgb_alpha_masks;
while (ptr < end_vec)
{
var colorsBytes = Vector256.LoadAligned<byte>(ptr);
var colorsUShort = Avx512BW.ConvertToVector512UInt16(colorsBytes);
//Умножаем RGB коэффициенты
var colorsMultipled = colorsUShort * rgb_koefficients;
//Складываем для каждого пикселя его перемноженные RGB
Vector128<ushort> sums;
{
//Тасуем RGB RGB RGB RGB RGB RGB RGB RGB в RRRRRRRR GGGGGGGG BBBBBBBB AAAAAAAA
var regroupedChannels = Vector512.Shuffle(colorsMultipled, channelRegrouping);
//Теперь нам нужно 3 вектора красных, зелёных и синих компонент
var lower = regroupedChannels.GetLower(); //RRRRRRRR GGGGGGGG
var reds = lower.GetLower(); //RRRRRRRR
var greens = lower.GetUpper(); //GGGGGGGG
var blues = regroupedChannels.GetUpper().GetLower(); //BBBBBBBB
//Складываем попарно компоненты сразу 8 пикселей
sums = reds + greens + blues; //RRRRRRRR + GGGGGGGG + BBBBBBBB = SUM SUM SUM SUM SUM SUM SUM SUM
}
//Делим все 8 сумм на 128
var lumsAsUShorts = Vector128.ShiftRightLogical(sums, 7);
//Получаем яркости
//Преобразуем яркости из ушортов обратно в байты
var lumsAsBytes = Avx2.PackUnsignedSaturate(*(Vector256<short>*)&lumsAsUShorts, Vector256<short>.Zero);
//Раздвигаем яркости чтобы прицелиться
//ими на места альфа-каналов
var lumsShuffled = Vector256.Shuffle(lumsAsBytes, byte_unrar_indices);
////Совмещаем считанные в самом начале цвета 8 пикселей с
////посчитанными альфа-каналами
var blendedResult = Avx2.BlendVariable(colorsBytes, lumsShuffled, rgb_alpha_masks);
//Пишем результат
Vector256.StoreAligned(blendedResult, ptr);
////Следующие 8 пикселей
ptr += (256 / 8 / sizeof(byte));
}
return ptr;
}
Данный фрагмент кода написан на языке C# и использует SIMD-инструкции (Single Instruction, Multiple Data) для параллельной обработки данных. Он предназначен для работы с цветовыми компонентами изображений и включает в себя несколько статических векторных переменных и функцию _avx512_byte_Avx512BW, которая выполняет обработку байтовых данных.
В коде используются векторы для хранения коэффициентов RGB, индексов для перегруппировки каналов цвета, а также маски для работы с альфа-каналами. Функция _avx512_byte_Avx512BW загружает байтовые данные в вектор, преобразует их в 16-битные значения, выполняет умножение на коэффициенты RGB, перегруппировку каналов, суммирование компонентов и другие операции для получения яркости пикселей. Затем яркость преобразуется обратно в байты, и результат сохраняется в памяти.
Этот код интересен тем, что демонстрирует использование SIMD-оптимизаций для ускорения обработки изображений. Он позволяет эффективно работать с большими объёмами данных, выполняя операции параллельно на нескольких элементах одновременно.
То есть оно как-бы более-менее перечислило, что там происходит, но не последовательно, потеряло нить, можно сказать. Лучше было бы что‑то в духе «на входе X, на выходе Y, делаем сначала это, потом это, потом это».
В целом, имхо, для начала функция норм. Только я бы кнопку сделал маленькой‑квадратной и поместил бы в правый верхний угол области с кодом, чтобы она не занимала столько места.
Если я правильно понимаю, то проверки для всех трёх измерений идентичны, поэтому можно сделать как‑то так:
public ContainmentType Contains(BoundingSphere sphere)
{
float3 clampedCenter = float3.Clamp(sphere.Center, Min, Max);
float radius = sphere.Radius;
{
var distanceSquared = float3.DistancePow2(sphere.Center, clampedCenter);
if (distanceSquared > radius * radius)
return ContainmentType.Disjoint;
}
float3 thisSize = Max - Min;
for (int dimensionIndex = 0; dimensionIndex < 3; dimensionIndex++)
{
//if (dimensionIndex is 0 or 1)
if (thisSize[dimensionIndex] <= radius)
return ContainmentType.Intersects;
if (Min[dimensionIndex] > sphere.Center[dimensionIndex] - radius)
return ContainmentType.Intersects;
if (sphere.Center[dimensionIndex] > Max[dimensionIndex] - radius)
return ContainmentType.Intersects;
}
return ContainmentType.Contains;
}
Массивы в C# — это аллокации в куче. В подавляющем большинстве случаев на них пофиг, особенно если они короткоживущие. Но если среда выполнения обладает кривым сборщиком мусора и код выполняется слишком часто, это может вызывать подлагивания даже на 0 поколении.
В.NET 10, ЕМНИП, завезли аллокацию массивов на стеке, если компилятор видит, что это не разрушит логику, ИМХО, Ваш пример туда как раз попадает. Поэтому в.NET 10 проблем точно не должно быть.
Да) Я сам минут 10 искал, и таки нашёл. Сейчас решил эксперимент поставить на локальной Qwen3-vl-30b
Она почти сразу распрощалась с кукухой
Давайте внимательно посмотрим на изображение.
Все буквы выглядят как Q со странным шрифтом и хвостиком, но, как и сказано, одна из них — это буква O.
Разберёмся:
Буква Q обычно имеет хвостик, который выходит вправо-вниз.
Буква O — это просто круг, без хвостика.
Значит, нам нужно найти ту единственную букву, которая не имеет хвостика — то есть, это O.
Теперь посмотрим на изображение. Всё выглядит одинаково, но если внимательно рассмотреть, можно заметить, что все буквы — это Q, но в одной из них хвостик отсутствует.
Посмотрим на вторую строку снизу, второй столбец слева.
Нет, давайте пересчитаем.
Посмотрим на вторую строку снизу, второй столбец слева — там, кажется, хвостик отсутствует.
Но давайте уточним.
На самом деле, если внимательно посмотреть, то все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте проверим.
На самом деле, все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хвостика.
Но давайте уточним: все буквы — это Q, но в одной из них хвостик отсутствует — это и есть O.
Посмотрим на вторую строку снизу, второй столбец слева — да, там нет хво
Мне кажется смысл тут в том, чтобы код был написан так, чтобы глаза цеплялись за важное и не цеплялись за неважное. Чем больше расхождение, тем выше вероятность что‑то пропустить, поэтому нужно учитывать особенности зрения.
Глаза эволюционно сделаны для поиска всяких бананов в листве и мамонтов с саблезубыми кошками в траве. Картинка обрабатывается уже на уровне сетчатки, выделяются ключевые паттерны и передаются в зрительный нерв, вроде бы даже доказано, что там какое‑то подобие разложения Фурье происходит.
Если глаз видит кучу подобных объектов (типа травинок), то они передаются в мозг не по отдельности, а как «куча объектов которые в среднем похожи на травинку» или вообще как шум такого‑то цвета такой‑то интенсивности.
не в длине строки как таковой, а в том, что тут куча подобных объектов, слабо отличающихся друг от друга. И зрение «на аппаратном уровне» это не фильтрует. Это буквально аналог всяких загадок типа такой.
Найдите среди букв Q букву O без хвостика
Тут, ИМХО, можно не просто ловить какие‑то конкретные паттерны типа длинных строк или множества однотипных конструкций, которые уязвимы перед зрением, а генерировать для кода тепловую карту удобочитаемости (сеткой и/или алгоритмами).Карту можно выводить прямо в IDE (типа под плохим кодом постепенно проступают красные пятна) или просто искать на карте экстремумы и выводить их в лог.
Именно. Подобная штука не гарантирует защиту, а лишь добавляет ещё один эшелон обороны, усложняя жизнь мошенникам и уменьшая вероятность их успеха. Раньше пользователь просто пролистывал, а теперь он видит нечто, вызывающее прилив кортизола и создающее препятствия для дальнейших шагов (так как просто нажать ок не получится). Мошенникам придётся придумать и ввести дополнительные шаги в свои схемы (уговаривать + объяснять как это преодолеть), повышая её хрупкость.
Тут имхо важно не только донести опасность на информационном и эмоциональном уровнях, но и сделать это максимально просто, не апеллируя к понятиям, которые требуют от пользователя компетенций.
А на какой процент это улучшит ситуацию это уже другой вопрос, надо проводить исследования, причём в разных социальных группах, в разных психологических состояниях и при разном воздействии/давлении.
Поэтому вместо
должно быть что‑то типа
Я, конечно, утрирую, но суть примерно такая.
Это ностальгическая кровь
В гравитационном поле электрический заряд тоже не может. В ОТО гравитация не есть сила.
Я говорю про ОТО. В рамках ОТО космонавты на МКС двигаются равномерно без ускорения.
Что интересно — в VB6 то, что скомпилировано в псевдокод (P‑Code) на современных компах работает гораздо быстрее, чем то, что скомпилировано в Native Code. Чуть ли не на порядок. По крайней мере так было на всех компах, где я тестил (Win7/8/8.1/11).
Равномерное движение относительно, ускоренное движение абсолютно. Ускорение можно узнать в локальной системе отсчёта с помощью всяких акселерометров‑весов с маятниками, то есть ускорение не зависит от системы отсчёта.
Если в клиенте какая‑нибудь уязвимость, то такое может быть. Банально может быть неофициальный телеграмоватсапов клиент с 50 бекдорами. В официальных клиентах же нет бекдоров, правда?
Многие пользователи не понимают внутреннюю кухню устройств. Они не понимают и не вникают в составляющие части системы и их взаимосвязи. Что там ОС, приложения и разрешения какие то. Для многих людей это не система с внутренними отношениями, а единый цельный объект.
Поэтому, когда оно начинает задавать вопросы про разрешения, человек не понимает что происходит, потому что в его понятийном аппарате нет тех штук, взаимоотношение которых описано на экране. Плюс люди не понимают важность ИБ. В итоге человек воспринимает это как помеху и просто её пролистывает. Как рекламу.
В данном случае оно может объяснить, что такое constrexpr, что такое size_t и что за синтаксис с 0x для совсем уж новичков. Хотя в статьях, где присутствуют подобные штуки, новички редко обитают.
Можно просто справа вверху иконку сделать и всё, при наведении появляется тултип «Объяснить код с SourceCraft».
Если на первых порах надо привлечь внимание, то можно чтобы она периодически (то есть не всё время) ненавязчиво сияла, подпрыгивала или покачивалась. Ну или жонглировала черными штуками используя оранжевокрасные как руки, если заморачиваться. Главное не перегнуть палку, чтобы не раздражало.
Еще можно объяснение выстраивать учитывая профиль того, кто читает. Если у него там 735 статей про написание драйверов на С, то азы ему объяснять не надо, надо сразу к делу и с терминологией. А если видно, что он новичок и/или у него другая профессия — то надо разжевывать, и тому подобное.
Инпутлаговое нарисованное MFG же. Играть можно, но не во всё. В BF6 и синглплеерах это можно вытерпеть, в CS с его сумасшедшими таймингами — нет.
Оно и 12К тянет вполне, даже в нативе (BF6 и Metro Exodus 12K выдавали где‑то 40–50 фпс), и GPT OSS 120b тянет 15 токенов/сек (а Qwen 3 Coder 30b вообще 192 т/с). В 3ds max можно почти в реалтайме рендерить Арнольдом прямо во вьюпорте. У меня даже получалось рендерить 16K (15360×8640) изображения на GPU, что раньше было за гранью. Ещё тут не 2, как у предыдущих карточек, а 3 аппаратных видеоэнкодера — можно поставить какой‑нибудь ffmpeg/Premiere кодировать видео и параллельно продолжать работать/играть.
Но: ИМХО, самая главная сила у неё не в ядрах и +100500 фпс, как заявляет маркетинг, а в большем количестве памяти, потому что малейшая её нехватка для любой задачи существенно просаживает производительность. Тот же Deathloop у меня жрет ~30 Гб VRAM, то есть впритык. Если с ним параллельно запустить хоть что‑то маленькое, FPS сажается раз в 10 и начинаются лютые лаги. Соответственно, на 4090 он уже бы просто не заработал.
PS. Вроде как карточке уже джейлбрейкнули интерконнект, чтобы если их несколько штук втыкаешь для ИИ, они могли между собой общаться напрямую (не полонценный Nvlink, просто ускорение взаимодействия через PCIE). Разумеется, гарантия после такого отправляется в помойку.
Будет написано на новом модном фраемворке, в котором иконка будет храниться в виде промпта который будет на каждой прорисовке отправляться в облако Azue вместе с вашими файлами, чтобы их ИИ отрисовал современную стильную дизайнерскую пиктограмму, каждый пиксель которой будет отправлен отдельным json пакетом.
Ну всё, теперь оно будет жрать 6 Гб ОЗУ и 3 Гб видеопамяти, и загружаться 10 секунд.
Будьте так добры, пожалуйста, не трогайте. Просто пусть как было будет.
Есть такое, она довольно поверхностно объясняет, и больше про то, какую задачу код решает, а не как именно он это делает и почему именно так. Фактически это выглядит как перевод с языка программирования на русский.
Однако мне понравилось, что он понимает контекст статьи, даже если она довольно большая (затестил на своей про подсветку на 500 вт), связывает смысл кода с решаемой задачей и понимает довольно хитрые приёмы.
Код с двойными указателями
Но вот на этом фрагменте я понял, что коменты в коде оно не читает.
Вычисление прозрачности картинки на основе яркости с использованием SIMD
То есть оно как-бы более-менее перечислило, что там происходит, но не последовательно, потеряло нить, можно сказать. Лучше было бы что‑то в духе «на входе X, на выходе Y, делаем сначала это, потом это, потом это».
В целом, имхо, для начала функция норм. Только я бы кнопку сделал маленькой‑квадратной и поместил бы в правый верхний угол области с кодом, чтобы она не занимала столько места.
Если я правильно понимаю, то проверки для всех трёх измерений идентичны, поэтому можно сделать как‑то так:
Массивы в C# — это аллокации в куче. В подавляющем большинстве случаев на них пофиг, особенно если они короткоживущие. Но если среда выполнения обладает кривым сборщиком мусора и код выполняется слишком часто, это может вызывать подлагивания даже на 0 поколении.
В.NET 10, ЕМНИП, завезли аллокацию массивов на стеке, если компилятор видит, что это не разрушит логику, ИМХО, Ваш пример туда как раз попадает. Поэтому в.NET 10 проблем точно не должно быть.
..или просто большой.
Скрытый текст
Да) Я сам минут 10 искал, и таки нашёл. Сейчас решил эксперимент поставить на локальной Qwen3-vl-30b
Она почти сразу распрощалась с кукухой
Мне кажется смысл тут в том, чтобы код был написан так, чтобы глаза цеплялись за важное и не цеплялись за неважное. Чем больше расхождение, тем выше вероятность что‑то пропустить, поэтому нужно учитывать особенности зрения.
Глаза эволюционно сделаны для поиска всяких бананов в листве и мамонтов с саблезубыми кошками в траве. Картинка обрабатывается уже на уровне сетчатки, выделяются ключевые паттерны и передаются в зрительный нерв, вроде бы даже доказано, что там какое‑то подобие разложения Фурье происходит.
Если глаз видит кучу подобных объектов (типа травинок), то они передаются в мозг не по отдельности, а как «куча объектов которые в среднем похожи на травинку» или вообще как шум такого‑то цвета такой‑то интенсивности.
ИМХО проблема кода типа
не в длине строки как таковой, а в том, что тут куча подобных объектов, слабо отличающихся друг от друга. И зрение «на аппаратном уровне» это не фильтрует. Это буквально аналог всяких загадок типа такой.
Тут, ИМХО, можно не просто ловить какие‑то конкретные паттерны типа длинных строк или множества однотипных конструкций, которые уязвимы перед зрением, а генерировать для кода тепловую карту удобочитаемости (сеткой и/или алгоритмами). Карту можно выводить прямо в IDE (типа под плохим кодом постепенно проступают красные пятна) или просто искать на карте экстремумы и выводить их в лог.
Добросовестная конкуренция. Иначе это источник не прогресса, а кое‑чего другого.