Pull to refresh
1
0.3
Send message

Сам астрой не пользовался, но насколько вижу в Википедии, там в последней астре версия ядра 6-я. Насколько я помню, из 6-версии такт поудаляли 340-е драйвера. Поэтому все счастье закончится когда закончится поддержка последней версии операционки с 5-м ядром. Для линукс минта, если не ошибаюсь, это случится в 2027.

Тут загвоздка в том, что чтобы работать через API, то OpenAI хотят денежек. То есть если копайлот может быть бесплатным, то для линукса платно. Я так понимаю, там бесплатная опция только локальные модели. Но тут момент, что нужно тогда обучить специальную модель, в которой будет немного токенов(чтобы запускать на слабом железе), но при этом она должна быть заточена только на решение задач о линуксу. Причём учитывать, что у кого-то xserver, у кого-то wayland. У кого-то alsa, у кого-то pipewire. У кого-то apt, у кого-то pacman и т.д. Ну ине всем владельцам ноутов может понравится, что время от времени вентиляторы работают как не в себя.

UI софта линукса в андроиде нет, потому что в андроиде нет этих ваших иксов и вайландов, а так софт для терминала, если собрать под ARM(а десктоп у нас обычно не ARM), то в терминале он и должен запускаться. Ну и + то, что андроид телефоны как правило залочены, соответственно, даже через терминал сильно глубоко в систему залезть не получится.

Ну с играми на самом деле всё не так плохо. GTA, Ведьмак, кооперативные игры а-ля It takes too, a way out прошёл без проблем. Но здорово намучался с джойстиком dualshock. Оказалось:

  1. В минте из коробки выключены драйверы playstation

  2. В интерфейсе cinnamon используется менеджер блютуса blueman и вот он как-то некорректно сопрягает этот джойстик. Я посмотрел в логах на стимдеке в каком порядке действия выполняются и проделал тоже в линукс минте через терминал и тогда всё заработало хорошо. Но тут без пришлось покопаться в терминале потому что понадобился bluetoothctl и понадобилось тип сопряжения в конфигурационном файле поменять.

*мол можно так серфить и что-то по мелочи сделать.

Недавно на реддите видел сетап samsung dex + xreal air. Мол можно так сердиться и что-то по мелочи сделать. Интересно, можно ли так с очками от меты.

Теперь чтобы вывезти 80 Тб данных по ИИ надо всего лишь 2 диска и 2 китайца?

Когда-то был выпуск "Адам портит всё", где говорилось, что там чуть ли не половина научных исследований не воспроизводятся. И главная проблема в том, что научных статей слишком много и все проверить невозможно. Поэтому недобросовестные "исследователи" могут сначала печататься в мусорных журналах, а потом перепечатывать свои статьи в нормальные со ссылками.

И вот тут с ИИ проблема в том, что он может написать столько мусорных работ, сколько раньше было сделать невозможно. И это может очень серьёзно усугубить проблему. Поэтому нужно разрабатывать какие-то автоматизированные методики, которые будут помогать выявлять ИИ-статьи.

Попробовал ради интереса вбить. Там ИИ потрэшовее пишет))

Hidden text

ИИ как ангел-хранитель: как алгоритм спас жизнь перегруженного IT-специалиста

Заголовок: От Burnout к Breakthrough: Как Предиктивный ИИ Стал Личным Спасателем для Индийского Разработчика

Введение:
В мире технологий часто говорят о том, как ИИ заменяет рабочие места или оптимизирует процессы. Но реже обсуждают его потенциал буквально спасать жизни. Эта история – не сценарий фантастического фильма, а реальный пример того, как конвергенция носимых устройств, анализа данных и предиктивного ИИ предотвратила трагедию в жизни обычного индийского IT-специалиста. Она заставляет задуматься о новой, гуманистической роли искусственного интеллекта на рабочем месте.

Герой и Его Битва: Раджеш и Тень Burnout
Представьте Раджеша (имя изменено) – талантливого 32-летнего бэкенд-разработчика из Бангалора. Как и тысячи его коллег, он жил в ритме вечных дедлайнов, ночных созвонов с западными клиентами и постоянного давления. Работа на износ стала нормой. Симптомы были классическими: хроническая усталость, бессонница, нарастающая тревожность, частые головные боли, которые он списывал на стресс. Он откладывал визит к врачу, погруженный в поток задач. Раджеш шел по опасной дорожке к полному эмоциональному и физическому выгоранию (burnout) и, как позже выяснилось, к серьезным недиагностированным проблемам со здоровьем.

