Проблема комментариев, которые легко писать и поддерживать, в том, что они описывают что происходит, а не почему и зачем.
Что код/функция/модуль делает можно худо-бедно понять по самому коду. Куда важнее информация зачем вообще этот код нужен, почему код делает именно так, а не очевидно более простым образом и в каком направлении его можно менять, а в каком лучше не стоит -- пробовали, не получилось.
Но такие комментарии парой строк перед функцией уже не напишешь и такую информацию очень сложно поддерживать в процессе более-менее активной разработки.
Вот и получается, что описаний функций с аргументами полно, а логику и практики применения можно найти только в статье или вообще монографии опытного пользователя.
Соглашусь, утверждение было сформулировано слишком категорично.
Однако я имел в виду обычные, популярные протоколы доступа к удалённому рабочему столу, где не предполагается много видео. В таком случае старый добрый подход с как бы, типа, если один глаз закрыть, lossless передачей пожатых прямоугольников с изменившимися пикселями работает на удивление хорошо.
Хотя с современными кодеками, которые сами могут разбить кадр на произвольные области с индивидуальными параметрами сжатия, граница становится довольно размытой. Не удивлюсь, если к AV2 или H.266 проще и эффективнее будет тупо кодеком весь экран пожать с указанным битрейтом и не париться.
Вы вероятно плохо представляете, как сложен современный UI. Те "свистелки и переделки", которые навертели поверх того самого старого доброго X -- это уже неотъемлемая часть работы большинства приложений, от общей композиции рабочего стола до нормальных шрифтов и аппаратного ускорения.
Добрая часть UI уже давно не будет работать по сети в том виде, в котором это задумывалось в X изначально, часть вещей в принципе не может работать по сети и явно или косвенно опирается на предположение, что все локально. А худо-бедно прокидывается оно потому, что вместо высокоуровневых примитивов там передаются целые области изображения -- как в VNC (а не VPN, надеюсь вы просто опечатались), только криво.
В итоге "как задумано" оно работает только в примитивных сценариях, которые нельзя назвать общим решением. Либо оно работает так же, как и остальные протоколы, только ещё и X там ни к селу, ни к городу.
Во-первых, видео а-ля стриминг игр нигде и не перекачивается, ни в плохом качестве, ни в каком.
Во-вторых, если ни один из этих протоколов не работает если связь меньше мегабита, ну значит для этой задачи объективно надо мегабит.
X просто не подходит, даже если он по тоненькому каналу может работать. Если "не передавать контент вне оконных примитивов", ограничившись только чистым X, то это будет работать только с X, то есть в довольно ограниченном виде. Если вам хватает простецких окон терминала и блокнота с древними шрифтами -- прекрасно, остальному миру не хватило. Если же прокинуть через X десктоп с композицией, а в нем ещё и современный браузер, то там уже по сути VNC начинает ходить, то есть все те же копии картинок.
Ни один из распространенных на практике протоколов удаленного доступа к рабочему столу не использует модель X. И тем не менее, все прекрасно работает без "перекачивания видео по сети в плохом качестве" =).
Вариант с передачей по сети команд по работе с фиксированным набором относительно высокоуровневых примитивов пользовательского интерфейса (окна, контролы, текст и т. п.) просто не работает в общем виде. Современный десктоп намного сложнее в графическом плане.
Поэтому все просто используют передачу изменившихся областей экрана. При этом используется множество оптимизаций, например Microsoft RDP может посылать информацию о высокоуровневых примитивах если клиент сможет их точно воспроизвести, но это всё-таки оптимизации, а не фундаментальный принцип работы.
Зачем нужен Wayland это тема для отдельной огромной статьи. Возможно, проще будет погуглить и по диагонали пролистать тезисы.
Если очень кратко и очень грубо, то X это очень старый протокол, который разрабатывался едва ли не целиком вокруг идеи удаленной работы клиентов, во времена, когда ни о безопасности в нынешнем понимании, ни об аппаратном ускорении не задумывались.
За тридцать с лишним лет приоритеты и практики разработки поменялись. Прокидывать интерфейс по сети никому не нужно (не стоит путать с удаленным рабочим столом), при декодировании видео на YouTube нежелательно даже лишнее копирование (потому что это дополнительные милливатты драгоценной батареи ноутбука или телефона), а воровать пароли и вовсе некрасиво.
X11 латали костылями изо всех сил, но в какой-то момент надоело.
С X11 скорее всего случится то, что приложения просто лавинообразно перестанут его поддерживать.
Большинство и так написаны с использованием основных фреймворков типа Qt или GTK, они даже не заметят что что-то произошло. Другие разработчики будут вынуждены переписать/обновить, потому что приложения при работе через X начнут выглядеть плохо (дробное масштабирование нынче все более распространено), не будут поддерживать всякие модные жесты, не смогут взаимодействовать с остальными приложениями в системе, появятся проблемы с задействованием новых API аппаратного ускорения и прочие мелочи, которые будут продолжать копиться.
И тем не менее, основные дистрибутивы уже включают Wayland по умолчанию (плюс конечно XWayland на фоне).
С Wayland смешно уже конечно, ему 15 лет уже, ещё через 6 ему будет столько же, сколько было X11 когда начали разрабатывать Wayland, можно будет новый проект запускать. Мне самому кое-какие моменты в разработке Wayland не нравятся.
Но то, что X11 все это факт. В нем даже баги кроме безопасности не правят уже. В ближайшее время все фреймворки переползут на Wayland и все, пользователя даже спрашивать не будут.
К текущему моменту протокол и реализация суть едины. Единственная де-факто реализация огромна, сложна и полна десятилетий различных нюансов, на которые явно или косвенно опираются всевозможные приложения или фреймворки. Никто уже не будет писать альтернативную реализацию X, все давно махнули рукой и теперь только два варианта: текущий X11, уж какой есть, и Wayland, который все равно неизбежен.
Это у Samyang только автомат экспозиции? =) Да они делают автофокусные объективы уже лет десять, если не больше. Причем с качеством на уровне родных (я не шучу, несколько их объективов выйди под маркой Sony/Fuji, никто бы и не удивился). У них недавно автофокусный зум вышел, а это вам не фунт изюму.
Viltrox делает автофокусные уже пару лет и отзывы о них тоже очень хорошие.
Первый автофокусный объектив Laowa уже продается. Meike и Brighting Star недавно выпустили анонс, но до магазинов их объективы ещё вроде не доехали.
У многих моделей есть честное кольцо апертуры, переключатели с кликом или без, авто и ручной фокус, настраиваемые (в камере!) функциональные кнопки. Вы в каких-то непонятных временах застряли, если думаете, что сторонние производители в чем-то заметно уступают.
Вот чего сторонние производители не могут, это автофокус выше определенного количества кадров в секунду (например родной объектив может бурст до 30 кадров в секунду, а сторонний только 15) и поддержку телеконверторов. Sony такое запрещает и чтобы продавать, приходится искусственно ограничивать.
А ну и ещё до автофокуса на магнитном подвесе (как в последних моделях Sony G и GM) пока китайские производители не дошли, но это дело времени.
А ещё Samyang, Tokina, Viltrox, Meike, Laowa и Brightin Star. Объективы, работающие в автоматическом режиме, нынче делают все китайцы, кому хоть сколько-нибудь не лень.
Но только для тех байонетов, владельцы которых не против, как например Sony, Nikon и Fujifilm. Потому что объективы ещё продавать надо.
Так HBM это просто быстрее. Один черт и у Apple, и у Intel со встроенным GPU память физически одна на все. Но в случае Intel до сих пор по каким-то причинам GPU не может пользоваться той же областью памяти, что и пользовательское приложение. В итоге данные передаются какими-то крюками, в разы медленнее, чем то же самое но внутри приложения или внутри GPU. Хотя память физически одна.
Интересно, что мешает остальным производителям сделать так же? Имею опыт работы с аппаратным ускорением обработки видео на CPU Intel и копирование кадра из "обычной" памяти приложения в GPU и обратно это не очень быстро. Они же все равно в одних и тех же чипах на одних и тех же плашках памяти в итоге хранятся!
В QR кодах обычно закодирована какая-то ссылка, что делает их бесполезными без возможности открыть эту ссылку.
В QR коде может быть спрятан код ошибки или пароль, но это единичные и довольно странные сценарии, одно-два слова намного проще написать прямо так. QR код всё-таки обычно для того, чтобы нажал, ещё раз нажал и оно само. Без интернета это не работает.
Механика -- это только ради кастомизации? Довольно широкое обобщение.
Я купил механическую клавиатуру потому, что мембранных с такими же ощущениями от работы (длинный ход, тактильный отклик) просто не существует. Клавиатуру не кастомизировал и не собираюсь. Максимум, кейкап Escape поменяю на красненький, просто потому что могу.
Бонусом у механических клавиатур как правило идёт большая прочность. Можно будучи раздраженным давить на клавиши со всей дури и клавиатура даже не скрипнет.
Библиотека языка это совсем базовые кирпичики. Знание алгоритмов в данном случае подразумевает понимание какие кирпичики в каком порядке надо составить, чтобы построить надёжный фундамент для дальнейшей логики программы.
Проблема комментариев, которые легко писать и поддерживать, в том, что они описывают что происходит, а не почему и зачем.
Что код/функция/модуль делает можно худо-бедно понять по самому коду. Куда важнее информация зачем вообще этот код нужен, почему код делает именно так, а не очевидно более простым образом и в каком направлении его можно менять, а в каком лучше не стоит -- пробовали, не получилось.
Но такие комментарии парой строк перед функцией уже не напишешь и такую информацию очень сложно поддерживать в процессе более-менее активной разработки.
Вот и получается, что описаний функций с аргументами полно, а логику и практики применения можно найти только в статье или вообще монографии опытного пользователя.
Соглашусь, утверждение было сформулировано слишком категорично.
Однако я имел в виду обычные, популярные протоколы доступа к удалённому рабочему столу, где не предполагается много видео. В таком случае старый добрый подход с как бы, типа, если один глаз закрыть, lossless передачей пожатых прямоугольников с изменившимися пикселями работает на удивление хорошо.
Хотя с современными кодеками, которые сами могут разбить кадр на произвольные области с индивидуальными параметрами сжатия, граница становится довольно размытой. Не удивлюсь, если к AV2 или H.266 проще и эффективнее будет тупо кодеком весь экран пожать с указанным битрейтом и не париться.
Вы вероятно плохо представляете, как сложен современный UI. Те "свистелки и переделки", которые навертели поверх того самого старого доброго X -- это уже неотъемлемая часть работы большинства приложений, от общей композиции рабочего стола до нормальных шрифтов и аппаратного ускорения.
Добрая часть UI уже давно не будет работать по сети в том виде, в котором это задумывалось в X изначально, часть вещей в принципе не может работать по сети и явно или косвенно опирается на предположение, что все локально. А худо-бедно прокидывается оно потому, что вместо высокоуровневых примитивов там передаются целые области изображения -- как в VNC (а не VPN, надеюсь вы просто опечатались), только криво.
В итоге "как задумано" оно работает только в примитивных сценариях, которые нельзя назвать общим решением. Либо оно работает так же, как и остальные протоколы, только ещё и X там ни к селу, ни к городу.
Справедливости ради, касаемо окон и пр. WinAPI это будет аналог оконного фреймворка, например того же GTK.
Если бы Linux мог себе позволить иметь один единственный официальный фреймворк для GUI, было бы намного проще.
И какое это имеет отношение к вышесказанному?
Во-первых, видео а-ля стриминг игр нигде и не перекачивается, ни в плохом качестве, ни в каком.
Во-вторых, если ни один из этих протоколов не работает если связь меньше мегабита, ну значит для этой задачи объективно надо мегабит.
X просто не подходит, даже если он по тоненькому каналу может работать. Если "не передавать контент вне оконных примитивов", ограничившись только чистым X, то это будет работать только с X, то есть в довольно ограниченном виде. Если вам хватает простецких окон терминала и блокнота с древними шрифтами -- прекрасно, остальному миру не хватило. Если же прокинуть через X десктоп с композицией, а в нем ещё и современный браузер, то там уже по сути VNC начинает ходить, то есть все те же копии картинок.
Ни один из распространенных на практике протоколов удаленного доступа к рабочему столу не использует модель X. И тем не менее, все прекрасно работает без "перекачивания видео по сети в плохом качестве" =).
Вариант с передачей по сети команд по работе с фиксированным набором относительно высокоуровневых примитивов пользовательского интерфейса (окна, контролы, текст и т. п.) просто не работает в общем виде. Современный десктоп намного сложнее в графическом плане.
Поэтому все просто используют передачу изменившихся областей экрана. При этом используется множество оптимизаций, например Microsoft RDP может посылать информацию о высокоуровневых примитивах если клиент сможет их точно воспроизвести, но это всё-таки оптимизации, а не фундаментальный принцип работы.
Зачем нужен Wayland это тема для отдельной огромной статьи. Возможно, проще будет погуглить и по диагонали пролистать тезисы.
Если очень кратко и очень грубо, то X это очень старый протокол, который разрабатывался едва ли не целиком вокруг идеи удаленной работы клиентов, во времена, когда ни о безопасности в нынешнем понимании, ни об аппаратном ускорении не задумывались.
За тридцать с лишним лет приоритеты и практики разработки поменялись. Прокидывать интерфейс по сети никому не нужно (не стоит путать с удаленным рабочим столом), при декодировании видео на YouTube нежелательно даже лишнее копирование (потому что это дополнительные милливатты драгоценной батареи ноутбука или телефона), а воровать пароли и вовсе некрасиво.
X11 латали костылями изо всех сил, но в какой-то момент надоело.
С X11 скорее всего случится то, что приложения просто лавинообразно перестанут его поддерживать.
Большинство и так написаны с использованием основных фреймворков типа Qt или GTK, они даже не заметят что что-то произошло. Другие разработчики будут вынуждены переписать/обновить, потому что приложения при работе через X начнут выглядеть плохо (дробное масштабирование нынче все более распространено), не будут поддерживать всякие модные жесты, не смогут взаимодействовать с остальными приложениями в системе, появятся проблемы с задействованием новых API аппаратного ускорения и прочие мелочи, которые будут продолжать копиться.
И тем не менее, основные дистрибутивы уже включают Wayland по умолчанию (плюс конечно XWayland на фоне).
С Wayland смешно уже конечно, ему 15 лет уже, ещё через 6 ему будет столько же, сколько было X11 когда начали разрабатывать Wayland, можно будет новый проект запускать. Мне самому кое-какие моменты в разработке Wayland не нравятся.
Но то, что X11 все это факт. В нем даже баги кроме безопасности не правят уже. В ближайшее время все фреймворки переползут на Wayland и все, пользователя даже спрашивать не будут.
К текущему моменту протокол и реализация суть едины. Единственная де-факто реализация огромна, сложна и полна десятилетий различных нюансов, на которые явно или косвенно опираются всевозможные приложения или фреймворки. Никто уже не будет писать альтернативную реализацию X, все давно махнули рукой и теперь только два варианта: текущий X11, уж какой есть, и Wayland, который все равно неизбежен.
Это у Samyang только автомат экспозиции? =) Да они делают автофокусные объективы уже лет десять, если не больше. Причем с качеством на уровне родных (я не шучу, несколько их объективов выйди под маркой Sony/Fuji, никто бы и не удивился). У них недавно автофокусный зум вышел, а это вам не фунт изюму.
Viltrox делает автофокусные уже пару лет и отзывы о них тоже очень хорошие.
Первый автофокусный объектив Laowa уже продается. Meike и Brighting Star недавно выпустили анонс, но до магазинов их объективы ещё вроде не доехали.
У многих моделей есть честное кольцо апертуры, переключатели с кликом или без, авто и ручной фокус, настраиваемые (в камере!) функциональные кнопки. Вы в каких-то непонятных временах застряли, если думаете, что сторонние производители в чем-то заметно уступают.
Вот чего сторонние производители не могут, это автофокус выше определенного количества кадров в секунду (например родной объектив может бурст до 30 кадров в секунду, а сторонний только 15) и поддержку телеконверторов. Sony такое запрещает и чтобы продавать, приходится искусственно ограничивать.
А ну и ещё до автофокуса на магнитном подвесе (как в последних моделях Sony G и GM) пока китайские производители не дошли, но это дело времени.
А ещё Samyang, Tokina, Viltrox, Meike, Laowa и Brightin Star. Объективы, работающие в автоматическом режиме, нынче делают все китайцы, кому хоть сколько-нибудь не лень.
Но только для тех байонетов, владельцы которых не против, как например Sony, Nikon и Fujifilm. Потому что объективы ещё продавать надо.
Например, павильоне на Луне. Там и гравитация натуральная, удобно будет.
Так HBM это просто быстрее. Один черт и у Apple, и у Intel со встроенным GPU память физически одна на все. Но в случае Intel до сих пор по каким-то причинам GPU не может пользоваться той же областью памяти, что и пользовательское приложение. В итоге данные передаются какими-то крюками, в разы медленнее, чем то же самое но внутри приложения или внутри GPU. Хотя память физически одна.
Интересно, что мешает остальным производителям сделать так же? Имею опыт работы с аппаратным ускорением обработки видео на CPU Intel и копирование кадра из "обычной" памяти приложения в GPU и обратно это не очень быстро. Они же все равно в одних и тех же чипах на одних и тех же плашках памяти в итоге хранятся!
Надо ещё немного увеличить количество светодиодов, чтобы каждый пиксель подсвечивался своим светодиодом... так, падажжи...
В QR кодах обычно закодирована какая-то ссылка, что делает их бесполезными без возможности открыть эту ссылку.
В QR коде может быть спрятан код ошибки или пароль, но это единичные и довольно странные сценарии, одно-два слова намного проще написать прямо так. QR код всё-таки обычно для того, чтобы нажал, ещё раз нажал и оно само. Без интернета это не работает.
Механика -- это только ради кастомизации? Довольно широкое обобщение.
Я купил механическую клавиатуру потому, что мембранных с такими же ощущениями от работы (длинный ход, тактильный отклик) просто не существует. Клавиатуру не кастомизировал и не собираюсь. Максимум, кейкап Escape поменяю на красненький, просто потому что могу.
Бонусом у механических клавиатур как правило идёт большая прочность. Можно будучи раздраженным давить на клавиши со всей дури и клавиатура даже не скрипнет.
Библиотека языка это совсем базовые кирпичики. Знание алгоритмов в данном случае подразумевает понимание какие кирпичики в каком порядке надо составить, чтобы построить надёжный фундамент для дальнейшей логики программы.
А какие, желательно кроссплатформенные, альтернативы вы могли бы привести в пример?