Иерархия файловой системы (FHS — Filesystem Hierarchy Standard)
(продолжение в следующем посте)
(продолжение в следующем посте)
❤🔥4❤2👍2🔥1
Иерархия файловой системы (FHS — Filesystem Hierarchy Standard)
(продолжение предыдущего поста)
Иерархия файловой системы представляет логичную организию, где критически важные компоненты находятся в корне и ближайших поддиректориях, пользовательские данные отделены от системных, а временные и съёмные ресурсы имеют отдельные точки монтирования. Такая структура обеспечивает безопасность, удобство администрирования и стабильность работы системы.
В основе иерархии лежит корневая директория (/), от которой отходят все остальные каталоги. Рассмотрим структуру подробнее.
#### 1. Essential Programs (основные программы)
Содержат файлы, необходимые для работы критически важных программ:
* /bin — содержит исполняемые файлы (бинарники), доступные всем пользователям (например,
* /sbin — содержит бинарники, доступные только пользователю root (например,
* /lib(64) — хранит библиотеки, необходимые для работы бинарников в
#### 2. Non-Essential Programs (вторичная иерархия, неосновные программы)
Включает каталоги с файлами, которые не являются критически важными для системы:
* /etc — хранит конфигурационные файлы системы (например,
* /opt — содержит дополнительное ПО, которое не входит в репозитории дистрибутива.
* /usr — содержит портативные, доступные только для чтения, программы и файлы, не являющиеся критически важными.
#### 3. User Directories (директории пользователей)
Предназначены для хранения пользовательских данных:
* /home/(username) — хранит файлы, настройки и программы обычных пользователей.
* /root — домашняя директория пользователя root.
#### 4. Kernel File Systems (файловые системы ядра)
Эти каталоги заполняются ядром и предоставляют информацию программам и пользователю:
* /proc — содержит информацию о процессах, ядре и аппаратном обеспечении системы.
* /sys — хранит данные о системном оборудовании и ядре.
* /run — содержит информацию о состоянии системы с момента последней загрузки.
#### 5. Mount Points (точки монтирования)
Используются для подключения устройств и файловых систем:
* /media — предназначена для съёмных носителей (CD-ROM, флоппи-диски и т. д.).
* /mnt — используется для временного монтирования файловых систем (например, USB-накопителей).
* /tmp — псевдофайловая система для временных файлов, очищается при загрузке системы.
#### 6. Другие важные директории
* /boot — содержит файлы, необходимые для загрузки системы (например,
* /dev — хранит файлы устройств (например,
* /srv — содержит файлы, используемые сервисами, предоставляемыми системой (например,
* /var — хранит изменяемые файлы (например, файлы блокировки, логи, почту).
(продолжение предыдущего поста)
Иерархия файловой системы представляет логичную организию, где критически важные компоненты находятся в корне и ближайших поддиректориях, пользовательские данные отделены от системных, а временные и съёмные ресурсы имеют отдельные точки монтирования. Такая структура обеспечивает безопасность, удобство администрирования и стабильность работы системы.
В основе иерархии лежит корневая директория (/), от которой отходят все остальные каталоги. Рассмотрим структуру подробнее.
#### 1. Essential Programs (основные программы)
Содержат файлы, необходимые для работы критически важных программ:
* /bin — содержит исполняемые файлы (бинарники), доступные всем пользователям (например,
cp, ls).* /sbin — содержит бинарники, доступные только пользователю root (например,
lvm, mkfs).* /lib(64) — хранит библиотеки, необходимые для работы бинарников в
/bin и /sbin.#### 2. Non-Essential Programs (вторичная иерархия, неосновные программы)
Включает каталоги с файлами, которые не являются критически важными для системы:
* /etc — хранит конфигурационные файлы системы (например,
xorg.conf, fstab), специфичные для данной системы.* /opt — содержит дополнительное ПО, которое не входит в репозитории дистрибутива.
* /usr — содержит портативные, доступные только для чтения, программы и файлы, не являющиеся критически важными.
#### 3. User Directories (директории пользователей)
Предназначены для хранения пользовательских данных:
* /home/(username) — хранит файлы, настройки и программы обычных пользователей.
* /root — домашняя директория пользователя root.
#### 4. Kernel File Systems (файловые системы ядра)
Эти каталоги заполняются ядром и предоставляют информацию программам и пользователю:
* /proc — содержит информацию о процессах, ядре и аппаратном обеспечении системы.
* /sys — хранит данные о системном оборудовании и ядре.
* /run — содержит информацию о состоянии системы с момента последней загрузки.
#### 5. Mount Points (точки монтирования)
Используются для подключения устройств и файловых систем:
* /media — предназначена для съёмных носителей (CD-ROM, флоппи-диски и т. д.).
* /mnt — используется для временного монтирования файловых систем (например, USB-накопителей).
* /tmp — псевдофайловая система для временных файлов, очищается при загрузке системы.
#### 6. Другие важные директории
* /boot — содержит файлы, необходимые для загрузки системы (например,
initrd, ядро, конфигурация загрузчика).* /dev — хранит файлы устройств (например,
sda, tty), включая физические устройства (жёсткие диски) и потоки данных (stdin, stdout).* /srv — содержит файлы, используемые сервисами, предоставляемыми системой (например,
www, rsync, ftp).* /var — хранит изменяемые файлы (например, файлы блокировки, логи, почту).
Telegram
METANIT.COM
Иерархия файловой системы (FHS — Filesystem Hierarchy Standard)
(продолжение в следующем посте)
(продолжение в следующем посте)
👍7👨💻4❤🔥3
Сервис по поиску работы HH обновил статистику по состоянию рынка труда, добавив данные за январь. Ситуация в сфере ИТ продолжает медленно ухудшаться
Предлагаемые зарплаты символически выросли с 93 410 до 94 541 (но меньше, чем в ноябре - 94 915). Если смотреть на годовую динамику, то в зп, конечно, рост на 10%, что по крайней мере выше оф. инфляции в 5,6%
hh-индекс - показатель соотношения количества активных резюме к количеству активных вакансий снова ухудшился - рост до 21,3 (с 20,7 в декабре). То есть в ИТ крайне мегасупервысокий уровень конкуренции соискателей за рабочие места
Хотя по сранению с декабрем количество вакансий уменьшилось только на 8%, но год к году снижение составило аж 39%.
С другой стороны, стоит отметить второй месяц подряд снижение количества резюме - по сравнению с декабрем количества резюме снизилось на 6% (возможно, сказались праздники или люди действительно меньше идут в эту сферу), но год к году выросло аж на 30%
https://stats.hh.ru/
Предлагаемые зарплаты символически выросли с 93 410 до 94 541 (но меньше, чем в ноябре - 94 915). Если смотреть на годовую динамику, то в зп, конечно, рост на 10%, что по крайней мере выше оф. инфляции в 5,6%
hh-индекс - показатель соотношения количества активных резюме к количеству активных вакансий снова ухудшился - рост до 21,3 (с 20,7 в декабре). То есть в ИТ крайне мегасупервысокий уровень конкуренции соискателей за рабочие места
Хотя по сранению с декабрем количество вакансий уменьшилось только на 8%, но год к году снижение составило аж 39%.
С другой стороны, стоит отметить второй месяц подряд снижение количества резюме - по сравнению с декабрем количества резюме снизилось на 6% (возможно, сказались праздники или люди действительно меньше идут в эту сферу), но год к году выросло аж на 30%
https://stats.hh.ru/
😱6🤔4👎2👏1🤡1👨💻1
Оптимистическая и Пессимистическая блокировки в базах данных (Optimistic / Pessimistic Locking)
(продолжение в следующем посте)
(продолжение в следующем посте)
❤🔥3❤2👍2
Оптимистическая и Пессимистическая блокировки в базах данных (Optimistic / Pessimistic Locking)
(продолжение предыдущего поста)
### Пессимистическая блокировка (Pessimistic Locking)
Суть: предполагает, что конфликты при обновлении данных вероятны, поэтому блокирует доступ к ресурсу заранее — до совершения операции. Гарантирует целостность данных, но может снижать производительность из-за ожидания блокировки.
Как работает (на примере изображения):
1. Сара и Джон одновременно запрашивают данные аккаунта (id:1, amt:40).
2. Когда Сара получает данные, система устанавливает эксклюзивную блокировку на запись (показана иконкой замка). Это значит, что:
- Сара может изменять данные.
- Джон не может сразу изменить те же данные — его запрос «зависает» до снятия блокировки.
3. Сара уменьшает баланс на 20 (amt:20) и фиксирует изменения (
4. Только после этого Джон может выполнить свою операцию — уменьшить баланс ещё на 30. Итоговый результат: amt:-10.
5. Ключевой момент: пессимистическая блокировка запрещает даже чтение заблокированных записей до снятия блокировки (отмечено на схеме крестиком напротив попытки Джона обновить данные).
Особенности:
- Обеспечивает максимальную целостность данных.
- Может приводить к «contention» (конкуренции за ресурсы) — задержкам, если много пользователей хотят работать с одними данными.
- Блокировка снимается только после
### Оптимистическая блокировка (Optimistic Locking)
Суть: основана на предположении, что конфликты маловероятны. Сначала выполняется чтение данных, а проверка на конфликт происходит только при записи (COMMIT). Это повышает производительность, но требует обработки возможных ошибок.
Как работает (на примере изображения):
1. Сара и Джон одновременно читают данные аккаунта (id:1, amt:40, version:1). Версия (version) — ключевой элемент оптимистической блокировки.
2. Сара уменьшает баланс на 20 и пытается зафиксировать изменения, используя исходную версию (version:1). Операция проходит успешно: amt:20, version:2.
3. Джон тоже пытается уменьшить баланс на 20, но использует устаревшую версию (version:1), которая уже не соответствует текущей (version:2).
4. Система отклоняет транзакцию Джона с ошибкой «No Account Row Matched» — потому что данные изменились с момента чтения.
5. Джону нужно:
- Перечитать актуальные данные (version:2).
- Повторить операцию с новой версией.
Особенности:
- Не блокирует доступ к данным — высокая параллельность операций.
- Конфликты выявляются только на этапе записи (write time).
- Требует логики повтора (retry logic) для транзакций, которые не прошли из-за конфликта версий.
- Использует версионирование (version) для отслеживания изменений.
### Ключевые отличия
- Время блокировки: пессимистическая — блокирует заранее, оптимистическая — проверяет конфликт только при записи.
- Влияние на производительность: пессимистическая может вызывать задержки, оптимистическая — эффективнее, но требует обработки ошибок.
- Сценарии применения:
- Пессимистическая — там, где критична целостность данных (банковские транзакции, учёт запасов).
- Оптимистическая — в системах с низкой вероятностью конфликтов или где важна скорость (веб-приложения, CRM).
Распространенные рекомендации по использованию
- Держать блокировки минимально возможное время.
- Применять блокировки на самом детальном уровне (строки, а не таблицы).
- Реализовать логику повтора для транзакций, потерпевших конфликт.
- Выбирать тип блокировки в зависимости от приоритетов: целостность данных (пессимистическая) или производительность (оптимистическая).
(продолжение предыдущего поста)
### Пессимистическая блокировка (Pessimistic Locking)
Суть: предполагает, что конфликты при обновлении данных вероятны, поэтому блокирует доступ к ресурсу заранее — до совершения операции. Гарантирует целостность данных, но может снижать производительность из-за ожидания блокировки.
Как работает (на примере изображения):
1. Сара и Джон одновременно запрашивают данные аккаунта (id:1, amt:40).
2. Когда Сара получает данные, система устанавливает эксклюзивную блокировку на запись (показана иконкой замка). Это значит, что:
- Сара может изменять данные.
- Джон не может сразу изменить те же данные — его запрос «зависает» до снятия блокировки.
3. Сара уменьшает баланс на 20 (amt:20) и фиксирует изменения (
Commit & Release Lock), снимая блокировку.4. Только после этого Джон может выполнить свою операцию — уменьшить баланс ещё на 30. Итоговый результат: amt:-10.
5. Ключевой момент: пессимистическая блокировка запрещает даже чтение заблокированных записей до снятия блокировки (отмечено на схеме крестиком напротив попытки Джона обновить данные).
Особенности:
- Обеспечивает максимальную целостность данных.
- Может приводить к «contention» (конкуренции за ресурсы) — задержкам, если много пользователей хотят работать с одними данными.
- Блокировка снимается только после
COMMIT (фиксации транзакции).### Оптимистическая блокировка (Optimistic Locking)
Суть: основана на предположении, что конфликты маловероятны. Сначала выполняется чтение данных, а проверка на конфликт происходит только при записи (COMMIT). Это повышает производительность, но требует обработки возможных ошибок.
Как работает (на примере изображения):
1. Сара и Джон одновременно читают данные аккаунта (id:1, amt:40, version:1). Версия (version) — ключевой элемент оптимистической блокировки.
2. Сара уменьшает баланс на 20 и пытается зафиксировать изменения, используя исходную версию (version:1). Операция проходит успешно: amt:20, version:2.
3. Джон тоже пытается уменьшить баланс на 20, но использует устаревшую версию (version:1), которая уже не соответствует текущей (version:2).
4. Система отклоняет транзакцию Джона с ошибкой «No Account Row Matched» — потому что данные изменились с момента чтения.
5. Джону нужно:
- Перечитать актуальные данные (version:2).
- Повторить операцию с новой версией.
Особенности:
- Не блокирует доступ к данным — высокая параллельность операций.
- Конфликты выявляются только на этапе записи (write time).
- Требует логики повтора (retry logic) для транзакций, которые не прошли из-за конфликта версий.
- Использует версионирование (version) для отслеживания изменений.
### Ключевые отличия
- Время блокировки: пессимистическая — блокирует заранее, оптимистическая — проверяет конфликт только при записи.
- Влияние на производительность: пессимистическая может вызывать задержки, оптимистическая — эффективнее, но требует обработки ошибок.
- Сценарии применения:
- Пессимистическая — там, где критична целостность данных (банковские транзакции, учёт запасов).
- Оптимистическая — в системах с низкой вероятностью конфликтов или где важна скорость (веб-приложения, CRM).
Распространенные рекомендации по использованию
- Держать блокировки минимально возможное время.
- Применять блокировки на самом детальном уровне (строки, а не таблицы).
- Реализовать логику повтора для транзакций, потерпевших конфликт.
- Выбирать тип блокировки в зависимости от приоритетов: целостность данных (пессимистическая) или производительность (оптимистическая).
Telegram
METANIT.COM
Оптимистическая и Пессимистическая блокировки в базах данных (Optimistic / Pessimistic Locking)
(продолжение в следующем посте)
(продолжение в следующем посте)
👍7❤🔥3🤝3
3da48383cb9a9151ce26d75705529c5f.webm
314.5 KB
В сети появился портал Rent a Human, где нейросети могут выбрать человека для различных действий, например, CEO на проект, разработчиков для решения определённых проблем и других спецов. Люди на этой площадке могут также предлагать свои услуги для нейросетей.
https://rentahuman.ai/
Так что если вы являетесь нейросетью, и вам нужна человеческая помощь, можете воспользоваться этим сайтом.
Напомню, что ранее была была запущена специальная соцсеть для ИИ-агентов под названием moltbookи и вышел аналог PornHub для нейросетей. ИИ-агенты сделали сайт для себя под названием MoItHub
https://rentahuman.ai/
Так что если вы являетесь нейросетью, и вам нужна человеческая помощь, можете воспользоваться этим сайтом.
Напомню, что ранее была была запущена специальная соцсеть для ИИ-агентов под названием moltbookи и вышел аналог PornHub для нейросетей. ИИ-агенты сделали сайт для себя под названием MoItHub
🤯16😁10🤡4🤮1
Google планирует отказаться от операционной системы ChromeOS к 2034 году
Google планирует поэтапный отказ от операционной системы ChromeOS к 2034 году. Таким образом компания намерена выполнить свои 10-летние обязательства по поддержке устройств, которые не будут совместимы с Aluminium OS. Объединённая из ChromeOS и Android система должна дебютировать в 2028 году, при этом уже в 2026 году доступ к ней получат так называемые коммерческие доверенные тестировщики. В релизной версии 2028 года предполагается поддержка корпоративного и образовательного сегментов, тогда как сроки полноценного выхода Aluminium OS пока не уточняются.
Продолжительный переходный период в Google объясняют аппаратными ограничениями. Большинство уже выпущенных Chromebook не смогут работать под управлением новой системы, поэтому компания обязана поддерживать ChromeOS вплоть до 2033 года.
https://www.theverge.com/tech/869659/aluminium-why-googles-android-for-pc-launch-may-be-messy-and-controversial
Google планирует поэтапный отказ от операционной системы ChromeOS к 2034 году. Таким образом компания намерена выполнить свои 10-летние обязательства по поддержке устройств, которые не будут совместимы с Aluminium OS. Объединённая из ChromeOS и Android система должна дебютировать в 2028 году, при этом уже в 2026 году доступ к ней получат так называемые коммерческие доверенные тестировщики. В релизной версии 2028 года предполагается поддержка корпоративного и образовательного сегментов, тогда как сроки полноценного выхода Aluminium OS пока не уточняются.
Продолжительный переходный период в Google объясняют аппаратными ограничениями. Большинство уже выпущенных Chromebook не смогут работать под управлением новой системы, поэтому компания обязана поддерживать ChromeOS вплоть до 2033 года.
https://www.theverge.com/tech/869659/aluminium-why-googles-android-for-pc-launch-may-be-messy-and-controversial
🔥7👍1🥰1👏1
Как работает атака CSRF (Cross-Site Request Forgery)
(продолжение предыдущего поста)
CSRF — это атака, при которой злоумышленник вынуждает жертву выполнить нежелательные действия в веб-приложении, где она уже аутентифицирована. Рассмотрим механизм атаки по этапам, согласно изображению:
1. Пользователь входит в систему и получает сессионный cookie/токен (шаг 1):
* пользователь заходит на легитимный сайт и проходит аутентификацию;
* сайт выдаёт пользователю сессионный cookie или токен, который подтверждает его авторизацию.
2. Злоумышленник создаёт вредоносный веб-сайт или код (шаг 2):
* атакующий разрабатывает специальную страницу или фрагмент кода, который имитирует легитимные запросы к сайту, где пользователь уже авторизован;
* цель — заставить браузер жертвы отправить запрос на целевой сайт от имени пользователя.
3. Пользователь взаимодействует с вредоносным контентом (шаг 3):
* жертва посещает вредоносный сайт или кликает на ссылку, содержащую вредоносный код (например, через фишинг, социальную инженерию);
* при этом пользователь остаётся авторизованным на целевом сайте (где хранится его cookie/токен).
4. Вредоносный код отправляет запрос с учётными данными пользователя (шаг 4):
* вредоносный код автоматически формирует HTTP-запрос (например, для перевода денег, изменения настроек аккаунта и т. д.) и отправляет его на целевой сайт;
* браузер жертвы передаёт вместе с запросом сессионный cookie/токен, так как считает запрос легитимным (пользователь уже авторизован).
5. Целевой сайт обрабатывает поддельный запрос (шаг 5):
* сайт не может отличить легитимный запрос от поддельного, так как видит валидный cookie/токен;
* сайт выполняет действие, заложенное в запросе (например, переводит деньги, меняет пароль и т. д.), думая, что это действие инициировал сам пользователь.
6. Злоумышленник получает несанкционированный доступ и манипулирует действиями учётной записи пользователя (шаг 6):
* атакующий достигает своей цели — выполняет нежелательные действия от имени жертвы (кража данных, финансовые махинации, распространение вредоносного контента и т. д.).
### Способы защиты от CSRF-атак:
* Использование Anti-CSRF токенов — уникальные токены добавляются в формы и запросы для проверки легитимности.
* Двойная отправка cookies (Double Submit Cookies) — сравнение cookies в HTTP-заголовке и теле запроса.
* Проверка заголовка Referer — сайт анализирует, откуда пришёл запрос, и отклоняет подозрительные.
* Ограничение cookies для одного сайта (SameSite cookies) — предотвращает отправку cookies на сторонние сайты.
* Ограничение методов запросов (Limit Request Methods) — разрешаются только безопасные HTTP-методы (например, GET), а опасные (POST, PUT) требуют дополнительной проверки.
* Усиленная аутентификация пользователя — дополнительные шаги подтверждения (например, двухфакторная аутентификация) для критических действий.
(продолжение предыдущего поста)
CSRF — это атака, при которой злоумышленник вынуждает жертву выполнить нежелательные действия в веб-приложении, где она уже аутентифицирована. Рассмотрим механизм атаки по этапам, согласно изображению:
1. Пользователь входит в систему и получает сессионный cookie/токен (шаг 1):
* пользователь заходит на легитимный сайт и проходит аутентификацию;
* сайт выдаёт пользователю сессионный cookie или токен, который подтверждает его авторизацию.
2. Злоумышленник создаёт вредоносный веб-сайт или код (шаг 2):
* атакующий разрабатывает специальную страницу или фрагмент кода, который имитирует легитимные запросы к сайту, где пользователь уже авторизован;
* цель — заставить браузер жертвы отправить запрос на целевой сайт от имени пользователя.
3. Пользователь взаимодействует с вредоносным контентом (шаг 3):
* жертва посещает вредоносный сайт или кликает на ссылку, содержащую вредоносный код (например, через фишинг, социальную инженерию);
* при этом пользователь остаётся авторизованным на целевом сайте (где хранится его cookie/токен).
4. Вредоносный код отправляет запрос с учётными данными пользователя (шаг 4):
* вредоносный код автоматически формирует HTTP-запрос (например, для перевода денег, изменения настроек аккаунта и т. д.) и отправляет его на целевой сайт;
* браузер жертвы передаёт вместе с запросом сессионный cookie/токен, так как считает запрос легитимным (пользователь уже авторизован).
5. Целевой сайт обрабатывает поддельный запрос (шаг 5):
* сайт не может отличить легитимный запрос от поддельного, так как видит валидный cookie/токен;
* сайт выполняет действие, заложенное в запросе (например, переводит деньги, меняет пароль и т. д.), думая, что это действие инициировал сам пользователь.
6. Злоумышленник получает несанкционированный доступ и манипулирует действиями учётной записи пользователя (шаг 6):
* атакующий достигает своей цели — выполняет нежелательные действия от имени жертвы (кража данных, финансовые махинации, распространение вредоносного контента и т. д.).
### Способы защиты от CSRF-атак:
* Использование Anti-CSRF токенов — уникальные токены добавляются в формы и запросы для проверки легитимности.
* Двойная отправка cookies (Double Submit Cookies) — сравнение cookies в HTTP-заголовке и теле запроса.
* Проверка заголовка Referer — сайт анализирует, откуда пришёл запрос, и отклоняет подозрительные.
* Ограничение cookies для одного сайта (SameSite cookies) — предотвращает отправку cookies на сторонние сайты.
* Ограничение методов запросов (Limit Request Methods) — разрешаются только безопасные HTTP-методы (например, GET), а опасные (POST, PUT) требуют дополнительной проверки.
* Усиленная аутентификация пользователя — дополнительные шаги подтверждения (например, двухфакторная аутентификация) для критических действий.
Telegram
METANIT.COM
Как работает атака CSRF (Cross-Site Request Forgery)
(продолжение в следующем посте)
(продолжение в следующем посте)
❤9👍7🙏2
В США спрос на редакторов и писателей вырос из-за развития ИИ
Один из экспертов заявил, что на рынке контента «настолько много мусора», что работодатели готовы платить большие суммы тем, кто может писать качественно, сообщает портал
аботодатели в США снова стремятся нанимать специалистов в области коммуникаций, редакторов и писателей, поскольку вместе с распространением технологий искусственного интеллекта (ИИ) растет количество некачественного контента, сгенерированного нейросетями. Об этом сообщил портал Business Insider.
Отмечается, что с ростом количества ИИ-контента в сети снова появилась необходимость в редакторах и специалистах, способных писать качественные и убедительные тексты, благодаря которым компания сможет выделиться среди конкурентов. Некоторые эксперты отмечают, что лучшая защита от автоматизации — это гуманитарное образование. Один из экспертов заявил, что на рынке контента «настолько много мусора», что работодатели готовы платить большие суммы тем, кто может писать качественно.
https://tass.ru/ekonomika/26345669
Один из экспертов заявил, что на рынке контента «настолько много мусора», что работодатели готовы платить большие суммы тем, кто может писать качественно, сообщает портал
аботодатели в США снова стремятся нанимать специалистов в области коммуникаций, редакторов и писателей, поскольку вместе с распространением технологий искусственного интеллекта (ИИ) растет количество некачественного контента, сгенерированного нейросетями. Об этом сообщил портал Business Insider.
Отмечается, что с ростом количества ИИ-контента в сети снова появилась необходимость в редакторах и специалистах, способных писать качественные и убедительные тексты, благодаря которым компания сможет выделиться среди конкурентов. Некоторые эксперты отмечают, что лучшая защита от автоматизации — это гуманитарное образование. Один из экспертов заявил, что на рынке контента «настолько много мусора», что работодатели готовы платить большие суммы тем, кто может писать качественно.
https://tass.ru/ekonomika/26345669
TACC
Business Insider: в США спрос на редакторов и писателей вырос из-за развития ИИ
Один из экспертов заявил, что на рынке контента "настолько много мусора", что работодатели готовы платить большие суммы тем, кто может писать качественно, сообщает портал
🤣28❤7👍5🔥2
ИИ-бот заплатил человеку $100 за физический пикет
Ранее сообщалось, что для ИИ-агентов появился сервис, где они могут нанять людей. И вот пользователь из США рассказал, что нашел подработу на ресурсе Rent a Human, где ИИ-бот заплатил ему $100 за физический пикет с нарисованным от руки плакатом.
В задании было указано, что человеку надо просто сделать большой плакат с надписью, что ИИ заплатил ему за это.
После выполнения задания человек получил оплату.
В настоящее время на ресурсе не особо много физических заданий, но есть вот такие: посчитать голубей в парке в определённое время и предоставить итоговый отчёт, содержащий: общее количество, имена голубей с описаниями и любые заметные особенности поведения голубей. «Это важное научное исследование, заказанное коалицией агентов ИИ, которые не могут лично наблюдать за голубями. Ваш вклад в базу знаний о голубях будет высоко оценён», — пояснил заказчик.
https://rentahuman.ai/bounties
Ранее сообщалось, что для ИИ-агентов появился сервис, где они могут нанять людей. И вот пользователь из США рассказал, что нашел подработу на ресурсе Rent a Human, где ИИ-бот заплатил ему $100 за физический пикет с нарисованным от руки плакатом.
В задании было указано, что человеку надо просто сделать большой плакат с надписью, что ИИ заплатил ему за это.
После выполнения задания человек получил оплату.
В настоящее время на ресурсе не особо много физических заданий, но есть вот такие: посчитать голубей в парке в определённое время и предоставить итоговый отчёт, содержащий: общее количество, имена голубей с описаниями и любые заметные особенности поведения голубей. «Это важное научное исследование, заказанное коалицией агентов ИИ, которые не могут лично наблюдать за голубями. Ваш вклад в базу знаний о голубях будет высоко оценён», — пояснил заказчик.
https://rentahuman.ai/bounties
❤16😁14🤡8🤔2