Как стать автором
Обновить
4
0.3

Software Engineer

Отправить сообщение
Это если проект свой. А если я пишу код для кого-то другого? Все-таки LGPL является более разумным компромиссом. Лично у меня такое мнение: если библиотека является основополагающей для твоей программы, ее ядром, так сказать, тогда да, разумно наследовать лицензию этой библиотеки. А если это маленькая библиотека, реализующая какую-то небольшую функцию, то она не должна влиять на лицензию остального кода.
Пароль на RAR-архив: KLub8pT&iU$8oBY(*$NOiu

Почему не homelesspa?
Во-первых, в такой ситуации Вам отказала фирма, а не эппл.

Под давлением Эппл. При совершении преступления виноват не только исполнитель, но и заказчик, если таковой имелся. А если исполнитель был принужден насильно, то тем более.
Во-вторых, она отказала Вам не потому что производитель запретил, а потому что они не получили разрешения.

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

Государство что-то запрещает, будучи легитимным, например, всенародно избранным, или, по крайней мере, всенародно признаваемым. Кто такой эппл, что он свои запретительные законы выдвигает? Причем, как вы сами заметили, запрещает он не покупателям, которые хотя бы условно что-то выбрали, и на что-то там согласились, купив себе айфон. А запрещает ремонтникам.
То есть вы верите в «невидимую руку рынка»? Учитывая, что деньги тянутся к деньгам, а крупные игроки стремятся к монополии и гегемонии, эта самая рука всегда будет заводить нас куда-то не туда. Так что идею просто не заключать договор, если условия не устраивают, я считаю слишком поверхностной и, далеко не всегда ведущей к светлому будущему. Вообще есть такое юридическое понятие, как «слабая сторона договора».
Более слабая сторона, которая вынуждена принять формуляр договора, разработанный контрагентом, должна получить защиту от несправедливых условий, даже если эти условия не противоречат закону, а соглашение не является договором присоединения.

Чтобы контрагент имел право на защиту от несправедливых условий, он должен находиться в положении, затрудняющем согласование тех или иных пунктов договора. Для определения наличия свободной воли при заключении договора судам предлагается оценивать:
фактическое соотношение переговорных возможностей сторон;
уровень их профессионализма в соответствующей сфере;
конкуренцию на соответствующем рынке;
наличие у присоединившейся стороны реальной возможности вести переговоры или заключить аналогичный договор с третьими лицами на иных условиях и т.д.

Я не юрист, и возможно юристы сейчас объяснят, что покупка аренда смартфона это не тот случай. Тем более, не знаю есть ли аналог этого понятия в американских законах. Но на мой взгляд, логика, стоящая за данным понятием, так же применима и тут. Ведь у покупателя нет возможности кастомизировать договор. С ним даже разговаривать не станут. Компанию может оправдывать наличие конкуренции, и возможности у покупателя купить другой смартфон. Но конкуренция тут не такая уж и бесспорная. Является ли другой смартфон полным аналогом айфона? Так что, на необходимость и правомерность налагаемых договором ограничений тоже будут смотреть. Заметьте, Эппл угрожает парню подать в суд за нарушение авторских прав, а не за ремонт. Это значит, что нельзя просто так взять и запретить кому-то ремонтировать устройство. Приходится прикрываться левыми предлогами.
Закон суров, но это всего-лишь закон. Это я к тому, что ни один закон не даст гарантии безотказности. Закон поможет определить виновных. Это тоже важно, и он однозначно нужен. Но надо стремиться к большему. Мой тезис был не в том, чтобы не использовать маяки, а в том, что автопилот должен справляться и без них. Причины моего мнения следующие:
1. Автопилот, в любом случае, должен иметь хорошую отказоустойчивость.
2. Маяки, в качестве обязательного требования, появятся только после того, как процент автономных машин достигнет определенного уровня. До тех пор, автопилоту придется справляться без них.
3. На данный момент, я не представляю, что может использоваться в качестве обсуждаемого нами маяка, чтобы дать достаточную точность и надежность. Откуда брать точные координаты? У GPS погрешность — 20 метров. А помимо координат нужно знать ориентацию в пространстве, габариты. Передаваться все будет по радио? Что делать с помехами? Что если злоумышленник поставит глушилку? Все эти вопросы надо решить, на это нужно время, а автономные машины уже ездят.
4. На велосипеды тоже маяки повесим? А на пешеходов? На детские коляски? На животных? На деревья и столбы?
Все это говорит нам о том, что маяки могут быть не более, чем дополнительной страховкой. Я изначально так и написал:
В будущем всякие примочки можно добавить, но необходимый минимум должен быть достигнут без них.

На мой взгляд, такой минимум — это водить не хуже человека, используя только автономные датчики, т.е. без сигналов от спутника, от других машин, от чего либо еще. Условно говоря — глаза и уши. С той лишь поправкой, что у машины, тех же глаз может быть много, видящих в разных спектрах.
А вот дополнительные источники информации уже дадут нам повышенную надежность. Машины смогут общаться друг с другом, «говорить» где они находятся, что они собираются сделать и т.д. Но если другая машина молчит, или ее «слова» противоречат тому, что мой автомобиль «видит», то он должен верить только своим «глазам», так же, как это сделал бы человек.
Тут надо понимать, что далеко не все генетические заболевания сводят на нет полезность человека для общества. К примеру, повернется ли у вас язык сказать, что Стивен Хокинг является обузой для общества?
Наличие у человека плохого гена, не гарантирует отсутствия у него хороших генов. Глупо видеть в человеке с «плохим» геном, только один этот ген. Даже если смотреть только на уровне генов, человек — это комбинация генов. Не забывайте об этом.
1. Самолеты проходят куда более строгий контроль, чем автомобили. В том числе ежедневный. Что если какие-то датчики будут неисправны? Что если у кого-то сломается маяк? В отличие от глаз водителя, датчики находятся снаружи и могут в любой момент загрязниться, повредиться и т.д. К тому же, не исключен взлом программного обеспечения. Представьте что будет, если вирус отключит половину датчиков, или удалит фуру с проекционного дисплея. К самолету сложнее получить доступ, чтобы что-такое вытворить. В отличие от автомобиля.
2. В случае с самолетом, у пилота нет особого выбора, кроме как доверять датчикам. Условия другие. Глаза там гораздо менее полезны.
3. Средний пилот более профессионален, чем средний водитель авто.
Прогресс конечно нужен, но когда речь идет о безопасности, стоит проявлять здоровый консерватизм. В данном конкретном случае, это означает, что ИИ должен научиться хорошо водить, полагаясь на минимум информации, без всяких маяков. Только зрение, только хардкор. Водители так же должны научиться правильно взаимодействовать с автопилотом. В будущем всякие примочки можно добавить, но необходимый минимум должен быть достигнут без них. В долгосрочной перспективе, осторожный подход, как раз ускорит прогресс, потому что поможет значительно снизить негативное отношение людей к технологии. А это очень важно. Не стоит давать в руки технофобов лишние козыря, вроде сбитых автопилотом детей.
Насколько понимаю, автопилот добавили уже после того, как машины ушли в продажу. То есть он просто прилетел с очередным обновлением. При этом новые датчики у машины, естественно, не выросли.
Если мы будем точно знать, какой ген за что отвечает, и как именно они действуют, а для «designer kids» это необходимо, то мы сможем смоделировать работу этого алгоритма на компьютере. Это будет тот же самый алгоритм, только выполняться он будет на порядки быстрее. Какой же это эволюционный тупик? Это скорее эволюционная сингулярность.
Не стоит так драматизировать. Речь же не обо всех законах общества, а только о валюте — область достаточно узкая и консервативная. Причем только об основном алгоритме, который определяет суть валюты. Если его изменить, то это будет уже другая валюта.
А теперь еще раз внимательно перечитайте свое утверждение, особенно обратите внимание вот на это:
Мне кажется, использовать баг софта для обворовывания участников...

Ситуация лично мне напоминает то, как на первых порах...

Нет, я согласен с вашей моральной оценкой этого поступка. Я тоже такое не одобряю. Наверное, большинство людей такое не одобрит. Но это всего лишь мнение. Даже если это мнение разделяет большинство, то это всего лишь общественное мнение. Но в том-то и дело, что криптовалюта это не демократия. Криптовалюты, позиционируют себя как системы, которые лучше чем демократия. Системы, в которых не надо полагаться на чье-то мнение. Ведь демократия — это далеко не идеал. История знает примеры, когда большинство было неправо. Особенно опасно, когда активные действия берет на себя узкая группа лиц (НКВД, КГБ, инквизиция, разработчики криптовалюты), а от большинства требуется лишь согласие на это. Еще хуже, когда достаточно молчаливого согласия (75% не голосовали, а их записали в согласные). Я не спорю, что это можно назвать демократией. Но в данном случае, уместней будет назвать это «всего лишь очередной, паршивой демократией». Именно в такой тональности. Паршивой — потому, что хорошая демократия, не признает референдум, по поводу существенного изменения конституции, состоявшимся, при явке в 25%.
Более того, валюта не может основываться на демократии. Просто потому. что деньги имеют свойство аккумулироваться у небольшого круга лиц. Валюта, которая учитывает интересы большинства — это бесконечный 1917 год. Если же силу голоса привязывать к капиталу, то это уже олигархия какая-то. Если придумать выборную, или еще как-то сформированную элиту, условно не зависящую от денег — классическое государство, с разделением на богатых, чиновников, и всех остальных. Криптовалюта может качественно отличаться от этого всего только в том случае, если её законы определяются алгоритмом, и алгоритм не меняется. Ни под каким предлогом. Никогда.
Так я и не говорил, что в ФП это невозможно. Но чем тогда этот «GenServer Teapot, у которого есть состояние(наличие и температура воды) и кто угодно может послать ему сообщение и узнать актуальное состояние в любой момент времени» отличается от «public static class Teapot у которого есть состояние(наличие и температура воды) и кто угодно может обратиться к нему и узнать актуальное состояние в любой момент времени»?
Естественно, чем сложнее бизнес-логика, тем сложнее окажется алгоритм. Дело в том, что все вопросы разграничения доступа к чайнику, на которые вы указываете, следуют из сущности чайника, и сценария его использования. А значит все эти конфликты придется разрешать в любом случае, не зависимо от парадигмы программирования. Чайник у нас, по логике предметной области, является общим ресурсом. В нашем приложении мы можем представить его как мутабельной, так и иммутабельной структурой. Но во втором случае, придется все равно синхронизировать иммутабельные копии. Мы просто будем имитировать мутабельность. Но зачем?
На практике, даже просто тот факт, что уровень в игре создается динамически, например игра предоставляет редактор карт, может дать просадку в производительности. Во всяком случае в Unity так. Из справки Unity:
Оптимизация для CPU — количество draw call (в дальнейшем, DC)
В процессе визуализации любого объекта на экране CPU должен немного потрудиться: выяснить, какие источники света влияют на объект, настроить шейдер и его параметры, отправить команды отрисовки графическому драйверу, который подготовит команды для отправки на видеокарту. Все эти операции могут быть не очень дешёвыми в своей сумме, если у вас есть много видимых объектов.
Для примера, если у вас есть тысяча треугольников, то будет намного дешевле разместить их в одном меше, чем использовать тысячу отдельных мешей для каждого треугольника. Стоимость обоих сценариев для GPU будет примерно одинаковой, но работа, выполняемая CPU для тысячи объектов вместо одного будет намного большей по объёму.

Чтобы снизить нагрузку на CPU, старайтесь уменьшить количество видимых объектов:
Объединяйте близко расположенные объекты: вручную или используя инструмент draw call batching в Unity.
Используйте меньше материалов, объединяйте текстуры в большие текстурные атласы.
Используйте меньше объектов, которые должны визуализироваться несколько раз.
Объединяйте объекты так, чтобы каждый меш содержал хотя бы несколько сотен треугольников и использовал только один Материал. Важно понимать, что объединение двух объектов, использующих разные материалы, не даст увеличения производительности.

Если уровень создан заранее в редакторе, то его можно оптимизировать, объединив объекты в один. Если же он создается динамически, то объекты уже не объединишь. Так же нельзя заранее рассчитать освещение для объектов снаружи, только в помещениях (если, конечно, их внутренний интерьер задан жестко, а не собирается, так же, динамически).
Конечно, готовый движок накладывает дополнительные ограничения. Если делать движок самому, пространство для маневра будет больше. Но тем не менее, неочевидных граблей, просто вагон и маленькая тележка. Это я еще физики не касался. В частности, меня в свое время неприятно удивил тот факт, что в большинстве игр, в отличие от остальных объектов, игрок — не подчиняется физике. Это просто капсула, управляемая примитивным скриптом.
Игру-песочницу намного сложней оптимизировать, просто потому, что там меньше мест, где можно схитрить, и «обмануть» пользователя, создав красивую иллюзию. Многие вещи приходится делать «честно».
Проблема в том, как дать другим знать, что мы это сделали? Старый чайник, с холодной водой должен перестать существовать. Иначе это какая-то мультивселенная получается: в одной версии чайник согрели, в другой он остался нетронутым. Можно конечно всем разослать какие-то события. Но если кому-то не требуется знать сразу, по событию, что чайник согрет, то это будет излишним. Например следует различать ситуации:
1) Я услышал, что чайник вскипел — надо пойти налить кипяток в кружку.
2) Домой вернулась жена из магазина, хочет попить чаю. О, чайник уже горячий, тогда можно не греть, сразу наливаем в чашку.
Второй случай существенно отличается от первого, т.к. жене не нужно мониторить состояние чайника, реагировать на изменения оперативно, или запоминать все состояния, это не является её приоритетом. Ей не нужно знать, что чайник вскипел, ровно в тот момент, когда это произошло. И я не шлю ей СМС: «чайник вскипел», а даже если я так сделаю, то она не бросит все, и не прибежит из магазина пить чай. Ей лишь надо узнать его актуальное состояние в тот момент, когда он понадобился, и быть уверенной, что состояние именно актуальное. И таких сущностей и процессов полно, когда своевременно знать о завершении операции надо только тому, кто операцию инициировал, а остальным нужно лишь актуальное состояние сущности в момент обращения. И ситуация, когда каждый находящийся в доме, имеет доступ к чайнику и может его согреть — это тоже естественно. За доступом к нему совершенно не надо следить и ограничивать его (хотя мы и можем это сделать при необходимости). Задач такого рода тоже полно. Это легко и эффективно решается с помощью ссылок и мутабельности.
Можете пояснить в чем я не прав? На минусы мне плевать, но может я чего-то сильно не понимаю в жизни, и мне стоит пересмотреть свои взгляды?
Или может меня просто не поняли? На всякий случай поясню: я не согласен со статьей в пунктах 4, 5 и, частично 3. Поскольку там говорится примерно следующее: «Если %название занятия% увлекаться чрезмерно, могут начаться проблемы в жизни». Так можно сказать вообще про что угодно, никакой существенной специфики относительно именно озвученных явлений (порно, игры) нету. Про порно я не согласен еще и потому, что происходящие при этом процессы мало отличаются от нормального секса, а он, будучи естественным занятием, по идее, не должен вызывать негативных последствий для организма. Это просто эволюционно не должно было так сложиться.
Про соцсети, могу согласиться, что человек склонен испытывать зависть. Но корень проблемы все равно в злоупотреблении, а не в принципиальном использовании соцсетей.
По пунктам 1 и 2 в целом согласен, т.к. проблема с перегруженностью людей информацией, и явлением «всегда на связи», действительно вызвано прогрессом в IT.
В любом случае, хотелось бы конструктивной дискуссии, а не молчаливого порицания.
К сожалению, исследования показали, что просмотр порно вредит работе мозга, изменяя нейронные пути и меняя поведение и личность