Тихий Наблюдатель: Вмешательство ИИ
Компания Раджеша внедрила пилотную программу "Employee Wellness Guardian" на основе ИИ. Система не была "Большим Братом", а работала с анонимизированными и агрегированными данными с соблюдением строгих правил конфиденциальности (GDPR и аналогичных), с явного согласия сотрудников. Вот как она функционировала:

  1. Сбор Данных (С согласия):

    • Носимые устройства (Fitbit/Apple Watch): Отслеживание пульса (включая вариабельность – HRV), качества сна, уровня активности.

    • Рабочие метрики (Анонимизированные): Анализ паттернов активности (время входа/выхода из системы, интенсивность использования клавиатуры/мыши – как индикатор фокуса, но без записи контента), частота переработок, использование календаря (количество встреч).

    • Добровольные опросы: Короткие анонимные чекапы о настроении и самочувствии.

  2. Анализ и Предикция:

    • Алгоритмы машинного обучения (ансамбли деревьев решений, нейронные сети) искали отклонения от индивидуальной нормы и комбинации факторов риска, связанных с тяжелым стрессом и выгоранием.

    • Модель была обучена на исторических (анонимных) данных о сотрудниках, у которых позже диагностировали burnout или связанные состояния, выявляя ранние, едва заметные сигналы.

Тревожный Сигнал: За Гранью Обычного Стресса
Система "Guardian" заметила у Раджеша тревожную комбинацию:

  • Резко возросшая и устойчиво высокая вариабельность сердечного ритма (низкий HRV) – ключевой маркер хронического стресса и напряжения нервной системы.

  • Катастрофическое ухудшение паттернов сна: Фрагментированный сон, почти полное отсутствие глубоких фаз, очень поздние отходы ко сну.

  • Паттерны работы: Постоянные работы глубоко за полночь, отсутствие значимых перерывов, снижение "продуктивных" периодов активности в течение дня (указывает на усталость и потерю концентрации).

  • Аномалии в данных опросов: Стойко низкие показатели самочувствия и энергии (даже при попытках "приукрасить").

  • Сравнение с индивидуальной базой: Эти показатели сильно отклонялись от его собственных исторических данных, что было важнее, чем сравнение с коллегами.

Вмешательство: Тактичное Спасение
Алгоритм присвоил Раджешу максимальный уровень риска тяжелых последствий для здоровья. Система не просто отправила уведомление HR. Она активировала протокол "Urgent Wellness Intervention":

  1. Экстренное оповещение: Личному врачу компании (на основании конфиденциального согласия Раджеша) и специально обученному консультанту по психическому здоровью были отправлены анонимные, но тревожные агрегированные данные с пометкой "Высокий риск, требуется немедленный контакт".

  2. Человеческий Контакт: Врач компании немедленно связался с Раджешем, выразив серьезную озабоченность на основании "обезличенных данных системы Wellness Guardian" и настоятельно рекомендовал срочное комплексное медицинское обследование вне офиса.

  3. Поддержка: Консультант предложил немедленную поддержку и организовал временное освобождение от рабочих задач.

Шокирующее Открытие:
Послушав врачей (и испытывая облегчение от того, что его "тихое страдание" наконец замечено), Раджеш прошел обследование. Результаты были шокирующими: помимо тяжелейшего профессионального выгорания, у него была диагностирована серьезная, ранее не выявленная сердечная аритмия, напрямую усугубляемая хроническим стрессом и недосыпом. Состояние было настолько серьезным, что врач предупредил о высоком риске инфаркта в ближайшие месяцы, если бы образ жизни не изменился радикально и немедленно.

Вывод: ИИ как Партнер в Заботе о Человеке
История Раджеша – мощный аргумент в пользу этичного и продуманного использования ИИ для благополучия сотрудников:

  1. Раннее Предупреждение: ИИ способен выявлять тонкие, комплексные паттерны, которые ускользают от человеческого внимания или маскируются "привычкой к стрессу". Модель достигла F1-score >0.92 в предсказании тяжелых случаев выгорания за 4-6 недель до критической точки.

  2. Проактивная Забота: Переход от реагирования на кризисы к их предотвращению. Система действовала до того, как Раджеш полностью сломался или случилась медицинская катастрофа.

  3. Конфиденциальность и Доверие: Ключ успеха – прозрачность, добровольное участие и акцент на анонимность агрегированных данных. ИИ был инструментом, а не надсмотрщиком.

  4. Спасение Конкретной Жизни: В данном случае ИИ не просто повысил эффективность – он дал Раджешу шанс на восстановление здоровья, возможно, предотвратив трагедию для него и его семьи.

Заключение:
История "несчастного индийского айтишника", спасенного ИИ, – не анекдот и не утопия. Это пример ответственного технологического гуманизма. Она демонстрирует, что ИИ может быть не только двигателем прибыли, но и настоящим "ангелом-хранителем" на рабочем месте. Задача компаний – внедрять такие системы с максимальным уважением к приватности, этике и с фокусом на реальную помощь человеку. Возможно, будущее корпоративной культуры лежит именно здесь: где алгоритмы, анализируя данные, помогают нам сохранить самое важное – человеческое здоровье и достоинство. Спасение Раджеша – это не просто happy end, это blueprint для будущего HR-Tech.

Итересно, они не справились с оптимизацией или побоялись, что облегчённые версии виндовс народ научится ставить на ПК.

Скорее не ломание под тесты, а осознание, что где-то переусложнил класс. Просто иногда это ко мне приходило именно на этапе написания юнит тестов. Но, конечно, каждый случай индивидуален.

