All streams
Search
Write a publication
Pull to refresh
16
1.6
Send message

Immich довольно проблемный.

Первый раз напоролся - обновилось приложение из Гугл плей - отвалилось от сервера (я был немного далеко от него) - научный опытом - обновил, отключил обновления в сторе.

Второй раз - поднимал версию, не прочитал ченжлоги всех предыдущих - а там breaking changes - иммих не поднялся, перечитал, поправил ок.

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

Короче immich - это пока ещё про пердолинг а не про замену google photo. Они об этом предупреждают, и в статье стоило бы написать об этом крупно и красным)

Годно. Когда последний раз что-то такое пробовал - были существенные проблемы с листаемыми списками (они реализовались в вёрстке как статические, и передавать их было чуть ли не сложнее), но тут может и прокатит

Прогуглил. Статистики нет, во всех статьях пишут - даблклик из за грязи (в целом логично - механическая клавиатура спроектирована таким образом чтобы точка отпускания была заметно выше точки нажатия). Короче не верится что это массовая проблема. Даблклик как раз удел мембранок - когда резинка изнашивается и начинается дребезг контактов, и то вроде в новых мембранках уже по лучше эта мембрана.

Если механика дешевая, то через некоторое время наиболее часто используемые клавиши типа "А" и "О" будут делать двойные нажатия 

Я конечно понимаю, что на одном человеке статистику не соберёшь - но у меня дешевая механика Уже 8 лет (она даже называется как-то смешно типо motospeed - китайский noname с али) - и я уже жду, когда же она сдохнет, а нет - никаких даблкликов нигде, живее всех живых. Так что у вас прямо хорошая статистика по проблеме есть? Может это у какой-то конкретной модели проблема была?

Не согласен. Клавиатуру специально для офиса я бы покупать не стал, а ту, что выдали, создавала после домашней механической ощущение, как будто пальцами по столу бьёшь, а не печатаешь. Отчасти это стало причиной смены работы в своё время)

Да, на не сертифицированных Гуглом устройствах проверки не будет

Заплатят за ключи разработчика и будут дальше без проблем публиковаться в русторе скорее всего.

А заодно - собрать денег с разрабов, публикующихся мимо гугл плей. А то чё это они Гуглу не платят за то, что не пользуются их магазином.

Чтобы привязать аккаунт - нужно зарегистрироваться за 25$. Взнос разработчика вроде 100 был

Он требует root жеж. На последних xiaomi или samsung например - рут не получить.

Один вопрос - за что эти 25$?

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

У нас получается парк устройств, которые потенциально скомпрометированы и слабо контролируются. Хотя я согласен, что идеально разделив доступы и настроив ограничения - можно получить очень хороший уровень безопасности. Из тех атак, методы проведения которых я видел - находим сотрудника с уязвимым софтом или головой, утягиваем у него доступы в впн, сканируем все ПК/устройства внутри сети, ищем уязвимые для повышения привелегий или проведения атаки с их помощью дальше, и так - пока не натворил делов.

Вот если у нас уязвимый сервер, защищённый впн, но все на него ходят - то первым шагом ломается сотрудник, вторым сервер, а третьим - сотрудники которые с ним взаимодействуют с высокими привелегиями.

P.s. я как бы поводу того, что это ВПН лучше - чем непонятная программа, особенно проприетарная - с вами тем не менее полностью согласен)

У меня товарищ совершенно технически не подкованный печатает модельки тысячами на фотополимернике - проблема с опорами решается (неожиданно) кнопкой - автоматически расставить опоры. Так что ваши разочарования преждевременны.

У меня самого fdm и чуть сложнее на нем печатать, но на самом деле если не покупать самый самый дешёвый пластик а в идеале брать pla - то даже кривая модель с огромными мостами и висящими в воздухе кусками - скорее всего напечатается приемлимо.

Пиксель арт намнооооого проще нарисовать приемлимо. По этому его выбирают чаще.

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

По сути - пиксель арт делат "автоматически" любой проект в одном стиле рисовки и одном уровне детализации объектов, если уж совсем не лажать.

А если немного вдаться в подробности? Запеченое 3д - это буквально взятие 3д модели, расположение под определённой камерой и последовательное снятие скриншотов. Потом проигрывание в качестве анимации. Что изменится, если мы повторим тот-же эффект в движке - берём анимацию модели, и вместо плавной, проигрываем её дискретно. Та же камера, те же кадры, разве что сжатие картинки не будет и возможно в старых играх разный уровень детализации/расстояния от камеры для разных моделей использовался и это будет сложнее на движке сделать.

Сравнение с капхед тут непонятно - рисование каждого кадра анимации руками даёт больше свободы для пластичности персонажей, чем любой морфинг, а вот какие плюсы в свободе даёт запекание относительно рендеринга? Или вы тоже кадры в ручную потом дообрабатываете?

Она до сих пор отлично подходит для определенных жанров. В первую очередь для мясных 3d шутеров). Что в doom, что в serios sam, что в вульфах или том-же painkiller - в среднем наваливание сюжета чаще делает хуже, чем лучше)

Думается мне, что тогда Кармак говорил это своим разработчикам про игры своего же жанра, и был прав что тогда, что сейчас)

На таких объемах я бы свою треуголку на то, что код написанный llm будет работать не поставил. Чем больше код, тем выше вероятность что llm пойдет в разнос, и по результатам одного экскремента из статьи - можно только утверждать только что "возможно, что сгенерировать код с 0 в полном объеме будет проще, чем использовать готовое решение".

Но как будто это опять же и так очевидно.

Вы сравнивали решение задачи с нуля и использование готовой библиотеки с помощью llm и пришли к выводу что с нуля нейрона пишет лучше? - Это совершенно логично - обучающая выборка намного больше для ванильного кода.

Вы пришли к выводу что четко формализованные до разработки требования лучше, чем генерируемые в процессе разработки? - давно известная истинна - без четкого т.з. результат х.з.

или это просто сложно написанная статья об очевидных вещах?

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

Так-же когда то чтобы писать софт нужно было знать регистры процессора, потом уметь писать свои ОС, потом низкоуровневые языки и вручную управлять памятью, сейчас мы переходим со стадии - "программу не написать, не зная языка" на стадию "программу не написать, не зная принципов программирования".

В среднем - для нормального функционирования как будто достаточно знать последний слой хорошо и предпоследний средне.

Конечно человек знающий всю иерархию всегда будет ценнее, но в исключительных ситуациях. В среднем - те, кто ищет водителя, не не заплатят больше за навыки автомеханика у него.

1
23 ...

Information

Rating
1,451-st
Registered
Activity