На старых устройствах пользователи уже залогинены (и, как правило, не разлогиниваются без необходимости). А вот процедура переноса такого ключа на новый смартфон неясна.
Если труд организован правильно, то, хочется верить, что будет создан корпоративный аккаунт. Если же работодатель заставляет дизайнера регистрироваться на свою личную почту, то, да, передача персональных данных.
В данном случае, это уже будет проблема сервиса LLM, насколько он соответствует законам. Пока что россиянам не запрещено пользоваться иностранными сервисами, обрабатывающими их персональные данные. Поэтому ответственность здесь будет не на стороне дизайнера.
Далеко не в каждой задаче, связанной с использованием LLM, используются персональные данные. Например, дизайнеру, использующему графические модели для быстрого прототипирования, вообще, персональные данные в работе не нужны, поэтому данный риск не всем актуален. А так, сотрудники могут персональные данные и в Гугле по дурости вбивать.
Корректнее было бы описывать, какие модели (и по какому тарифу) для каких задач подходят. А то если взять, например, случай обработки врачебной тайны, то я, вот, не уверен, что отчественные модели по бесплатному тарифу (без заключения доп. соглашений) для этого случая подойдут (с учётом возможности дообучения на запросах).
А если атакующий, взломавший виртуальную машину, неспешно через HSM просто зачитает всю базу в кэш? HSM её услужливо и расшифрует, если нет ограничений по числу запросов к HSM.
Идея хорошая. Что до конкретной реализации, политика сервиса у ChatGPT ясна и доступна, а вот у приведённого в примере сервиса опубликованной политики обработки данных я не нашёл, и кому достанутся копии отправленных в сервис данных, не ясно. Поэтому с копированием в него чувствительной информации я бы не торопился, а лучше бы нашёл что-то, что можно запускать локально.
close() closes a file descriptor, so that it no longer refers to any file and may be reused.
То бишь по крайней мере если мы пишем прямо на С и используем системные функции без каких-то обёрток сделанных языком более высокого уровня, то сокет (точнее файловый дескриптор созданный вызовом socket(...)) переиспользовать все-таки можно - главное закрыть его!
Тут речь идёт не о переиспользовании переменной в юзерспейсе, а о том, что после закрытия файлового дескриптора в ядре, это место в таблице файловых дескрипторов процесса станет свободным, и при открытии нового файла или сокета, ядро просто переиспользует первый свободный дескриптор.
Например, если вы закроете STDIN (дескриптор которого имеет номер 0), а затем откроете любой файл, то у этого файла дескриптор будет 0 за счёт переиспользования. Но этот дескриптор уже не будет иметь никакого отношения к тому, что было нулём раньше. И в этом плане никакое переиспользование в юзерспейсе не выйдет.
Если операционная система это позвляет, если эти API не входят в число запрещённых для использвания приложениями в сторе, если root не требуется, то, я считаю, это всё-таки Android. Хоть и низкоуровневая реализация, а не готовый высокоуровневый компонент.
На мой взгляд, пережёвывать 600 мегабайт в секунду -- это уже нетривиальная задача. Старые карты памяти, например, банально не справятся с такой записью. А если хранилище ещё и зашифровано (как это сейчас принято), то надо мерить, вообще, пропускную способность криптоускорителя.
Кстати, я бы начал с простого теста. Создал бы в памяти буфер, допустим в 128 мегабайт случайного мусора, а потом стал бы случайные его части размером в 32 мегабайта (для ускорения, выровненные по границе страницы памяти) писать в файл по разным смещениям параллельно, чтобы сэмулировать многопоточную запись кадров видео фиксированного размера. И посмотрел бы, а успевает ли железо шифровать и записывать 600 мегабайт в секунду, в принципе?
Главное, чтобы метаданные были фиксированного размера. Тогда и можно будет писать в файл параллельно, так как при фиксированном размере удастся заранее вычислять смещение в файле, где будет лежать каждый кадр.
Я имел в виду, не пользоваться стандартными библиотеками, а написать собственный параллельный обработчик, который знает внутреннее устройство ZIP-файла.
У вас тут получается поток данных 25 МБ * 24 кадра = 600 МБ/с. Тут нужно, по возможности, делать zero copy, то есть уменьшать копирование данных из буфера в буфер.
Я детально не разбирался, но выглядит так, что создание того-же DNG может состоять из приклеивания фиксированного заголовка (и хвоста, если требуется), так как все кадры одинаковы, а не изготовление заголовка с нуля для каждого кадра.
Аналогично с непожатым ZIP-архивом. Все кадры вместе с заголовками должны иметь одинаковый размер, а потому писать их можно и параллельно. А в конце доклеить структуру со списком файлов.
Я бы для эксперимента попробовал бы просто писать сырые данные в файл из нескольких потоков параллельно — без заголовков DNG и ZIP («колбаса» кадров). Просто, чтобы убедиться, что такой поток данных успевает обрабатываться.
Указанное дело было в 2023-м году, то есть, вроде как, ещё до закона о рекламе. А есть сейчас практика, когда кого-то оштрафовали, а не только попросили промаркировать непромаркированное?
Хотелось бы ещё описания, насколько указанные схемы законны с точки зрения налогового законодательства, и как все эти платежи должны проводиться, чтобы оставаться «белым и пушистым» с точки зрения закона? Так же был бы полезен расчёт всех дополнительных комиссий и налогов при зарабатывании N денег.
Чтобы продать что-нибудь ненужное, надо сначала купить что-нибудь ненужное, а у нас
денег неткарты не принимают. ©Будет как тут: «VoWiFi = ВоВайФай, Wi-Fi = Вай-Фай». И потребителю сразу понятно, о чём речь, и никаких больше заблуждений.
На старых устройствах пользователи уже залогинены (и, как правило, не разлогиниваются без необходимости). А вот процедура переноса такого ключа на новый смартфон неясна.
Если труд организован правильно, то, хочется верить, что будет создан корпоративный аккаунт. Если же работодатель заставляет дизайнера регистрироваться на свою личную почту, то, да, передача персональных данных.
В данном случае, это уже будет проблема сервиса LLM, насколько он соответствует законам. Пока что россиянам не запрещено пользоваться иностранными сервисами, обрабатывающими их персональные данные. Поэтому ответственность здесь будет не на стороне дизайнера.
Далеко не в каждой задаче, связанной с использованием LLM, используются персональные данные. Например, дизайнеру, использующему графические модели для быстрого прототипирования, вообще, персональные данные в работе не нужны, поэтому данный риск не всем актуален. А так, сотрудники могут персональные данные и в Гугле по дурости вбивать.
Корректнее было бы описывать, какие модели (и по какому тарифу) для каких задач подходят. А то если взять, например, случай обработки врачебной тайны, то я, вот, не уверен, что отчественные модели по бесплатному тарифу (без заключения доп. соглашений) для этого случая подойдут (с учётом возможности дообучения на запросах).
А если атакующий, взломавший виртуальную машину, неспешно через HSM просто зачитает всю базу в кэш? HSM её услужливо и расшифрует, если нет ограничений по числу запросов к HSM.
Вот это, я понимаю, proof of work! :-)
Идея хорошая. Что до конкретной реализации, политика сервиса у ChatGPT ясна и доступна, а вот у приведённого в примере сервиса опубликованной политики обработки данных я не нашёл, и кому достанутся копии отправленных в сервис данных, не ясно. Поэтому с копированием в него чувствительной информации я бы не торопился, а лучше бы нашёл что-то, что можно запускать локально.
Тут речь идёт не о переиспользовании переменной в юзерспейсе, а о том, что после закрытия файлового дескриптора в ядре, это место в таблице файловых дескрипторов процесса станет свободным, и при открытии нового файла или сокета, ядро просто переиспользует первый свободный дескриптор.
Например, если вы закроете STDIN (дескриптор которого имеет номер 0), а затем откроете любой файл, то у этого файла дескриптор будет 0 за счёт переиспользования. Но этот дескриптор уже не будет иметь никакого отношения к тому, что было нулём раньше. И в этом плане никакое переиспользование в юзерспейсе не выйдет.
Согласия сотрудников, допустим, имеются на бумаге. Есть ещё вопрос к юристам: вправе ли РКН проверять их наличие в организации?
Может ли ИП просто звонить со своего личного номера?
Если операционная система это позвляет, если эти API не входят в число запрещённых для использвания приложениями в сторе, если root не требуется, то, я считаю, это всё-таки Android. Хоть и низкоуровневая реализация, а не готовый высокоуровневый компонент.
На мой взгляд, пережёвывать 600 мегабайт в секунду -- это уже нетривиальная задача. Старые карты памяти, например, банально не справятся с такой записью. А если хранилище ещё и зашифровано (как это сейчас принято), то надо мерить, вообще, пропускную способность криптоускорителя.
Кстати, я бы начал с простого теста. Создал бы в памяти буфер, допустим в 128 мегабайт случайного мусора, а потом стал бы случайные его части размером в 32 мегабайта (для ускорения, выровненные по границе страницы памяти) писать в файл по разным смещениям параллельно, чтобы сэмулировать многопоточную запись кадров видео фиксированного размера. И посмотрел бы, а успевает ли железо шифровать и записывать 600 мегабайт в секунду, в принципе?
Главное, чтобы метаданные были фиксированного размера. Тогда и можно будет писать в файл параллельно, так как при фиксированном размере удастся заранее вычислять смещение в файле, где будет лежать каждый кадр.
Я имел в виду, не пользоваться стандартными библиотеками, а написать собственный параллельный обработчик, который знает внутреннее устройство ZIP-файла.
У вас тут получается поток данных 25 МБ * 24 кадра = 600 МБ/с. Тут нужно, по возможности, делать zero copy, то есть уменьшать копирование данных из буфера в буфер.
Я детально не разбирался, но выглядит так, что создание того-же DNG может состоять из приклеивания фиксированного заголовка (и хвоста, если требуется), так как все кадры одинаковы, а не изготовление заголовка с нуля для каждого кадра.
Аналогично с непожатым ZIP-архивом. Все кадры вместе с заголовками должны иметь одинаковый размер, а потому писать их можно и параллельно. А в конце доклеить структуру со списком файлов.
Я бы для эксперимента попробовал бы просто писать сырые данные в файл из нескольких потоков параллельно — без заголовков DNG и ZIP («колбаса» кадров). Просто, чтобы убедиться, что такой поток данных успевает обрабатываться.
Указанное дело было в 2023-м году, то есть, вроде как, ещё до закона о рекламе. А есть сейчас практика, когда кого-то оштрафовали, а не только попросили промаркировать непромаркированное?
Так стратегия же «Максимум прибыли».
Первые пять ссылок на законы битые. Через редиеркт VC ведут на Пикабу, но дальше 404 вместо редиректа на КонсультантПлюс.
Хотелось бы ещё описания, насколько указанные схемы законны с точки зрения налогового законодательства, и как все эти платежи должны проводиться, чтобы оставаться «белым и пушистым» с точки зрения закона? Так же был бы полезен расчёт всех дополнительных комиссий и налогов при зарабатывании N денег.
Или пристегнуть к ключам от квартиры. Тогда не получится уйти, не взяв.