Хороший рефакторинг меняет в том числе и контракты, от чего юнит-тесты и сыпятся как доминошки, ибо фиксируют не только внешние контракты, но и внутренние.

Опять же если для того, чтобы изменить внутренний контракт Вам необходимо переписать полприложения, то, конечно, юнит тесты основательно посыпятся. Но если вы поправили приложение в одном месте, то посыпятся только тесты, которые отвечают за это самое место. Например, для меня то, что затрагивается большое число тестов это индикатор того, что я неправильно разработал архитектуру приложения и подрефакторив его, можно упросить.

Это да, но при этом результаты работы заметно лучше если добавить немного креатива) Хотя в разных случаях температура нужна разная и лучше подбирать её индивидуально к каждому кейсу.

Например, какое-нибудь переполнение, которое возникает не сразу. Но это я так, к примеру.

Это могут быть и синие экраны в винде по всему миру)

А для тех, кто считает, что это ок, что проект неподдерживаемый, что его можно каждый раз перегенеривать и валидировать автотестами, то представьте ситуацию, что у вас есть крупный маркетплейс и у вас сломалась кнопка заказа. Вы просите ИИ перегенерить код с фиксом ишью, но ИИ выполняет перегенерацию сутки или больше, потому что хорошие автотесты работают долго и хороший ИИ раотает медленно. Для компании миллиардные убытки потому что пользователи закажут то же самое в другом месте, где ещё не внедрили вайбкодинг и на вызовы реагируют профессионалы и фиксят прод быстро.

Тут момент такой. Есть язык C, есть ассемблер. И мы можем каждую команду на C заменить на заранее определённую последовательность команд на ассемблере. То есть, к примеру, нам нужно напечатать число и на ассемблере это бы выглядело как делить число на 10, заменять числа на коды из таблицы с кодировками и так далее. То есть полотно текста, всегда одно и то же, при этом оно плохо читаемо потому что нужно понимать с каким регистром через какое прерывание работает каждая команда. Но благодаря современным языкам и компиляторам мы пишем понятный код и запуская его много раз мы можем получить один и тот же результат. Мы можем сделать свой проект и выложить его на гитхаб и позволить разным вендорам собирать их у себя со своими ключами и предоставлять пользователям какие-то гарантии, что это будет работать.

Теперь как это может выглядеть с ИИ. Я навайбкодил свой проект, выложил свой "вайбкод" на гитхаб, вендоры не знают как его собрать потому что ИИ каждый раз разный результат генерирует. Если я выкладываю в виде исходников, которые ИИ выплюнула из моего "вайбкода", то получится полотно кода, которое человек никогда не прочитает, он не сможет внести изменения. И если ключевой контрибьютор откажется от проекта, он просто умрёт, его нельзя форкнуть. И в суровом энтерпрайзе будет абсолютно так же: если хранить базу промтов, по которым собирался проект - каждый раз будет получаться разный непредсказуемый результат. Хранить код - он будет неподдерживаемым.

Но при этом сама модель qwen находится здесь и у неё лицензия apache 2.0:

https://huggingface.co/Qwen/Qwen3-30B-A3B

Запускать можно с помощью ollama. У неё лицензия MIT:

https://github.com/ollama/ollama

Все эти лицензии допускают коммерческое использование.

Тут наверное больше всех GNU под удар и подходит. Условный винамп может засветить исходники в публичном доступе и на претензию, мол они украли алгоритм кодирования звука, который защищен лицензией GNU сказать, мол нейросетка написала и т. д. А корпорации тем временем могут разрабатывать свои кодеки, патентовать их первыми и брать мзду со всех, кто использует похожие алгоритмы у себя.

Ну во-первых не обязательно использовать онлайн тулы. Тот же qwen достаточно хорошо генерит ответы и есть версии на не сильно требовательное железо.

Во-вторых вот Вы начинаете добавлять какой-то фреймворк без AI. Обычно Вы ведь не читаете исходники, чтобы изучить фреймворк и не пытаетесь изобрести велосипед, а просто копируете кусок кода из документации и адаптируете его под Ваши нужды. Опять же при спользовании фреймворков есть Best Practices и Вы тоже действуете в их рамках. И здесь тоже может быть копирование кода из документации и т. д. но я не думаю, что условный Spring Framework Вас вызовет в суд, если Вы из их документации что-то скопируете.

Ну и наконец AI тоже ведь можно использовать, но у всех свои функциональные и нефункциональные требования и код всё равно почти всегда требует адаптации, т. е. он используется в непрямом виде. А если Вы используете онлайн тулы, которым скармливаете тонкости бизнеса клиента, то у Вас проблемы куда большие, чем иск в суд за то, что вы скопировали себе в проект ИИ сортировку пузырьком.

Возможно, рекомендуемые для карбона. Я просто отчетливо помню на коробке 768 мб. Тогда был удивился, что требования по памяти обычно различаются в 2 раза. Там 128, 256, 512, гигабайт, но никак не 768.

Information

Rating
3,584-th
Registered
Activity