Только сейчас случайно я нашел тот источник, от которого я отталкивался, когда обдумывал эту идею. Оказалось, что это научная статья: "Causal Entropic Forces" авторства Dr. Alex D. Wissner-Gross & C. E. Freer, опубликованная в "Physical Review Letters" в 2013 году.
Но, вообще, вы правы на счет того, что "принцип глубже". Он касается не только активности "роботов", но и той-же разработки, например. Некоторые из прописанных в нем аксиом не позволяют делать деструктивные действия типа удаления продуктовой базы данных. Или принцип "увеличения DoF системы" позволяет проектировать с помощью ИИ достаточно качественную архитектуру приложений.
Естественно, что в реализации надо все это учитывать. В общем, этот принцип не исключает использование его, например, в военных роботах. Просто классификатор будет на основе системы "свой-чужой" классифицировать "врага" как "источник коллапса". Я недавно провел моделирование этой ситуации. И даже здесь появились интересные вещи... Если мирное население считать обычными агентами, то такой "боевой робот" будет действовать максимально избирательно что-бы не было жертв среди мирного населения. Кроме того (что для меня было полной неожиданностью), в одном из вариантов "дружеского столкновения" (две группы "своих", по ошибке принявшие друг друга за противника), робот даже пошел на самопожертвование ради спасения людей.
Но, вообще, в репозитарии есть не только "скилл" для агентов. Есть и спецификация, которая описывает построение систем с использованием этого принципа. И там есть и "защита от галюцинаций" и "система прерываний" при изменении обстановки.
Как-то по молодости лет перепутал параметры в команде ln и сделал /dev/null некорректным симлинком. Пришлось поразбираться почему это на сервере все рухнуло. :))) Хорошо что сервер был в физическом доступе. :)+
Это библиотека + переводчик. Сейчас работает под Linux - на винду еще не адаптировал.
Лицензия MIT или Apache на выбор. Режим синхронного голосового перевода или только текст. Я больше стрессую из-за того что могу не понять что мне говорят. Поэтому добавил и текстовый режим без голоса.
Ну, тут я предложил возможный механизм принятия патчей сообществом, а не отдельным человеком. Естественно, все это обсуждаемо. Например, разработчики, получившие крипту за свои патчи будут иметь больше возможностей по голосованию за другие патчи и т.д.
Тут больше проблема не в форке ядра (их и так дофига существует), а в том, как управлять приемом доработок в него. Насколько я понимаю, Линус и его команда, в основном, занимается именно этим.
В этом плане, что-бы исключить имеющийся прецедент, можно организовать управление приемом патчей (или их отменой) совместными действиями сообщества. Например, создать систему "голосования" на блокчейне. Что-бы заинтересованные в доработках ядра "голосовали" за конкретные изменения, например, переводом специальной криптовалюты на счет "патча".
Конкретности, конечно, надо еще обсуждать. Но то, что дублирование текущей системы принятия патчей бессмысленно, это однозначно.
Очень полезно! Спасибо большое! Иногда хочется написать что-то на сербском латиницей правильно, но опыт с подключением обычной сербской раскладки оказался неудачным. Попробую ваш вариант.
Только сейчас случайно я нашел тот источник, от которого я отталкивался, когда обдумывал эту идею. Оказалось, что это научная статья: "Causal Entropic Forces" авторства Dr. Alex D. Wissner-Gross & C. E. Freer, опубликованная в "Physical Review Letters" в 2013 году.
Abstract & Publisher: APS Journal Link - https://link.aps.org/doi/10.1103/PhysRevLett.110.168702
Open Access PDF (MIT DSpace Archive): MIT DSpace Permanent URL -
https://dspace.mit.edu/entities/publication/52f1bf4e-04e4-4229-b321-92dc51feb66d
Но, вообще, вы правы на счет того, что "принцип глубже". Он касается не только активности "роботов", но и той-же разработки, например. Некоторые из прописанных в нем аксиом не позволяют делать деструктивные действия типа удаления продуктовой базы данных. Или принцип "увеличения DoF системы" позволяет проектировать с помощью ИИ достаточно качественную архитектуру приложений.
Естественно, что в реализации надо все это учитывать. В общем, этот принцип не исключает использование его, например, в военных роботах. Просто классификатор будет на основе системы "свой-чужой" классифицировать "врага" как "источник коллапса". Я недавно провел моделирование этой ситуации. И даже здесь появились интересные вещи... Если мирное население считать обычными агентами, то такой "боевой робот" будет действовать максимально избирательно что-бы не было жертв среди мирного населения. Кроме того (что для меня было полной неожиданностью), в одном из вариантов "дружеского столкновения" (две группы "своих", по ошибке принявшие друг друга за противника), робот даже пошел на самопожертвование ради спасения людей.
Но, вообще, в репозитарии есть не только "скилл" для агентов. Есть и спецификация, которая описывает построение систем с использованием этого принципа. И там есть и "защита от галюцинаций" и "система прерываний" при изменении обстановки.
Забавно. Я вот более чем опытный разработчик с большим бэкэндом. Но работу не могу найти с начала года. Что я делаю не так?
Как-то по молодости лет перепутал параметры в команде ln и сделал
/dev/nullнекорректным симлинком. Пришлось поразбираться почему это на сервере все рухнуло. :))) Хорошо что сервер был в физическом доступе. :)+А почему-бы текущий snapshot состояния сети не подписывать узлами так-же, как они подписывают транзакции?
Прикольно. Я недавно решал ту-же задачу по той-же причине. :) Получилось вот это: https://github.com/UncleAndy/transono
Это библиотека + переводчик. Сейчас работает под Linux - на винду еще не адаптировал.
Лицензия MIT или Apache на выбор. Режим синхронного голосового перевода или только текст. Я больше стрессую из-за того что могу не понять что мне говорят. Поэтому добавил и текстовый режим без голоса.
При наличии Open Source можно было-бы общими силами адаптировать под другие ОС.
И не Open Source? Будете продавать?
Только для айфона? Жаль. Но идея классная. У меня есть инструмент для ее реализации под Linux и Windows (тоже pet-проект).
Как раз недавно исследовал тему разработки для бирж. Очень понравились методы, позволяющие добиться минимальной задержки и высокой скорости обработки.
Если агент должен будет работать с данными на естественных языках, не советую BM25. Он языкозависимый.
Крайне интересная тема. Но, что-то я не смог перейти на страницу курса.
Я недавно с удивлением обнаружил, что Rust используется в качестве языка для написания смарт-контрактов в блокчейне Stellar. :)
В таких случаях у меня единственная мысль - "Не хотите со мной работать? Ну, значит, сами себе злобные буратины!". :)))
Ну, я-бы сказал, не мерж-реквесты, а механизмы их аппрува. :)
Ну, тут я предложил возможный механизм принятия патчей сообществом, а не отдельным человеком. Естественно, все это обсуждаемо. Например, разработчики, получившие крипту за свои патчи будут иметь больше возможностей по голосованию за другие патчи и т.д.
Тут больше проблема не в форке ядра (их и так дофига существует), а в том, как управлять приемом доработок в него. Насколько я понимаю, Линус и его команда, в основном, занимается именно этим.
В этом плане, что-бы исключить имеющийся прецедент, можно организовать управление приемом патчей (или их отменой) совместными действиями сообщества. Например, создать систему "голосования" на блокчейне. Что-бы заинтересованные в доработках ядра "голосовали" за конкретные изменения, например, переводом специальной криптовалюты на счет "патча".
Конкретности, конечно, надо еще обсуждать. Но то, что дублирование текущей системы принятия патчей бессмысленно, это однозначно.
Очень полезно! Спасибо большое! Иногда хочется написать что-то на сербском латиницей правильно, но опыт с подключением обычной сербской раскладки оказался неудачным. Попробую ваш вариант.
Давно пользуюсь ssh + sshuttle. Думаю, самый невидимый вариант VPN. :)