Pull to refresh
1
0.3
Alexander Grafov @siberianlaika

Software engineer

Send message

ZX Spectrum сотоварищи с клонами, ностальгично же!

В начале 2000-х довелось поработать в коммерческой конторе, которая присосалась к РЖД и внедряла в Москве и регионах небезызвестную SAP R/3 (это та немецкая чудо-система, где расценки на каждый чих по цене самолета, во всяком случае в те времена так было). Насмотрелся на коррупцию, как руководство не палясь хвалилось, как они "занесли" очередному чиновнику, чтобы подписать акты. И с админами тогдашней РЖД довелось взаимодействовать. Хорошие добрые люди, с низкими зарплатами и квалификацией на уровне этих зарплат. Времена сменились и конторы той больше нет, а в РЖД выглядит так, что мало что изменилось. Сейчас 2024 и Чаркин на той же должности.

Реклама спама на хабре??? :( Я бы сравнил спам с компьютерными вирусами. И то и другое бесполезно для пользователя, при этом требует регулярных ресурсов компьютера на проверку и удаление.

Однако, я понял, зачем нужна высокая хаброкарма, чтобы иметь возможность минусовать подобные статьи! Поставьте плиз и за меня минус этому парню :)

Действительно в декодере, невнимательно прочел, спасибо за уточнение. Да, такая схема сужает область применения.

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

Имхо, другое критично. Алгоритм патентованый, с применением в свободном ПО могут возникнуть проблемы. А если еще и исходники будут закрыты, то точно нафиг.

У меня все видео в firefox также не отобразились, а в chromium работают. Всё относительно :\

Судя по скрину с сайтом hothardware.com как минимум CSS поддерживается.

Как пользователь Linux со стажем > 25 лет отмечу, что на мой взгляд большинство возникающих проблем на десктопе -- это проблемы конкретных приложений, а не десктопного окружения или тем более ядра. Число функций и сложность приложений растут, на стабильности это не сказывается положительно. Что-нибудь где-нибудь да тормозит или задвисает. Наблюдая за пользователями других ОС, мой личный вывод, что это общий тренд, применимый ко всем трем наиболее известным системам: MacOS или Windows или Linux -- плюс-минус одинаковы. Все они отлично себя ведут, когда инсталляция минимальна и установки дефолтные. Добавляем прикладного софта и баги вылезают в совершенно неожиданных местах. Да вон даже старый добрый GNU/Emacs, который историей старше Linux, умудряется порой выжрать кучу CPU и памяти с некоторыми комбинациями плагинов -- вопрос к плагинам, так как в дефолтном виде Emacs образец стабильности.

Возможно, конкретно в моём случае минимум проблем окружения связан с минималистичным десктопом, я некоторое время назад пришел к применению тайловых WM, они с одной стороны сильно "беднее" по возможностям и требуют много больше предварительной настройки под себя, но их внутреннее устройство сильно проще, банально меньше кода и это очень снижает число ошибок, которые тащат за собой десктопные монстры кода, вроде Gnome или KDE.

Ещё проблема Linux десктопа в самой реализации графической системы. Есть старая система X Window, на которой в виде Xorg столетиями с прошлого века работают графические приложения, таща за собой легаси проблемы с рефрешем, шрифтами и пр. Есть развитие в виде Wayland, но ввиду большого числа окружений, приложений и дистрибутивов эта инициатива продвигается очень медленно и поддержка Wayland до сих пор остается неполной. Мне пришлось по итогу съехать с Wayland (с WM River) обратно на Xorg/i3, поскольку шаринг экрана обеспечить для всего используемого стека так и не удалось. То есть, сам Wayland или расширения к нему необходимые API предлагают, но есть куча софта, которых на них еще не перешел, или как ряд проприетарных приложений вовсе игнорируют эту тему, поскольку поддержка Linux в них явно для галочки (как пример MS Teams или Zoom).

Gigachat от Сбера не отстаёт от тренда!

29 февраля 2024 года. Это корректная дата?
Нет, 29 февраля 2024 года не является корректной датой, так как 2024 год не является високосным. Високосный год - это год, который имеет 366 дней, а не 365, как обычный год.
...
Таким образом, в 2024 году 29 февраля не существует. Последний високосный год был в 2020 году, а следующий будет в 2024 году.

Каждый раз как захожу на sourceforge.net удивляюсь, оно ещё живое? По привычке ожидаю увидеть там архив забытого дцать лет назад проекта, а тут что-то с датами за текущий год.

Хм, у меня кроме отдававшего сегодня 504 хабра (и то недолго), всё стабильно и быстро. Поразвели всяких интернетов, у кого работает, у кого не работает.

Выглядит любопытной альтернативой C. Я для себя ещё zig рассматриваю, его разработка пораньше началась, выглядит постабильнее. Почему не взять оригинальный C и не выюживаться? :) Видимо избалованным современными тулчейнами разработчикам, как я, хочется больше комфорта в коде :) После ухода на Go перестал пользоваться C практически, но порой его легковесности не достаёт, не всегда требуется гошный рантайм с его горутинами и прочими изысками.

Похоже на ситуацию с Oracle и OpenOffice, в дистрибутивах Linux постепенно замененным на LibreOffice. Как впрочем и другими похожими кейсами, когда крупный бизнес загребает себе известный опенсорс проект. Окей, ждем замены в дистрибутивах на angie и freenginx. Надеюсь, какая-то совместимость останется и конфиги сильно менять не придется :)

Ребрендингом больше, ребрендингом меньше. По мне так и правда было слишком помпезно. Смотрится уместно у итальянских и швейцарских банков с историей > 300 лет, но не для новодела из XXI века :)

Просто любопытно, а сам Олег Тиньков имел какое-то отношение к этому дворянскому роду или просто заребрендил для себя давно ничейный логотип герб однофамильцев? :)

Любопытно, эту оптимизацию индексных переменных цикла, названную "проблемой" смогли решить без потери в производительности? По-моим наблюдениям разработчики легко принимали эту особенность поведения как данность, сделанную для оптимизации цикла и после первой ошибки (которую вероятно совершали хоть раз все, кто долго программирует на go :) больше на это не попадались.

Личные практические советы, по минимальной безопасности для игр применительно к Linux:

  1. Запуск всего относящегося к играм под отдельным пользователем (Steam и пр., библиотеки игр). Убедиться, что игровой пользователь ограничен в правах (никаких sudo, даже с паролем).

  2. Какой-нибудь файрвол приложений, я использую Apparmor. Под все появляющиеся игры под него утомишся профили генерить, но хотя бы закрыть доступ для Steam и wine к местам, которые им явно не нужны. Для приложений в рабочем аккаунте тоже Apparmor, траты ресурсов от него немного.

  3. Антивирус в системе, как ни странно, актуально в наши дни даже в Linux. Для себя использую один из отечественных коммерческих продуктов.

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

В идеале конечно просто следует разделять компы для работы и игр, но это не всегда удобно, двойная трата ресурсов.

Выглядит такой пылесборник очень непрактично кстати. При всём уважении ко вложенному в это времени неизвестного мастера :-)

Information

Rating
1,848-th
Location
Москва, Москва и Московская обл., Россия
Registered
Activity

Specialization

Software Developer, Backend Developer
Lead
Git
PostgreSQL
Docker
Linux
C
Golang
RabbitMQ
Redis