К идее создания умного зеркалу подходил несколько раз, крутил, вертел. И Малина Пи есть (используется для другого), но... сколько раз подходил к этой задача задавал один и тот-же вопрос, точнее несколько:
Какую проблему я хочу решить?
Что мне это даст?
зачем зеркало будет потреблять энергию (в Германии это дорого)
...и каждый раз откладывал проект в сторону.
Вопрос всем, кто тут на эту тему вообще реагирует - а что такого у вас делает "умное зеркало", что полезного оно дает, кроме погоды, и еще пары-тройки похожих (по мне, не сильно важных) функций?
Буквально на днях разговаривал с хорошим другом, у которого команда.
С переходом на ИИ их скорость выполнения проектов возросла в 10+ раз. И да, это помогает. И да, из-за ИИ они уже потеряли несколько контрактов, где клиенты, не имея опыта программирования, уже смогли решить ряд задач самостоятельно.
Самое забавное то, что большая часть ответа "самого виновника" это некая статистическая подборка уже того, что кто-то когда-то сказал... либо напрямую этим текстом, приведенном в ответе, либо в форме смыслового описания то, что собрано в ответе.
И да, возможно, в том, что описано, есть некая правда, но... вполне возможно, что части "ответа" - это всего-лишь "экстраполяция" будущих потенциальных возможностей тех, кто продает ИИ, или описывает будущие возможности ИИ системы.
Думаю, мы может разойтись при обсуждении, что понимать под капиталкой. Если замену поршней, колец считать капиталкой, то тогда да, не ходят. Но это, в любом случае, не замена всего двигателя, коробки целиком.
Да, соглашусь, современные японцы могут ходить 500+к - как минимум это то, что я вынес из разговора с таксистами и что увидел на спидометрах машин.
я не изучал особенности лицензирования qwen, на это не было времени и необходимости, сделал быстрый поиск и понял, что там тоже не все просто.
Что знаю (их прошлого), что MIT лицензия обязует вас использовать MIT если вы используете элементы кода с MIT лицензией, и там были особенности раскрытия кода.
Для какого-то небольшого приватного проекта MIT может быть ок, но для комерческого - это может быть палка о двух концах. Поэтому тут отдельная тема, которая только добавляет сложности в ситуацию.
я бы привел немного абстрактную аналогию, чтобы показать, что такой взгляд может быть и правильным и не очень одновременно.
Берем работу художника. Художник использует краски которые, чаще всего, можно купить в простом магазине, однако создаваемое им творение уникально и является его собственностью в плане копирайта (предполагаем это не копия какой-то другой работы).
В этой ситуации краски - это стандартный набора изначально доступных инструментов, превращается в уникальное творение защищенное авторским правом.
В программировании не редко работае аналогичный принцип. (не говоря про особенности патентирования алгоритмов и специфических решений)
Увы, не профанация. По роду деятельности мне довелось поработать на клиентов из многих индустрий. Разработка заведомо устаревающих продуктов - это не просто "миф", это то, что у некоторых производителей стоит как цель, задание поставленное инженерам. И тестирование не редко проводится с фокусом на то, чтобы ресурс запланированный на гарантийный срок удерживался, а потом устройство заведомо гарантированно ломалось. Это не вымысел, это то, что я лично слышал в разговорах с людьми в инженерных подразделениях. Увы, назвать компании не могу, но просто поверьте, там будет с десяток больших фирм, которые вы хорошо знаете.
Электроника, кстати, добавила в этот процесс некую новую норму на скорость устаревания.
По поводу устаревания автомобилей: простой вопрос: где вы сегодня можете увидеть машины (таких в 90е было много), которые проезжают миллион или более без капитального ремонта двигателя и коробки? Увы, в современном мире таких уже нет. Причина - умышленное изменение конструкции, замена материалов, которая делает такой ресурс недосягаемым. Тут мы говорим про легковые машины. В сегменте профессиональных грузовых перевозок миллион это вообще ничто.
Почему? Потому что раньше вы могли ездить на машине дедушки и радоваться жизнью. У моего соседа старый Мерс. Стоимость обслуживания близка к нулю. Да, он не сверкает всеми возможными лампочками, он не похоже на новогоднюю елку, но он надежно ездит - выполняет основную свою функцию. Сегодня этого класса машина это порядка 100к Евро каждые 4 года + значительные расходы на обслуживание. Если у вас много денег и вы можете это позволить - рад за вас, но среднестатистический житель даже Германии (где я и живу) такого себе позволить не может от слова "вообще".
Да у старых "Москвичей" ресурс был тоже не бог весь какой, но по тем временам 200к - это огромный ресурс, да и стоимость обслуживания у них был не в стоимость новой маленькой машины. Говорю, как когда-то владелец восьмерки (которой на момент продажи было 14 лет), и потом восьмерки (стоимость обслуживания даже тогда была смешной).
Спасибо за оценку, но, как говорят, есть нюанс: стоит отличать "право собственности" от "лежать". Это важное отличие как "получаете зарплату вы" (за ваш труд) или "ваш сосед".
Как когда-то было сказано: "Если на СЦЕНЕ висит ружьё, то в третьем акте оно должно выстрелить." Из письма Антона Павловича Чехова
Мы находимся только в начале пути. Правовое поле вокруг AI все еще только формируется, но то, что написано в данном конкретном лицензионном соглашении звучит достаточно тревожно.
Это лишь говорит, что пора начинать внимательно читать лицензионные соглашения, и информировать юристов вашего работодателя (даже если вы сам себе работодатель) о такого рода подводных камнях.
Хочу обратить ваше внимание на то, что есть важное отличие, когда вы что-то делаете сами, и используете какой либо тул, и когда вы используете тул, который что-то создает за вас.
Да, вы правы, в обеих случаях тул что-то генерит, даже компилятор генерит финальный код - в этом вы правы.
Есть одно маленькое но: что написано в лицензионном соглашении компилятора, которым вы пользуетесь? Вы читали? Там сказано, что сгенерированный код вам не принадлежит? Посмотрите, что написано в лицензионном соглашении и давайте вернемся к этой теме еще раз. Думаю, это будет и вам и мне интересно.
Вы упускаете один важный аспект: одно - когда вы пишите текст сами, и второе - когда текст пишет за вас система.
По поводу языка С - если вы произведете поиск, то увидите, что .... вот что выдает гугл сегодня:
No single entity "owns" the C programming language. It's a publicly available standard maintained by the ISO/IEC JTC1/SC22/WG14 working group.
Иными словами, это язык, который описан стандартом и как таковой не имеет владельца.
По поводу языка Rust ситуация немного другая, и вот что про это говорит гугл:
The Rust programming language is owned by the Rust Foundation. The foundation is a non-profit organization established by companies like Amazon Web Services, Google, Microsoft, and Mozilla.
Иными словами языком Rust владеет "без-прибыльная компания" (это лишь форма собственности, позволяющая не платить налоги), которой владеют 4 основных гиганта мировой IT промышленности.
Это важный нюанс. Если помните (нет, поищите, очень интересная история) истории с Java, как продукт, который был открытым и доступным всем забесплатно, был приобретен вместе с компанией Sun, и что было потом (возникшие лицензионные соглашения, споры и тому подобное).
Эта тема очень интересная, советую изучить. Игнорирование лицензионных вопросов не означает, что они вас не касаются ;-)
И, в качестве заключения, мне лично довелось наблюдать вдруг возникшие и очень дорогие проекты миграции связанные с резким изменением в лицензировании Java.
Да, на сегодняшний день тема дискриминации права пользователя встает все острее и острее. Полностью согласен.
То, что нужно читать соглашения - это тоже факт. Многие считают это не нужным, не интересным, некоторые этого сделать не могут, потому что тексты часто на английском.
бОльшая проблема появляется когда кто-то работает по контракту на какую-то фирму. Втянув чужой код или библиотеку, программист может (возможно не умышленно) создать сложную ситуацию для работодателя. Тема, которая заслуживает пристального внимания.
Если такое событие наступит, то сначала те, кто попал под претензию должны будут заплатить штрафы и неустойки. их размер, суммы могут быть для некоторых компаний убийственными.
Иными словами, компания до переписывания кода может недотянуть.
То что вы пишите для кого-то... этот кто-то может попасть под лицензионные риски. Поэтому, когда вы начинаете использовать новую библиотеку, которая вам понравилась, стоит прочитать лицензионное соглашение и поставить "кого-то" в известность. Риски не ваши, и вы работая по контракту или на зарплате косвенно отвечаете за увеличение или уменьшение рисков компании работодателя.
Для себя - тоже хороший вопрос. В какой-то момент у вас будет собственность, и, в случае какого либо судебного иска, вы несете ответственность и покрываете финансовые риски всем своим имуществом. Это стоит помнить.
К идее создания умного зеркалу подходил несколько раз, крутил, вертел.
И Малина Пи есть (используется для другого), но... сколько раз подходил к этой задача задавал один и тот-же вопрос, точнее несколько:
Какую проблему я хочу решить?
Что мне это даст?
зачем зеркало будет потреблять энергию (в Германии это дорого)
...и каждый раз откладывал проект в сторону.
Вопрос всем, кто тут на эту тему вообще реагирует - а что такого у вас делает "умное зеркало", что полезного оно дает, кроме погоды, и еще пары-тройки похожих (по мне, не сильно важных) функций?
я могу.
Буквально на днях разговаривал с хорошим другом, у которого команда.
С переходом на ИИ их скорость выполнения проектов возросла в 10+ раз. И да, это помогает. И да, из-за ИИ они уже потеряли несколько контрактов, где клиенты, не имея опыта программирования, уже смогли решить ряд задач самостоятельно.
И да, начальная тема была малость не об этом.
ответ на
Самое забавное то, что большая часть ответа "самого виновника" это некая статистическая подборка уже того, что кто-то когда-то сказал... либо напрямую этим текстом, приведенном в ответе, либо в форме смыслового описания то, что собрано в ответе.
И да, возможно, в том, что описано, есть некая правда, но... вполне возможно, что части "ответа" - это всего-лишь "экстраполяция" будущих потенциальных возможностей тех, кто продает ИИ, или описывает будущие возможности ИИ системы.
И да и нет. В какой-то степени ИИ помогает, но есть нюанс - он иногда врет, и не редко очень правдоподобно.
В юридическом деле это может стоит дорогого.
Думаю, мы может разойтись при обсуждении, что понимать под капиталкой. Если замену поршней, колец считать капиталкой, то тогда да, не ходят. Но это, в любом случае, не замена всего двигателя, коробки целиком.
Да, соглашусь, современные японцы могут ходить 500+к - как минимум это то, что я вынес из разговора с таксистами и что увидел на спидометрах машин.
Нет, не юрист, но с ними сейчас активно работаю.
я не изучал особенности лицензирования qwen, на это не было времени и необходимости, сделал быстрый поиск и понял, что там тоже не все просто.
Что знаю (их прошлого), что MIT лицензия обязует вас использовать MIT если вы используете элементы кода с MIT лицензией, и там были особенности раскрытия кода.
Для какого-то небольшого приватного проекта MIT может быть ок, но для комерческого - это может быть палка о двух концах. Поэтому тут отдельная тема, которая только добавляет сложности в ситуацию.
я бы привел немного абстрактную аналогию, чтобы показать, что такой взгляд может быть и правильным и не очень одновременно.
Берем работу художника. Художник использует краски которые, чаще всего, можно купить в простом магазине, однако создаваемое им творение уникально и является его собственностью в плане копирайта (предполагаем это не копия какой-то другой работы).
В этой ситуации краски - это стандартный набора изначально доступных инструментов, превращается в уникальное творение защищенное авторским правом.
В программировании не редко работае аналогичный принцип. (не говоря про особенности патентирования алгоритмов и специфических решений)
Спасибо за детальный разбор.
Увы, не профанация. По роду деятельности мне довелось поработать на клиентов из многих индустрий. Разработка заведомо устаревающих продуктов - это не просто "миф", это то, что у некоторых производителей стоит как цель, задание поставленное инженерам. И тестирование не редко проводится с фокусом на то, чтобы ресурс запланированный на гарантийный срок удерживался, а потом устройство заведомо гарантированно ломалось. Это не вымысел, это то, что я лично слышал в разговорах с людьми в инженерных подразделениях. Увы, назвать компании не могу, но просто поверьте, там будет с десяток больших фирм, которые вы хорошо знаете.
Электроника, кстати, добавила в этот процесс некую новую норму на скорость устаревания.
По поводу устаревания автомобилей: простой вопрос: где вы сегодня можете увидеть машины (таких в 90е было много), которые проезжают миллион или более без капитального ремонта двигателя и коробки? Увы, в современном мире таких уже нет. Причина - умышленное изменение конструкции, замена материалов, которая делает такой ресурс недосягаемым. Тут мы говорим про легковые машины. В сегменте профессиональных грузовых перевозок миллион это вообще ничто.
Почему? Потому что раньше вы могли ездить на машине дедушки и радоваться жизнью. У моего соседа старый Мерс. Стоимость обслуживания близка к нулю. Да, он не сверкает всеми возможными лампочками, он не похоже на новогоднюю елку, но он надежно ездит - выполняет основную свою функцию. Сегодня этого класса машина это порядка 100к Евро каждые 4 года + значительные расходы на обслуживание. Если у вас много денег и вы можете это позволить - рад за вас, но среднестатистический житель даже Германии (где я и живу) такого себе позволить не может от слова "вообще".
Да у старых "Москвичей" ресурс был тоже не бог весь какой, но по тем временам 200к - это огромный ресурс, да и стоимость обслуживания у них был не в стоимость новой маленькой машины. Говорю, как когда-то владелец восьмерки (которой на момент продажи было 14 лет), и потом восьмерки (стоимость обслуживания даже тогда была смешной).
... возможно, потому что проблема существует?
Да, первая часть параграфа 6.2 звучит именно так.
Спасибо за оценку, но, как говорят, есть нюанс: стоит отличать "право собственности" от "лежать".
Это важное отличие как "получаете зарплату вы" (за ваш труд) или "ваш сосед".
Как когда-то было сказано: "Если на СЦЕНЕ висит ружьё, то в третьем акте оно должно выстрелить." Из письма Антона Павловича Чехова
Мы находимся только в начале пути. Правовое поле вокруг AI все еще только формируется, но то, что написано в данном конкретном лицензионном соглашении звучит достаточно тревожно.
Это лишь говорит, что пора начинать внимательно читать лицензионные соглашения, и информировать юристов вашего работодателя (даже если вы сам себе работодатель) о такого рода подводных камнях.
Большое спасибо за такое строгое замечание.
Хочу обратить ваше внимание на то, что есть важное отличие, когда вы что-то делаете сами, и используете какой либо тул, и когда вы используете тул, который что-то создает за вас.
Да, вы правы, в обеих случаях тул что-то генерит, даже компилятор генерит финальный код - в этом вы правы.
Есть одно маленькое но: что написано в лицензионном соглашении компилятора, которым вы пользуетесь? Вы читали? Там сказано, что сгенерированный код вам не принадлежит? Посмотрите, что написано в лицензионном соглашении и давайте вернемся к этой теме еще раз. Думаю, это будет и вам и мне интересно.
Всегда рад услышать развернутый ответ. Готов учится и открыт к детальному разбору ошибок ;-)
Вы упускаете один важный аспект: одно - когда вы пишите текст сами, и второе - когда текст пишет за вас система.
По поводу языка С - если вы произведете поиск, то увидите, что .... вот что выдает гугл сегодня:
No single entity "owns" the C programming language. It's a publicly available standard maintained by the ISO/IEC JTC1/SC22/WG14 working group.
Иными словами, это язык, который описан стандартом и как таковой не имеет владельца.
По поводу языка Rust ситуация немного другая, и вот что про это говорит гугл:
The Rust programming language is owned by the Rust Foundation. The foundation is a non-profit organization established by companies like Amazon Web Services, Google, Microsoft, and Mozilla.
Иными словами языком Rust владеет "без-прибыльная компания" (это лишь форма собственности, позволяющая не платить налоги), которой владеют 4 основных гиганта мировой IT промышленности.
Это важный нюанс. Если помните (нет, поищите, очень интересная история) истории с Java, как продукт, который был открытым и доступным всем забесплатно, был приобретен вместе с компанией Sun, и что было потом (возникшие лицензионные соглашения, споры и тому подобное).
Эта тема очень интересная, советую изучить. Игнорирование лицензионных вопросов не означает, что они вас не касаются ;-)
И, в качестве заключения, мне лично довелось наблюдать вдруг возникшие и очень дорогие проекты миграции связанные с резким изменением в лицензировании Java.
Да, на сегодняшний день тема дискриминации права пользователя встает все острее и острее. Полностью согласен.
То, что нужно читать соглашения - это тоже факт. Многие считают это не нужным, не интересным, некоторые этого сделать не могут, потому что тексты часто на английском.
бОльшая проблема появляется когда кто-то работает по контракту на какую-то фирму. Втянув чужой код или библиотеку, программист может (возможно не умышленно) создать сложную ситуацию для работодателя. Тема, которая заслуживает пристального внимания.
Если такое событие наступит, то сначала те, кто попал под претензию должны будут заплатить штрафы и неустойки. их размер, суммы могут быть для некоторых компаний убийственными.
Иными словами, компания до переписывания кода может недотянуть.
То что вы пишите для кого-то... этот кто-то может попасть под лицензионные риски. Поэтому, когда вы начинаете использовать новую библиотеку, которая вам понравилась, стоит прочитать лицензионное соглашение и поставить "кого-то" в известность. Риски не ваши, и вы работая по контракту или на зарплате косвенно отвечаете за увеличение или уменьшение рисков компании работодателя.
Для себя - тоже хороший вопрос. В какой-то момент у вас будет собственность, и, в случае какого либо судебного иска, вы несете ответственность и покрываете финансовые риски всем своим имуществом. Это стоит помнить.