libva-vdpau-driver - хорошая штука, наверное, но с гибридной графикой (PRIME render offloading на nvidia) не завелось, да и зачем оно - встроенной видеокарты для 4к вполне хватает. К тому же, потребовалось бы целиком браузер на дискретной видеокарте запускать - у меня firefox с prime-run дружить не хочет, фаллбечится на софтварный рендеринг. В общем, с "всё будет работать сразу" пока не получается)
если youtube-dl натравить на это 4К и результат закинуть в медиаплеер
Тут действительно вопросов нет - mpv/vlc все это умеют, проблемы в основном с браузерами (и приложениями на электроне/qt-webengine - а таких сейчас много).
Буквально этой зимой пересобирал ядро с патчем для подаренной вебкамеры, пока в середине весны не вышло ядро, куда этот патч включили. На не-rolling-release дистрибутиве пришлось бы ждать подольше. Но это так, к слову, других проблем с драйверами у меня не было.
всё будет работать сразу
Хардварный декодинг/энкодинг видео/webrtc в браузере? Дробные коэффициенты масштабирования? Разные коэффициенты масштабирования на разных мониторах? Автоматический оффлоадинг приложений на дискретную видеокарту? Выключение питания дискретной видеокарты, если она не используется? Дополнительный уровень сложности - все вышеперечисленное с проприетарным nvidia-драйвером.
Что-то из этого будет работать на Wayland (но там появятся другие проблемы), что-то не на всех устройствах, что-то - вообще нигде не заработает, что-то заработает на 50% в программе X, и на другие 50% - в программе Y.
зачем вообще нужно преподавание программирования в обычной среднестатистической школе
Меня когда-то впечатлил вот этот ted talk - https://www.youtube.com/watch?v=60OVlfAUPJg (транскрипт - https://ted2srt.org/talks/conrad_wolfram_teaching_kids_real_math_with_computers), tldw: если изначально интегрировать компьютер в процесс обучения (в данном случае - в процесс обучения математики), то можно достичь намного более интересных результатов, чем сейчас. Действительно, подружить школьников с wolfram/matlab/etc, а не заставлять 11 лет учить, как решать очередной вид уравнений на бумаге - мне кажется намного полезнее с практической точки зрения. Наверное (экстаполирую), практическую часть любого другого STEM-предмета можно преподавать не как "читаем учебник, решаем задачки в тетрадке", а как "читаем учебник, пишем программы, которые что-то считают, моделируют или визуализируют". В таком процессе обучения, программирование (в каком-то виде), понадобится изучать весьма рано, и программировать нужно будет много и часто. Но от воплощения в реальность все эти мечты, конечно, довольно далеки.
Wayland по стеку, запихнут как слой между XServer и драйвером.
Здесь, вероятно, речь идет об XWayland. Wayland-композитор не требует существования X11-сервера.
NVidia собственные проприетарные драйвер и X сервер
X-сервер у Nvidia-драйверов вроде бы не свой — у меня в системе xorg-server один и тот же, что для nvidia, что для intel-графики.
Проблема проприетарных драйверов Nvidia в том, что у них свой API для манипуляции графическими буферами — EGLStreams, хотя все остальные драйвера используют GBM. Mutter (композитор Gnome), строго говоря, один из немногих wayland-композиторов, способных использовать как GBM, так и EGLStreams. Часть этой проблемы — даже если ваш wayland-композитор умеет работать с EGLStreams, xwayland не умел работать с EGLStreams, поэтому все x11-приложения на wayland работали без хардварного ускорения. К счастью, поддержку драйверов Nvidia для xwayland совсем недавно замерджили (https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/587), и к следующему релизу xwayland этим уже можно будет пользоваться на драйверах nvidia версии 470+.
Шаринг экрана в wayland — это общаяя проблема wayland протокола и wayland-композиторов (например, в Gnome используется Mutter, в KDE — kwin и так далее). Используя wayland, приложение не получает доступа ко всей возможной графической информации, как в случае X11. Единой спецификации о том, как wayland-композитору предоставлять доступ к экрану, долгое время не было. У Gnome, например, есть их собственное API для этого — поэтому Zoom не поддерживает screensharing на Wayland нигде, кроме Gnome. К счастью, сейчас все более-менее согласились (по крайней мере, для WebRTC) на использовании API xdg-desktop-portal и pipewire. Чтобы заработало, нужно установить pipewire и реализацию xdg-desktop-portal для вашего композитора (xdg-desktop-portal-gtk для gnome, xdg-desktop-portal-kde — для KDE, xdg-desktop-portal-wlr — для wlroots-based комопзиторов, наподобие sway и wayfire). Этого должно быть достаточно, чтобы screensharing на Wayland заработал в браузерах (в Firefox из коробки, в chromium нужно включить флаг chrome://flags/#enable-webrtc-pipewire-capturer). Теоретически, всем десктопным приложениям, написанным на электроне (Discord, Skype, Slack), этого тоже должно быть достаточно, но может так оказаться, что конкретное электрон-приложение собрано без поддержки pipewire.
Ну, если уж считаем млоки, то у NetBeans IDE на openhub 66 миллионов строк на джаве, у CXF — 40 миллионов, maven 3 — 17 миллионов…
А так, из больших проектов, вспомним еще Elasticsearch, GraalVM, openHAB, eclipse IDE (и производные), Apache Flink, Hive, Spring, Gradle, Bazel… В общем, по-моему, недостатка крупных проектов на джаве не наблюдается.
Мной иногда движет технический прогресс. Человечество придумало совершенно прекрасные алгоритмы сжатия, которые работают быстрее (скорость архивации/разархивации) и эффективнее (сжимается лучше) чем deflate (который внутри zip) — надо же как-нибудь стимулировать людей на них переходить. Поэтому мои достаточно технически подкованные друзья периодически получают от меня архивы в .zstd)
Браузеры действительно запоминают данные, которые вы в некоторые инпуты вводите, но я не помню случаев, когда исключительно браузерными средствами заполнялись формы при обновлении страницы (за исключением логинов-паролей). Заполнить данные в инпутах на основе данных из БД в сгенерированном на сервере HTML — да, так делали (и делают), но это же не браузерный мезанизм.
А всего-то нужно было заполнять их обратно при отмене перехода.
Я не уверен, что это "всего-то", учитывая, что поведение сайта при нажатии кнопки "назад" на SPA полностью настраивается фротнедером. Автозаполнение форм при назад-вперед нужно именно с них спрашивать.
Я немного читал по теме — теоретически, Flink должен быть намного более производительным. Spark работает либо в режиме микробатчинга, где он медленный (большая latency), либо микробатчинг можно отключить — тогда потеряются всякие полезные свойства по гарантии доставки сообщений, какие-то методы API будут недоступны. На практике мне их не доводилось сравнивать.
В х86 игры на macOS можно спокойно играть на M1 и даже лучше чем в нативе.
Хорошо, что у маководов с этим легче, чем у Linux c WINE/Proton.
Как я понимаю, это разные вещи. Речь идет о том, чтобы на MacOS ARM запустить приложение под MacOS x86-64. Wine/Proton — это чтобы запустить на Linux x86-64 приложение под Windows x86-64. Для запуска приложений под Linux ARM на Linux x86-64 красивых трансляторов вроде Rosetta нет (могу ошибаться), и обычно используют qemu.
А ведь это не первый и не второй курс, и многие из них уже трудоустроены по специальности и весьма успешны на своих работах. Что происходит?
Это очень знакомая ситуация. Вот несколько тезисов из своего опыта как студента известного столичного вуза (сейчас я на 6 курсе):
Большинство студентов не знают, что именно включает в себя выбранное направление обучения
План обучения, мягко говоря, не помогает студентам с самоопределением, и включает в себя в рамках одного семестра предметы, которые с малой вероятностью будут интересны одному и тому же студенту одновременно (что-нибудь вроде "нейронные сети", "цифровая схемотехника" и "корппоративные информационные системы")
После того, как студенты кое-как сориентировались и определились со своими интересами — 80% учебной программы начинает сдаваться по принципу минимально необходимого усилия
Представьте себе студента-айтишника четвертого курса, который по работе программирует микроконтроллеры, и в качестве выпускной работы разрабатывает хардварный кодек какого-нибудь AV1 на ПЛИС. Он прилежный студент — но в гробу он видел разбираться, что там лежит в SLN-файле. Ему этот предмет не очень интересен, а в учебной программе он есть — что ж, лабы он сделает (когда будет удобно), но никакого энтузиазма здесь не ожидайте.
"Назовите 5 преимуществ статической типизации над динамической"
"Перечислите преимущества многопоточных программ над однопоточными для выполнения CPU-bound задач"
"Как бы вы спланировали перевод пользователей на новую версию системы, несовместимую с предыдущей?"
...
лучшие умы, самые гениальные ученые и инженеры будут создавать идеальные архитектуры, совершенные алгоритмы и писать софт из тысяч строк кода, который будет работать на дорогом высокотехнологичном железе, десятках серверов с платами из редких металлов, машинах, связанный хитрой системой для быстрой обработки огромного количества данных, с нейронными сетями, которые держатся на сложнейшей математике, развитие которой эстафетой передавалось сквозь сотни лет, от поколения умнейших людей к другим умнейшим людям —
Чтобы на выходе эта система делала забавный фон на фотографии котиков.
libva-vdpau-driver - хорошая штука, наверное, но с гибридной графикой (PRIME render offloading на nvidia) не завелось, да и зачем оно - встроенной видеокарты для 4к вполне хватает. К тому же, потребовалось бы целиком браузер на дискретной видеокарте запускать - у меня firefox с prime-run дружить не хочет, фаллбечится на софтварный рендеринг. В общем, с "всё будет работать сразу" пока не получается)
Результат интересный, потому что проприетарный драйвер Nvidia для декодирования видео фаерфоксом не поддерживается(https://bugzilla.mozilla.org/show_bug.cgi?id=1210729, https://wiki.archlinux.org/title/Hardware_video_acceleration#Application_support). Уверены, что правильно замерили?
Работает - но кодирование видео там работает без хардварного ускорения (https://bugzilla.mozilla.org/show_bug.cgi?id=1658900)
Тут действительно вопросов нет - mpv/vlc все это умеют, проблемы в основном с браузерами (и приложениями на электроне/qt-webengine - а таких сейчас много).
Буквально этой зимой пересобирал ядро с патчем для подаренной вебкамеры, пока в середине весны не вышло ядро, куда этот патч включили. На не-rolling-release дистрибутиве пришлось бы ждать подольше. Но это так, к слову, других проблем с драйверами у меня не было.
Хардварный декодинг/энкодинг видео/webrtc в браузере? Дробные коэффициенты масштабирования? Разные коэффициенты масштабирования на разных мониторах? Автоматический оффлоадинг приложений на дискретную видеокарту? Выключение питания дискретной видеокарты, если она не используется? Дополнительный уровень сложности - все вышеперечисленное с проприетарным nvidia-драйвером.
Что-то из этого будет работать на Wayland (но там появятся другие проблемы), что-то не на всех устройствах, что-то - вообще нигде не заработает, что-то заработает на 50% в программе X, и на другие 50% - в программе Y.
Пробовали ставить игры из EGS (конечно, есть https://github.com/derrod/legendary, но тем не менее)? Про античиты и MMO уже писали.
В общем, до "все будет работать сразу" еще далековато, как мне кажется.
Меня когда-то впечатлил вот этот ted talk - https://www.youtube.com/watch?v=60OVlfAUPJg (транскрипт - https://ted2srt.org/talks/conrad_wolfram_teaching_kids_real_math_with_computers), tldw: если изначально интегрировать компьютер в процесс обучения (в данном случае - в процесс обучения математики), то можно достичь намного более интересных результатов, чем сейчас. Действительно, подружить школьников с wolfram/matlab/etc, а не заставлять 11 лет учить, как решать очередной вид уравнений на бумаге - мне кажется намного полезнее с практической точки зрения.
Наверное (экстаполирую), практическую часть любого другого STEM-предмета можно преподавать не как "читаем учебник, решаем задачки в тетрадке", а как "читаем учебник, пишем программы, которые что-то считают, моделируют или визуализируют". В таком процессе обучения, программирование (в каком-то виде), понадобится изучать весьма рано, и программировать нужно будет много и часто. Но от воплощения в реальность все эти мечты, конечно, довольно далеки.
По-моему, это не совсем так.
Здесь, вероятно, речь идет об XWayland. Wayland-композитор не требует существования X11-сервера.
X-сервер у Nvidia-драйверов вроде бы не свой — у меня в системе xorg-server один и тот же, что для nvidia, что для intel-графики.
Проблема проприетарных драйверов Nvidia в том, что у них свой API для манипуляции графическими буферами — EGLStreams, хотя все остальные драйвера используют GBM. Mutter (композитор Gnome), строго говоря, один из немногих wayland-композиторов, способных использовать как GBM, так и EGLStreams. Часть этой проблемы — даже если ваш wayland-композитор умеет работать с EGLStreams, xwayland не умел работать с EGLStreams, поэтому все x11-приложения на wayland работали без хардварного ускорения. К счастью, поддержку драйверов Nvidia для xwayland совсем недавно замерджили (https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/587), и к следующему релизу xwayland этим уже можно будет пользоваться на драйверах nvidia версии 470+.
del
Шаринг экрана в wayland — это общаяя проблема wayland протокола и wayland-композиторов (например, в Gnome используется Mutter, в KDE — kwin и так далее). Используя wayland, приложение не получает доступа ко всей возможной графической информации, как в случае X11. Единой спецификации о том, как wayland-композитору предоставлять доступ к экрану, долгое время не было. У Gnome, например, есть их собственное API для этого — поэтому Zoom не поддерживает screensharing на Wayland нигде, кроме Gnome. К счастью, сейчас все более-менее согласились (по крайней мере, для WebRTC) на использовании API xdg-desktop-portal и pipewire. Чтобы заработало, нужно установить pipewire и реализацию xdg-desktop-portal для вашего композитора (xdg-desktop-portal-gtk для gnome, xdg-desktop-portal-kde — для KDE, xdg-desktop-portal-wlr — для wlroots-based комопзиторов, наподобие sway и wayfire). Этого должно быть достаточно, чтобы screensharing на Wayland заработал в браузерах (в Firefox из коробки, в chromium нужно включить флаг chrome://flags/#enable-webrtc-pipewire-capturer). Теоретически, всем десктопным приложениям, написанным на электроне (Discord, Skype, Slack), этого тоже должно быть достаточно, но может так оказаться, что конкретное электрон-приложение собрано без поддержки pipewire.
Ну, если уж считаем млоки, то у NetBeans IDE на openhub 66 миллионов строк на джаве, у CXF — 40 миллионов, maven 3 — 17 миллионов…
А так, из больших проектов, вспомним еще Elasticsearch, GraalVM, openHAB, eclipse IDE (и производные), Apache Flink, Hive, Spring, Gradle, Bazel… В общем, по-моему, недостатка крупных проектов на джаве не наблюдается.
Кажется, у вас там в самом конце что-то с текстом случилось...
Мной иногда движет технический прогресс. Человечество придумало совершенно прекрасные алгоритмы сжатия, которые работают быстрее (скорость архивации/разархивации) и эффективнее (сжимается лучше) чем deflate (который внутри zip) — надо же как-нибудь стимулировать людей на них переходить. Поэтому мои достаточно технически подкованные друзья периодически получают от меня архивы в .zstd)
Браузеры действительно запоминают данные, которые вы в некоторые инпуты вводите, но я не помню случаев, когда исключительно браузерными средствами заполнялись формы при обновлении страницы (за исключением логинов-паролей). Заполнить данные в инпутах на основе данных из БД в сгенерированном на сервере HTML — да, так делали (и делают), но это же не браузерный мезанизм.
Я не уверен, что это "всего-то", учитывая, что поведение сайта при нажатии кнопки "назад" на SPA полностью настраивается фротнедером. Автозаполнение форм при назад-вперед нужно именно с них спрашивать.
Кажется, то, что вы описали — это в точности https://project-everest.github.io/.
Я немного читал по теме — теоретически, Flink должен быть намного более производительным. Spark работает либо в режиме микробатчинга, где он медленный (большая latency), либо микробатчинг можно отключить — тогда потеряются всякие полезные свойства по гарантии доставки сообщений, какие-то методы API будут недоступны. На практике мне их не доводилось сравнивать.
Как я понимаю, это разные вещи. Речь идет о том, чтобы на MacOS ARM запустить приложение под MacOS x86-64. Wine/Proton — это чтобы запустить на Linux x86-64 приложение под Windows x86-64. Для запуска приложений под Linux ARM на Linux x86-64 красивых трансляторов вроде Rosetta нет (могу ошибаться), и обычно используют qemu.
Это очень знакомая ситуация. Вот несколько тезисов из своего опыта как студента известного столичного вуза (сейчас я на 6 курсе):
Представьте себе студента-айтишника четвертого курса, который по работе программирует микроконтроллеры, и в качестве выпускной работы разрабатывает хардварный кодек какого-нибудь AV1 на ПЛИС. Он прилежный студент — но в гробу он видел разбираться, что там лежит в SLN-файле. Ему этот предмет не очень интересен, а в учебной программе он есть — что ж, лабы он сделает (когда будет удобно), но никакого энтузиазма здесь не ожидайте.
"Назовите 5 преимуществ статической типизации над динамической"
"Перечислите преимущества многопоточных программ над однопоточными для выполнения CPU-bound задач"
"Как бы вы спланировали перевод пользователей на новую версию системы, несовместимую с предыдущей?"
...
Довольно круто, что мы живем в то время, когда с полной серьезностью люди и корпорации обсуждают, какие будут законы в марсианских колониях)
Уже да (в найтли-версии). Вот инструкция — включается весьма неудобно, чтобы среднестатистический юзер себе чего-нибудь случайно не сломал.
Как говорится,