Quest 3 совершили прорыв по сравнению с Quest 2 в аспекте качества изображения в режиме Passthrough: оно стало цветным и чётким
Вы точно в руках Quest 3 держали или только видели запись с камер? На записи все красиво, но пользователь на деле видит пересвеченную зернистую картинку низкого разрешения и эффекты гравитационного линзирования от рук по краям. Ни о какой четкости там речи не идёт.
Лежит пока без дела красавец на полке, жду wifi платку. Кстати на Вики появился пункт про новый NIC (старый ещё не выпустили, а уже новый на подходе), но без подробностей.
Вся сложность git и других систем управления версиями обусловлена в первую очередь сложностью разрешения конфликтов. На данном этапе все ещё приходится это делать руками. Если б можно было это автоматизировать, то можно было бы с задачами работать на более высоком уровне абстракций, без погружения в код.
Хочу вот эту задачку в этот релиз - нажал кнопку и оно заработало. На практике же могут возникнуть нетривиальные конфликты. В ветку мог быть вмержен мастер, и этот мерж-коммит притащит с собой код, которого в задаче не должно было быть.
Поэтому имеем в арсенале помимо merge ещё и rebase, который, как я считаю, должен знать каждый разработчик.
Для успешного использования гита достаточно разобраться с commit, add/reset, push/pull, tag, checkout/branch, merge-base, merge и rebase + merge-tool Это покроет 99% потребностей любого разработчика. Это изучается за пару вечеров. (Изначально команд было меньше, но, подумав, я добавил ещё :-)
Все остальное в git либо добавляет комфорта при работе (например stash), либо используется очень специфичных случаях (например filer-branch).
Итого, что я хочу этим сказать. Да, git сложный. Но это лишь потому, что он решает сложную задачу. Да, у git крутая кривая обучения, нужно сразу много чего знать, что бы нормально им пользоваться. Я при первом своем знакомстве с ним клонировал репозиторий несколько раз заново, потому что "что-то нажал и оно сломалось". Однако этот пробел в знаниях заполняется за короткое время. У git хорошая документация, но она абсолютно бесполезна для новичка, опять же из-за кривой обучения. Pro Git тут очень помогает.
Музыкант может загружать свои песни в Интернет - но не знать ничего про HTTP
Да, но. git это не средство хранения, а средство разработки. Он позволяет собрать из нескольких работ разных авторов цельный продукт (код). При этом разные версии продукта будут иметь разный функционал. В хотфикс например пойдут только критичные баги, в новый релиз пойдут и баги из хотфикса и новые фичи. Вы когда делаете push, то вам тоже не нужно ничего знать про http.
На примере музыканта: ему потребуется как минимум знание программы для сведения разных партий. Просто обычно этим в музыкальной индустрии занимается отдельный человек.
Вывозит без проблем. Исходники Линукс это маленький репозиторий в масштабах монорепы. Всего несколько гигабайт. Монорепы Гугла и MS занимают сотни гигабайт. Вот там уже проблемы были.
Из которых 300 страниц это "как поднять свой git-хостинг" и 100 страниц картинок.
пользоваться им в объеме 10-минутного quick-start guide
Ну большинство так и пользуются гитом, умея только нажимать готовые кнопки commit/push/pull в ide. Однако можно сильно упростить себе жизнь, если познакомиться с git поближе.
> Вы верно подметили - даже огромный по меркам конца 90-ых готов проект ядра ОС Линукс вполне жил на patch
Авторы формируют через git format-patch патчи, отсылают их по почте в список рассылки, комиттеры же из почты их забирают. Так до сих пор ведется разработка и Linux и самого git.
Этому подвержена любая операционная система, у которой файловая система доступна на запись. Ведь я своими кривыми ручонками могу делать в ней что угодно.
Вопрос лишь в том, может ли пакетный менеджер вас защитить от этого.
Очевидно это ошибка в buildroot или в вашей конфигурации, но не системная проблема. Я ж тоже могу любой бинарик слинковать с одной версией библиотеки, а в LD_PATH другую положить.
Ещё есть такие же свичи, но с PoE
Конечно у вас чёткое изображение, на таком то расстоянии. Но как часто вы разглядываете предметы в упор?
Вы точно в руках Quest 3 держали или только видели запись с камер? На записи все красиво, но пользователь на деле видит пересвеченную зернистую картинку низкого разрешения и эффекты гравитационного линзирования от рук по краям. Ни о какой четкости там речи не идёт.
Гавайи это военная база, на которую наведены пару боеголовок. Не лучший выбор для бункера.
Фанатам OpenWRT. Фанаты делают плату для фанатов. Домохозяйки их не интересуют.
Лежит пока без дела красавец на полке, жду wifi платку. Кстати на Вики появился пункт про новый NIC (старый ещё не выпустили, а уже новый на подходе), но без подробностей.
Как тогда возникает ситуация, что где-то на трассе ловит Мегафон, но не ловит МТС, а через 10 километров наоборот?
Раньше при использовании сети другого оператора ты находился в роуминге с соответствующими тарифами.
Диапазоны частот принадлежат государству, а сотовые операторы имеют лицензию на их использование.
Если это не компиляция чужих статей, включая GPT, то мой почтение.
А я не жалуюсь, я наоборот оправдываю.
Вся сложность git и других систем управления версиями обусловлена в первую очередь сложностью разрешения конфликтов.
На данном этапе все ещё приходится это делать руками. Если б можно было это автоматизировать, то можно было бы с задачами работать на более высоком уровне абстракций, без погружения в код.
Хочу вот эту задачку в этот релиз - нажал кнопку и оно заработало.
На практике же могут возникнуть нетривиальные конфликты. В ветку мог быть вмержен мастер, и этот мерж-коммит притащит с собой код, которого в задаче не должно было быть.
Поэтому имеем в арсенале помимо merge ещё и rebase, который, как я считаю, должен знать каждый разработчик.
Для успешного использования гита достаточно разобраться с commit, add/reset, push/pull, tag, checkout/branch, merge-base, merge и rebase + merge-tool Это покроет 99% потребностей любого разработчика.
Это изучается за пару вечеров. (Изначально команд было меньше, но, подумав, я добавил ещё :-)
Все остальное в git либо добавляет комфорта при работе (например stash), либо используется очень специфичных случаях (например filer-branch).
Итого, что я хочу этим сказать. Да, git сложный. Но это лишь потому, что он решает сложную задачу.
Да, у git крутая кривая обучения, нужно сразу много чего знать, что бы нормально им пользоваться. Я при первом своем знакомстве с ним клонировал репозиторий несколько раз заново, потому что "что-то нажал и оно сломалось".
Однако этот пробел в знаниях заполняется за короткое время.
У git хорошая документация, но она абсолютно бесполезна для новичка, опять же из-за кривой обучения. Pro Git тут очень помогает.
Да, но. git это не средство хранения, а средство разработки. Он позволяет собрать из нескольких работ разных авторов цельный продукт (код). При этом разные версии продукта будут иметь разный функционал. В хотфикс например пойдут только критичные баги, в новый релиз пойдут и баги из хотфикса и новые фичи. Вы когда делаете push, то вам тоже не нужно ничего знать про http.
На примере музыканта: ему потребуется как минимум знание программы для сведения разных партий. Просто обычно этим в музыкальной индустрии занимается отдельный человек.
Вывозит без проблем. Исходники Линукс это маленький репозиторий в масштабах монорепы. Всего несколько гигабайт.
Монорепы Гугла и MS занимают сотни гигабайт. Вот там уже проблемы были.
Почту используют просто по привычке.
Из которых 300 страниц это "как поднять свой git-хостинг" и 100 страниц картинок.
Ну большинство так и пользуются гитом, умея только нажимать готовые кнопки commit/push/pull в ide. Однако можно сильно упростить себе жизнь, если познакомиться с git поближе.
> Вы верно подметили - даже огромный по меркам конца 90-ых готов проект ядра ОС Линукс вполне жил на patch
Авторы формируют через git format-patch патчи, отсылают их по почте в список рассылки, комиттеры же из почты их забирают.
Так до сих пор ведется разработка и Linux и самого git.
Можете пояснить? Вы ведь сейчас про времена, когда не было никаких хостингов, а разработчики отсылали патчи через почту?
Git возник как инструмент для разработки Linux. И большая часть его возможностей вытекла из потребностей сообщества, а не корпораций.
Этому подвержена любая операционная система, у которой файловая система доступна на запись. Ведь я своими кривыми ручонками могу делать в ней что угодно.
Вопрос лишь в том, может ли пакетный менеджер вас защитить от этого.
Очевидно это ошибка в buildroot или в вашей конфигурации, но не системная проблема. Я ж тоже могу любой бинарик слинковать с одной версией библиотеки, а в LD_PATH другую положить.
source-based дистрибутивы не имеют таких проблем.
Вы описали слишком частный случай в области IT. Биолог бубонную чуму на дом тоже взять не может, как и сталевар доменную печь.
Большинству же нужен только компьютер и интернет.