Могу предложить схему, которая мне кажутся интересной, если её грамотно продумать.
Можно карму разбить на две составляющие:
Авторитет или репутация
Рассудительность или мудрость
Оценку сообщений также разбить на составляющие:
Отношение к сообщению: нравится или не нравится
Оценка истинности утверждения: правда или неправда
Авторитет и рассудительность привязываются не к человеку, а к его сообщениям. А оценки сообщений формируют веса, которые умножаются на показатели кармы. Карма же автоматически рассчитывается исходя из показателей репутации и рассудительности.
Такая система даёт некоторые плюсы и бонусы для дальнейшего развития идеи:
Если сообщения просто не нравятся, это не будет вызывать такой уж сильной обиды у людей.
По показателю рассудительности можно будет формировать доверие к информации преподносимой тем или иным пользователем.
На основе рассудительности и репутации можно будет видоизменить систему ограничений. Например, если человек рассудителен, но никому не нравится, нет смысла применять к нему жёсткие ограничения, несмотря на отрицательную карму, т. к. он иногда может выдавать полезные комментарии. Если же человек всем нравится, но не рассудителен, есть смысл дать ему время подумать между сообщениями.
В качестве бонуса можно в будущем получить неплохую систему самомодерации.
Приведу пример случая, где эта схема сработает лучше текущей. Обычно у меня карма балансирует около одного и того же значения, если не пишу глупости с недосыпа. Как-то на днях я указал человеку, что лучше об ошибках писать личными сообщениями, сообщение ушло в плюс, само собой. Но карма — на 1 в минус. Другие сообщения с малой вероятностью могли повлиять на карму. Возможно, человеку не понравилось, что его ткнули носом, может его единомышленники постарались. Но если бы карма привязывалась к сообщению с системой весов, то по факту она бы не ушла в минус.
Ну и в дополнение к этой схеме, к человеку можно привязывать другой, нейтральный, параметр — юморист/деловой человек. Тоже неплохой показатель для различных оценок в купе с другими параметрами.
А я вот обычно об ошибках и опечатках пишу личными сообщениями. Все мы люди и все ошибаемся, суперлюдей не существует. Завтра так получится, что заголовок поправят, а Ваше сообщение будет указывать в никуда.
Надо смотреть, что прописано в договорах и прочих документах, относящихся к режиму коммерческой тайны
Если договор есть, но как как таковой режим отсутствует (ничего нигде не расписано, устных указаний нет), то, по идее, может хватить подписи руководителя под распоряжением об открытии?
Я голосовать не могу, т. к. не хватает кармы, поэтому выскажусь в комментарии.
Меня больше интересует как правильно назначить лицензию продукту так, чтобы она была валидной и за границей, и у нас в стране. В том числе интересно, может ли открытие исходных текстов нести какие-либо риски в плане возможного нарушения иностранных и отечественных патентов и прочего. Причём интересует как для юридических лиц, так и для физических лиц с ограниченными финансовыми возможностями.
1. Если компания соберётся открывать часть неконкурентных исходных кодов, какие бумаги должны быть подписаны, в том числе, если есть договор о коммерческой тайне, чтобы ни у кого из сотрудников в будущем не могло быть проблем? И можно ли лицензировать исходники под иностранными лицензиями вроде GPL, LGPL и других?
2. Если IT-компания укажет в каких-либо договорах, что сотрудники не могут после увольнения использовать алгоритмы и идеи компании, будет ли это иметь хоть какую-то юридическую ценность, если нет патентов, но есть зарегистрированное авторское право на определённый продукт?
То есть на лицо — преадаптация: случай когда уже имеющаяся адаптация пригодилась в совсем иных условиях. И тут опять же можно вспомнить крабов бодро бегающих по суше.
Не соглашусь, что на лицо. Передвижение по дну не даёт никаких преимуществ, но делает рыб лёгкой добычей для хищных рыб. Поэтому эволюция быстро подобные виды сведёт на нет, либо загонит в жёсткие рамки, вроде маскировки, если для них это основной способ передвижения. В условиях наличия хищников важна обтекаемость и скорость. Плавники с мышцами скорости не дадут, поэтому упор будет на хвост и мышцы тела.
Более вероятно будет эволюция в условии приливов/отливов и пересыхания водоёмов. В этом случае рыбы получают преимущество — защиту хищников на мелководье. С появлением наземных хищников, а особенно птиц, эти рыбы резко потеряли преимущества, поэтому сейчас являются редкостью.
Но лично моё мнение — скорее всего эволюция шла в условиях частого пересыхания водоёмов, — больше шансов.
Поправлю себя, увидел комментарий выше от Dorogonov_DA после того как написал сообщение, приливы и отливы аналогичны водоёмам и даже более правдоподобны.
P.S. Опять сообщения появляются не под теми, на которые отвечаешь…
Вот интересно. Раз, и животное вышло из моря 300 млн. лет назад. А ножки ростило в океана? По идее — должны быть промежуточные какие-то создания, у которых еще нет таких развитых конечностей.
Stan_1, найти промежуточные версии крайне трудно. Да и шансы маленькие, т. к. естественный отбор будет с огромной скоростью двигать гены в нужном направлении.
При этом часть в будущем полезных генов могут оставаться долгое время рецессивными и приводить к ранней смерти особей, у который нет нормальных аллелей, пока не появятся условия, где они, совместно с другими мутантными генами, смогу предоставить конкурентные преимущества. В таком случае естественный отбор начнёт действовать в другом направлении. А затем рецессивными гены могут быть заменены схожими доминантными.
А лапы имели большие шансы на появление в условиях частого пересыхания водных территорий. Либо если рыбы часто по ошибке выбирались на мелководье (например, гоняясь за мелкой едой подобно косаткам), — чтобы вернуться назад, им могли потребоваться значительные усилия, но чаще это могло приводить к смерти. Скорее всего часть рыб получила гены страха мелководья, а часть — гены конечностей. Гены конечностей со временем развивались. Гены мелководья должны были стать более конкурентными при наличии хищников (обтекаемость), поэтому рыбы с конечностями со временем были вытеснены на сушу. Но лично моё мнение — скорее всего эволюция шла в условиях частого пересыхания водоёмов, — больше шансов.
Эволюция идёт быстрыми шажками по длительным периодам стабильности. Скорее всего, промежуточная эволюция шла очень быстро на очень маленьком участке участке территории, а затем вид распространился повсеместно. Поэтому найти следы очень короткого промежутка времени будет сложно или даже невозможно.
На самом деле не всегда такое правило применимо. Я пришёл ровно к таким же принципам, что Вы изложили, собственно, удивился увидев стиль программирования один в один как у себя, только на другом языке.
Первым в операторе условия должен идти не истинный блок, а логически ожидаемый. Например, у нас в Си, если произошла ошибка, мы должны сначала явно обработать ошибку:
char *str = malloc(str_size);
if (!str) {
// ... сохранение errno, если требуется
perror("malloc");
// ...
} else {
// в невероятно крайне редких случаях этот блок может присутствовать
}
Но в то же время для условных строк условие будет обратным:
if (str) {
// работа с str
} else {
// какая-либо другая логика
}
Пример плохой, но это первое, что пришло в голову.
Читали вообще? Мне надо было говорить «крайне разрежённая, в десять триллионов раз менее плотная Земной, никак не воздействующая на Луну и не сжигающая приближающиеся объекты атмосфера» или всё таки проще сказать, что её нет в рамках рассматриваемого вопроса?
Витапрост (Уропрост/Простатилен/Сампрост/Vitaprost): препарат для лечения и профилактики всевозможных простатитов в инструкции честно сказано «Данные о фармакокинетике препарата Витапрост не предоставлены»; в составе экстракт простаты скота, что естественно относится к БАДам.
И ведь, если они это производят, значит это кто-то покупает?
Не, там вопрос не в том, чтоб сделать терраформирование, а в том, что доставлять воду с Земли крайне дорого. А любой космический корабль с людьми или космическая база будут требовать запасы воды. Сейчас выкручиваются созданием полностью замкнутого цикла.
Не смог найти, кто какие идеи по доставке предлагает, но вот воду на астероидах добывать собираются. Её оценивают как самый ценный ресурс в будущем в космосе. Думаю, понятно, почему. И вот её доставлять не будет особых проблем, как мне кажется. Вообщем, в будущем будем новая индустрия в космосе, и она будет совсем не похожа не земную: habr.com/post/181283 www.popmech.ru/science/12972-dobycha-poleznykh-iskopaemykh-na-drugikh-planetakh/#part5
Зато поверхность есть, так что что не сгорит в результате удара — то разлетится мельчайшими осколками на много километров вокруг :)
Технологии не будут стоять на месте, можно создавать специальные площадки и целенаправленно туда запускать прессованные ресурсы. Приём ресурсов также можно сделать с автоматическим смягчением падения с помощью специальных устройств при условии приёма блоков небольшой массы. Стрелять с астероида такими блоками также будет не очень сложно. Корректировку курса можно делать точечными выстрелами с поверхности Луны. Сейчас такие идеи выглядят фантастикой, а в будущем могут экономически оказаться очень выгодными.
Что дороже: создать фабрики по строительству ракет на Луне, запуская их оттуда, или запукать ракеты с Земли? Вопрос больше по знанию физики, а не экономики. Про доступность ресурсов пока говорить рано, само собой. Но что-нибудь да придумают. Те же астероиды можно использовать для добычи ресурсов. Атмосферы на луне нет, туда можно прямиком отправлять, ничего не сгорит.
А так же сквозь облака, спутники, головы. КПД будет низок.
Вам знаком термин «целесообразность» ?) Я думаю за одну только стоимость ДОСТАВКИ туда этих батарей, можно будет сделать еще один комплект.
Для таких целей и делается геологическая разведка, чтобы понять актуальность тех или иных задач, а также технологий. Сейчас этим активно занимаются как на Марсе, так и на Луне. Первые базы позволят этим заниматься вглубь, причём буквально. А как будет известно, чем там можно поживиться, там и технологии подстроятся под материалы. Не стоит думать, что солнечные батареи можно только из земных материалов собирать.
и может именно поэтому человечество до сих пор себя не уничтожило.
Когда придумали ядерную бомбу, учёных спрашивали, может ли она зажечь атмосферу, учёные говорили, что такая вероятность есть, но власть-держащие бомбу взорвали. Сейчас есть термоядерная бобма. Разницу в мощности понимаете? Ещё не испытывали на городах? Вот то же самое будет и с подобными лазерами. Испытают, но гуманно, испарив какое-нибудь озерцо искусственное. А дальше новая гонка вооружений.
К счастью наш создатель или создатели
Советую прочитать «Эгоистичный ген» Ричарда Докинза. А заодно задуматься, кто создал создателей. А пока Вы обдумываете написанное пойду покормлю невидимого бестелесного дракона в своём невидимом гараже из астральной реальности. :)
Но вот по поводу остального: космический бум последних лет не был следствием гонки сверхдержав.
Лично моё мнение — это как раз гонка, но уже не за публичное мнение, а за территории, возможности и технологии. Освоение Луны и Марса скоро уже перестанет быть научной фантастикой. Представьте, какие возможности открываются при создании лунной базы.
Из того, что сейчас кажется нереальной научной фантастикой — покрытие огромных территорий на Луне солнечными батареями, передача энергии через лазерные лучи на Землю. А отсюда и мощное оружие вытекает: точечный удар из космоса по шахте с ядерной ракетой и вуаля. А солнечные фермы требуется защищать от космических угроз, а это ещё одна ветвь науки и область финансирования.
И ещё одну вещь пропустил, всегда sizeof(char) == 1, это гарантируется компилятором. Что, как и почему — хорошо описано в Википедии. Поэтому проще и понятнее не использовать sizeof в этом случае. Сам некоторое время страдал такой паранойей, пока в стандарт не полез: www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf
Уж извиняюсь, что много написал, посто делать ревью кода и показывать все недостатки уже в привычке по работе, а код на Си тут редко проплывает, не могу пройти мимо. :)
И ещё, если пишете под GLib, то лучше и используйте функции GLib. Например, вместо calloc()/free() лучше использовать g_malloc0()/g_free(). Результат такого выделения памяти не требуется проверять на NULL, т. к. в него встроен g_assert(), что называется «ленивым программированием».
У Вас же используется calloc()/free(), но не проверяется результат работы этой функции calloc(). Она имеет полное право вернуть NULL, если памяти не хватило. В общедоступных примерах такие проверки обязательно должны быть всегда и везде, иначе новички могут приучиться к плохому.
А почему не используете вместо get_real_path() стандартную функцию realpath()?
Пожалуйста. Наконец, добрался до этой статьи ещё раз, для загрузки SVG нативная поддержка есть в GdkPixbufLoader.В итоге получается GdkPixbuf. Явно задать размер можно по обработчику «size-prepared», для этого в нём требуется вызвать функцию gdk_pixbuf_loader_set_size(). Любые данные туда можно опять же передать через user_data. При этом в обработчик попадают натуральные размеры, которые заданы в самом svg-файле. При создании своего виджета на основе картинки, к примеру, можно использовать эти размеры как натуральные для виджета (у виджетов есть натуральные и минимальные).
Единственное «но» — если требуется изменить размер, Pixbuf требуется пересоздавать, но оно и понятно, — по-другому никак. Для этого можно закешировать файл в GBytes, и писать его через gdk_pixbuf_loader_write_bytes(). Для чтения файла рекомендую g_mapped_file_get_bytes().
Если будут вопросы, спрашивайте, что могу, подскажу.
Можно карму разбить на две составляющие:
Оценку сообщений также разбить на составляющие:
Авторитет и рассудительность привязываются не к человеку, а к его сообщениям. А оценки сообщений формируют веса, которые умножаются на показатели кармы. Карма же автоматически рассчитывается исходя из показателей репутации и рассудительности.
Такая система даёт некоторые плюсы и бонусы для дальнейшего развития идеи:
Приведу пример случая, где эта схема сработает лучше текущей. Обычно у меня карма балансирует около одного и того же значения, если не пишу глупости с недосыпа. Как-то на днях я указал человеку, что лучше об ошибках писать личными сообщениями, сообщение ушло в плюс, само собой. Но карма — на 1 в минус. Другие сообщения с малой вероятностью могли повлиять на карму. Возможно, человеку не понравилось, что его ткнули носом, может его единомышленники постарались. Но если бы карма привязывалась к сообщению с системой весов, то по факту она бы не ушла в минус.
Ну и в дополнение к этой схеме, к человеку можно привязывать другой, нейтральный, параметр — юморист/деловой человек. Тоже неплохой показатель для различных оценок в купе с другими параметрами.
Если договор есть, но как как таковой режим отсутствует (ничего нигде не расписано, устных указаний нет), то, по идее, может хватить подписи руководителя под распоряжением об открытии?
Меня больше интересует как правильно назначить лицензию продукту так, чтобы она была валидной и за границей, и у нас в стране. В том числе интересно, может ли открытие исходных текстов нести какие-либо риски в плане возможного нарушения иностранных и отечественных патентов и прочего. Причём интересует как для юридических лиц, так и для физических лиц с ограниченными финансовыми возможностями.
2. Если IT-компания укажет в каких-либо договорах, что сотрудники не могут после увольнения использовать алгоритмы и идеи компании, будет ли это иметь хоть какую-то юридическую ценность, если нет патентов, но есть зарегистрированное авторское право на определённый продукт?
Не соглашусь, что на лицо. Передвижение по дну не даёт никаких преимуществ, но делает рыб лёгкой добычей для хищных рыб. Поэтому эволюция быстро подобные виды сведёт на нет, либо загонит в жёсткие рамки, вроде маскировки, если для них это основной способ передвижения. В условиях наличия хищников важна обтекаемость и скорость. Плавники с мышцами скорости не дадут, поэтому упор будет на хвост и мышцы тела.
Более вероятно будет эволюция в условии приливов/отливов и пересыхания водоёмов. В этом случае рыбы получают преимущество — защиту хищников на мелководье. С появлением наземных хищников, а особенно птиц, эти рыбы резко потеряли преимущества, поэтому сейчас являются редкостью.
Поправлю себя, увидел комментарий выше от Dorogonov_DA после того как написал сообщение, приливы и отливы аналогичны водоёмам и даже более правдоподобны.
P.S. Опять сообщения появляются не под теми, на которые отвечаешь…
Stan_1, найти промежуточные версии крайне трудно. Да и шансы маленькие, т. к. естественный отбор будет с огромной скоростью двигать гены в нужном направлении.
При этом часть в будущем полезных генов могут оставаться долгое время рецессивными и приводить к ранней смерти особей, у который нет нормальных аллелей, пока не появятся условия, где они, совместно с другими мутантными генами, смогу предоставить конкурентные преимущества. В таком случае естественный отбор начнёт действовать в другом направлении. А затем рецессивными гены могут быть заменены схожими доминантными.
А лапы имели большие шансы на появление в условиях частого пересыхания водных территорий. Либо если рыбы часто по ошибке выбирались на мелководье (например, гоняясь за мелкой едой подобно косаткам), — чтобы вернуться назад, им могли потребоваться значительные усилия, но чаще это могло приводить к смерти. Скорее всего часть рыб получила гены страха мелководья, а часть — гены конечностей. Гены конечностей со временем развивались. Гены мелководья должны были стать более конкурентными при наличии хищников (обтекаемость), поэтому рыбы с конечностями со временем были вытеснены на сушу. Но лично моё мнение — скорее всего эволюция шла в условиях частого пересыхания водоёмов, — больше шансов.
Эволюция идёт быстрыми шажками по длительным периодам стабильности. Скорее всего, промежуточная эволюция шла очень быстро на очень маленьком участке участке территории, а затем вид распространился повсеместно. Поэтому найти следы очень короткого промежутка времени будет сложно или даже невозможно.
Первым в операторе условия должен идти не истинный блок, а логически ожидаемый. Например, у нас в Си, если произошла ошибка, мы должны сначала явно обработать ошибку:
Но в то же время для условных строк условие будет обратным:
Пример плохой, но это первое, что пришло в голову.
encyclopatia.ru/wiki/Расстрельный_список_препаратов
Там очень много интересного, вплоть до такого:
И ведь, если они это производят, значит это кто-то покупает?
habr.com/post/181283
www.popmech.ru/science/12972-dobycha-poleznykh-iskopaemykh-na-drugikh-planetakh/#part5
Ну, что я тут могу сказать… :)
Технологии не будут стоять на месте, можно создавать специальные площадки и целенаправленно туда запускать прессованные ресурсы. Приём ресурсов также можно сделать с автоматическим смягчением падения с помощью специальных устройств при условии приёма блоков небольшой массы. Стрелять с астероида такими блоками также будет не очень сложно. Корректировку курса можно делать точечными выстрелами с поверхности Луны. Сейчас такие идеи выглядят фантастикой, а в будущем могут экономически оказаться очень выгодными.
Что дороже: создать фабрики по строительству ракет на Луне, запуская их оттуда, или запукать ракеты с Земли? Вопрос больше по знанию физики, а не экономики. Про доступность ресурсов пока говорить рано, само собой. Но что-нибудь да придумают. Те же астероиды можно использовать для добычи ресурсов. Атмосферы на луне нет, туда можно прямиком отправлять, ничего не сгорит.
Да без вопросов. Беспокоит КПД, которое кстати не беспокоит российских учёных (тут), вот другое решение, снабжение орбитальных аппаратов энергией, получаем возможности роста космических баз:
www.popmech.ru/technologies/303382-luch-zhizni-peredacha-energii-lazerom/#part3
Для таких целей и делается геологическая разведка, чтобы понять актуальность тех или иных задач, а также технологий. Сейчас этим активно занимаются как на Марсе, так и на Луне. Первые базы позволят этим заниматься вглубь, причём буквально. А как будет известно, чем там можно поживиться, там и технологии подстроятся под материалы. Не стоит думать, что солнечные батареи можно только из земных материалов собирать.
Когда придумали ядерную бомбу, учёных спрашивали, может ли она зажечь атмосферу, учёные говорили, что такая вероятность есть, но власть-держащие бомбу взорвали. Сейчас есть термоядерная бобма. Разницу в мощности понимаете? Ещё не испытывали на городах? Вот то же самое будет и с подобными лазерами. Испытают, но гуманно, испарив какое-нибудь озерцо искусственное. А дальше новая гонка вооружений.
Советую прочитать «Эгоистичный ген» Ричарда Докинза. А заодно задуматься, кто создал создателей. А пока Вы обдумываете написанное пойду покормлю невидимого бестелесного дракона в своём невидимом гараже из астральной реальности. :)
Лично моё мнение — это как раз гонка, но уже не за публичное мнение, а за территории, возможности и технологии. Освоение Луны и Марса скоро уже перестанет быть научной фантастикой. Представьте, какие возможности открываются при создании лунной базы.
Из того, что сейчас кажется нереальной научной фантастикой — покрытие огромных территорий на Луне солнечными батареями, передача энергии через лазерные лучи на Землю. А отсюда и мощное оружие вытекает: точечный удар из космоса по шахте с ядерной ракетой и вуаля. А солнечные фермы требуется защищать от космических угроз, а это ещё одна ветвь науки и область финансирования.
www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf
Уж извиняюсь, что много написал, посто делать ревью кода и показывать все недостатки уже в привычке по работе, а код на Си тут редко проплывает, не могу пройти мимо. :)
У Вас же используется calloc()/free(), но не проверяется результат работы этой функции calloc(). Она имеет полное право вернуть NULL, если памяти не хватило. В общедоступных примерах такие проверки обязательно должны быть всегда и везде, иначе новички могут приучиться к плохому.
А почему не используете вместо get_real_path() стандартную функцию realpath()?
Единственное «но» — если требуется изменить размер, Pixbuf требуется пересоздавать, но оно и понятно, — по-другому никак. Для этого можно закешировать файл в GBytes, и писать его через gdk_pixbuf_loader_write_bytes(). Для чтения файла рекомендую g_mapped_file_get_bytes().
Если будут вопросы, спрашивайте, что могу, подскажу.