Подобно наркотическим веществам, порно наполняет мозг дофамином

Чем в этом плане порно отличается от настоящего секса? От второго дофамина может быть еще больше, потому что ощущения более реальные, а порно — все таки суррогат. Получается секс приводит к депрессии? А может депрессия коррелирует с порно, потому что человек, смотрящий порно несколько раз в день, с большей вероятностью имеет проблемы в отношениях?
Ученые обнаружили, что наш мозг похож на бесконечную игру в Тетрис

Фраза на уровне желтой газеты.
>Пользователи онлайн-игр, которые часами сидят за онлайн-сражениями, имеют более заметные симптомы депрессии, социофобии и интернет-зависимости.
Ну еще бы, а если сидеть сутками, то и с физическим здоровьем проблемы появятся.
Всю статью можно заменить одной фразой: «Во всем надо знать меру». Нет, я не говорю, что опасности совсем нет. В частности, человек, столкнувшийся с проблемами в жизни, может попытаться уйти от них в виртуальность, и в итоге проблемы усугубятся, т.к. он их не решает. Да и чрезмерное увлечение чем-либо может вызвать проблемы в жизни, а от них и депрессия нагрянет. Но компьютерные технологии в этом плане совершенно ничем не выделяются, на фоне любых других областей жизни. Даже наоборот это одно из самых безопасных занятий, из тех, которыми может увлечься человек.
Мне это тоже очень не нравилось, когда изучал его в универе. По задумке, должна быть сильная абстракция, а на практике, приходится держать в голове алгоритм работы машины вывода. То же самое можно сказать и про SQL. Чтобы писать эффективные запросы, надо знать, как именно СУБД этот запрос выполняет. В такие моменты, абстракция не помогает, а только мешает. Мешает понять, как именно выполняется твой код. То же самое и в языках со сборщиком мусора. В определенных моментах, чтобы оптимизировать программу, надо понимать логику его работы. На самом деле эта проблема носит фундаментальный характер, и лежит она далеко за пределами программирования. С такой же проблемой сталкиваются летчики, при взаимодействии с автопилотом. Они подолгу учатся с ним правильно обращаться, изучают его особенности. Поставили автопилот в автомобиль, и там появились те же проблемы. Во всех системах, где присутствует машина, которая претендует на то, что она сама с чем-то разберется, эта самая машина может стать узким местом. И чем больше от этой машины зависит, тем чаще будут проявляться эти узкие места, и тем более узкими они могут быть.
Почему просто не признать очевидную вещь: есть сущности, которые удобней не изменять, а есть те, которые удобно изменять. Следовательно должны быть, как изменяемые, так и неизменяемые типы данных. В идеале, чтобы immutable — вообще было атрибутом, который можно применить к любому типу.
Как сделать человеку хорошо? Сначала сделать плохо, а потом вернуть как было.

Информация

В рейтинге
2 442-й
Зарегистрирован
Активность