Есть еще гибридный. Я люблю писать красивый код (один проект много лет), и мне не особо важно как его используют (продуктовая часть за пределом конкретных фич в моем проекте меня интересует мало) -- главное что используют и пользователи довольны.
Но писать красивый код в стол желания никакого нет.
Текущие кодеки изначально исходят не из максимальной компрессии. А из возможной компрессии с учетом ограничений (сложности и цены) декодера (https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles). Поэтому в таких кодеках используются ассиметричные алгоритмы, такие что декодирование должно быть достаточно простым, легко параллелизуемым и локальным (что бы можно было создать специализированные чипы). Тогда как кодирование может быть в разы более трудоемким.
Но если уж дошло до нехватки памяти, то вполне логично убить весь процесс — ибо ситуация уже нестабильна, и скорее всего любое другое действие тоже приведет к проблемам (или будет периодически приводить пока система балансирует на границе голодания)
К сожалению, тут есть практическая проблема того что nginx использует разделяемую память между воркерами для многих задач. Киляние воркеров может оставить разделяемую память в несогласованном состоянии. Потом, например, приходят люди в рассылку и удивляются, почему у них перестало работать удаление устаревших файлов из кеше при превышении лимита или времени (реальная ситуация).
Сам nginx вполне себе справляется с ситуацией нехватки памяти и корректно её обрабатывает.
В AlphaGo все что сделали — это применили нейросеть для предсказания насколько хороша текущая позиция, вместо делания rollout до конца игры (сама нейросеть обучается на реальных проигранных партиях, конечно).
На первый взгляд звучит достаточно просто. Однако тут встает вопрос как же обучить эту нейросеть оценки (особенно на первых этапах), если фидбек будет получен только в конце игры (за время игры порядка 100 ходов, как понять какие из них были хорошими, а какие нет. Была ли сделана ошибка вначале, или в самом конце, например).
Увы, нет. Существует исследование (не могу найти ссылку), где в игре вроде марио, фигурку персонажа и блоки с наградой/ловушками заменяли на блоки из случайных цветных пикселей. Люди-игроки методом проб и ошибок довольно быстро научились играть в такую игру. Не зная какой значок означает ловушку, а какой награду.
Казалось бы, это показывает нашу человеческую способность быстро обучаться. Но стоило изменить механику игры, например расположив пол вертикально, а сила тяжести чтобы действовала не вверх, а вбок — и люди игроки резко затормаживались. А некоторые так и не смогли научиться играть (не смогли понять что происходит). Не смотря на весь свой интеллект.
В то же время нейросеть с помощью reinforcement learning алгоритма затратила одинаковое время на обучение всем разновидностям игры.
>P.S. отвечая на вопрос — теоретических ограничений на обучение современных нейросетей, в общем-то, и нет никаких. По крайней мере, они неизвестны. Это скорее практика, народ делится удачными решениями друг с другом.
вопрос был скорее про теоретические ограничения текущих моделей RL Т.е. какие задачи (и какого уровня сложности) можно уже решать при их помощи, а какие все еще нет. Какие у них есть ограничения и недостатки (например есть ли аналог ADVERSARIAL EXAMPLES как в случае CNN) Понятное дело что ограничения вообще достаточно сложно представить.
Отдельный вопрос разве AlphaZero это не реально прорыв? И кстати в чем именно, Какой фактор оказался наиболее важным?
Аналогичный вопрос про Deepmind capture the flag Это прорыв, или реально просто огромный перебор параметров (на что намекает использование эволюционных алгоритмов)?
>В Reinforcement Learning, пожалуй, больше математики по сравнению с другими областями Deep Learning, да еще со статистическим и вероятностным уклоном. И тянущие многие термины с 70-х годов.
да, именно поэтому я открываю статьи по теме и почти сразу их закрываю, потому что читается с огромным трудом.
>Я имел ввиду, собственно, js_set — управлять переменными конфига, используя блокирующие операции на файлах, базе или сети, нельзя.
тут проблема скорее не в njs, а в том что nginx не умеет асинхронно ждать пока переменная вычислится. Модули тупо зовут ngx_http_complex_value() для вычисление значения переменной (пример), и ожидают что она либо вычислится либо нет. Если сюда добавить некий NGX_AGAIN это все сломает в куче мест.
>Кстати, у этого js-модуля есть общая память хотя бы для процесса (а ещё лучше для всех воркеров)?
На данный момент нет. Доступ к общей памяти процесса не предполагается. Тогда как мы думаем над тем как и в каком виде добавить функционал аналогичный ngxshareddict (глобальный словарь в разделяемой памяти доступный всем воркерам).
>Работа с файлами, базами, сетью на уровне конфига не предполагается.
Тут вы ошибаетесь. Работа с файлами уже есть (правда на данный момент блокирующая).
Чего в perl модуле нет так это асинхронного выполения кода, тогда как njs это уже есть в виде таймеров и асинхронных подзапросов (пример).
>Работа с файлами, базами, сетью на уровне конфига не предполагается.
Причем тут конфиг? Модель выполнения несколько другая. Вам доступно несколько хуков для различных фаз выполнения запроса где вы можете написать произвольный код который будет выполнятся для каждого запроса. Вот практический пример использования для openId Connect.
Как человек в теме, не могли бы кинуть ссылки на источники по теоретическим ограничениям возможностей современных нейронных сетей? В данный момент я постепенно читаю статьи из подборки, пока в основном по сверточным NN и обучению с учителем, к другим более сложным архитектурам пока не подбирался. Но меня скорее интересуют не практическое применение (оно уже сейчас может решать прикладные задачи во многих областях), а теоретические ограничения подобного подхода.
В частности интересует источник для утверждения
Знаете в какой размерности работают современные нейросетевые ИИ? State = 5..10, actions = 2..4. Это для простых задач вроде балансировки маятника. А state = 40 и actions = 17 уже считаются задачами высокой размерности
Что вы именно под jit понимаете?
Если компиляцию в байт-код по типу CPython то да.
Если компиляцию в нативный код процессора то нет. JIT малоактуален, если у вас мало кода, или ваш код высокоуровневый (дергаете методы окружения, что как раз типично для кода на стороне прокси) потому что никакого преимущества вы от него не получите. Если же у вас, например, много математических расчетов то JIT будет кстати, но для этого есть другие инструменты.
In terms of performance, the epoll design has a weakness; it does not support multiple updates on the interest set in a single system call. When you have 100 file descriptors to update their status in the interest set, you have to make 100 epoll_ctl() calls.
Another issue, which is more important in my opinion, is the limited scope of epoll. As it was designed to improve the performance of select()/epoll(), but for nothing more, epoll only works with file descriptors. What is wrong with this?
It is often quoted that “In Unix, everything is a file”. It is mostly true, but not always. For example, timers are not files. Signals are not files. Semaphores are not files. Processes are not files. (In Linux,) Network devices are not files. There are many things that are not files in UNIX-like operating systems. You cannot use select()/poll()/epoll for event multiplexing of those “things”. Typical network servers manage various types of resources, in addition to sockets. You would probably want monitor them with a single, unified interface, but you cannot. To work around this problem, Linux supports many supplementary system calls, such as signalfd(), eventfd(), and timerfd_create(), which transforms non-file resources to file descriptors, so that you can multiplex them with epoll(). But this does not look quite elegant… do you really want a dedicated system call for every type of resource?
In kqueue, the versatile struct kevent structure supports various non-file events. For example, your application can get a notification when a child process exits (with filter = EVFILT_PROC, ident = pid, and fflags = NOTE_EXIT). Even if some resources or event types are not supported by the current kernel version, those are extended in a future kernel version, without any change in the API.
Да, не обратил внимание. ИМХО с точки зрения переводчика стоило бы актуализировать некоторую информацию (для IT 6 лет это огромный срок). Тот же klee был одно время заброшен полностью. Сейчас пытаются проект возродить (судя по офиц. сайту), однако тот факт что он до сих пор собирается с llvm 3.4 несколько удручает. Опять таки, стоило бы добавить информацию про проекты упомянутые мною выше.
Удивлен что
1) не было упомянуто семейство *sanitizer (https://github.com/google/sanitizers), clang.llvm.org/docs/UndefinedBehaviorSanitizer.html Уже несколько лет регулярно пользуемся ими на дебажных билдах при прогоне тестов. Отловили в тестах приличное количество проблем которые или себя никак не проявляли или проявляли себя спорадически.
2) до сих пор кто-то использует супер медленный и тормозной valgrind. Что-то более или менее интенсивно потребляющее CPU или память под ним запустить практически невозможно. Asan же дает всего 2x замедление и ~2x потребление памяти. Еще одна проблема valgrind в том что множество юзкейсов связанных с таймингом на нем не воспроизводятся.
Считать фруктозу ядом было бы конечно большой натяжкой, но в больших кол-вах она действительно оказывает негативное воздействие на печень. Основная причина в том что фруктоза в отличии от глюкозы метаболизируется в обход основного пути метаболизма глюкозы. В основном пути есть обратная связь с энергитическим уровнем клетки (метаболизм идет активнее при потребности в энергии), тогда как в пути по которому метаболизируется фруктоза подобный механизм отсуствует. Избычное кол-во продуктов метаболизма фруктозы, в частности ацетил-CoA, естественным образом запускают синтез жиров, как результат 'неалкогольное ожирение печени', нарушение в работе печени приводит к целой цепочке последствий для организма, в том числе диабет 2 типа.
Подробнее, на уровне биохимии тут http://www.filedropper.com/biochemistry8thed-jeremymbergetalwhfreemanandcompany2015
CHAPTER 16
Glycolysis and Gluconeogenesis
Excessive fructose consumption can lead to pathological conditions
Fructose, a commonly used sweetener, is a component of sucrose and high fructose corn syrup (which con-
tains approximately 55% fructose and 45% glucose). Epidemiological as well as clinical studies have linked excessive fructose consumption to fatty liver, insulin insensitivity, and obesity. These conditions may eventually result in type 2 diabetes (Chapter 27). Studies have shown that these disorders are not necessarily the result of simple excess energy consumption, but rather how fructose is processed by the liver.
Есть люди которые пинают кожаную флейту и есть люди которые создают новые технологии
…
Я имею ввиду что люди, чей труд может выполнять практически любой другой человек, т.к. которые ничего уникального не делают. Управлять комбайном можно научить практически любого достаточно быстро, а вот программировать или делать двигатели — нет.
Давайте, не будем сами себе льстить. Конечно, существуют выдающиеся программисты и computer scientists которые радикально изменили мир за последние четверь века, но это единицы. Остальные это, по большому счету, более или менее профессиональные ремесленники, в массе своей пишущие очередное приложение для доставки пиццы. Сказать что они создают новые технологии или делают что то уникальное будет большой натяжкой.
ИМХО, нам надо признать что текущее особое положение айтишников это в значительной степени результат внешних к нам факторов, таких как спрос на рынке труда превышающий предложение, а это в свою очередь следствие текущих экономических реалий в виде предельно низких процентных ставок в развитом мире и готовность инвесторов вкладывать в IT (кстати этот тренд уже развернулся и пошел вниз), а так же непопулярность профессии инженера на западе в предыдущие десятилетия что создало нехватку кадров. Как следствие зарплаты в отрасли в разы превышают зарплаты других профессий.
Предыдущему поколению инженеров, ученых повезло гораздо меньше, но не потому что они были менее талантливы.
Я тут вот недавно смотрел для интереса экспедицию по Антарктиде — $70k на человека. Так что далеко не всем из TOP 1% доступно такое удовольствие.
честно говоря не знаю где вы берете такие дикие цены). коллега с работы, путешествовал через Аргентину в Антарктиду, за ~ 10к$. я примерно за эту же сумму добрался в Новую Зеландию через Австралию и обратно, живя в отелях и ни в чем себе не отказывая. Я это к тому что можно путешествовать по всему миру, самым удивительным местам, не имея 1кк$ дохода, просто не надо жить в бунгало за 4к$ в сутки). Потому что ценны они не дорогими отелями, очевидно, а красотой природы и переменой обстановки. С этой точки зрение, жить в самой обычной хижине местного жителя, под пальмой в гамаке, является гораздо более запоминающимся опытом. Мне вообще сложно себе представить что может стоит 4к$ за сутки кроме статусного потребления (рациональным это точно назвать нельзя).
Вы неявно предполагаете несколько достаточно спорных утверждений:
Есть люди которые пинают кожаную флейту и есть люди которые создают новые технологии — они не должны иметь не то что равное, но даже сравнимое состояние.
классическое проявление just-world cognitive bias. Ну, т.е. я согласен, что определенно существует большое кол-во людей которые бедные потому что они лентяи, но статистически это кажется совершенно маловероятным что в США 40% лентяев (сюда например попадают фермеры и часть учителей).
Стоит ли рвать естественные отверстия ради прибавки всего в 2 раза? Ведь изменение уровня жизни в этом случае чисто количественное.
…
Ведь каждый шаг наверх для вас не просто небольшое улучшение, а качественно иной уровень жизни.
Есть достаточно много исследований, например упомянутых тут, которые говорят о том что после некоторого порога (в статье упомянута сумма 200к$), каждый следующий доллар сверху перестает влиять на well being. Деньги лишь один из факторов, хотя и один из основных.
Никаких качественных скачков, где стимул что-то делать?
После того как как вопрос денег решен, или другими словами эта потребность достигла насыщения, обычно людей начинают волновать совершенно другие темы, такие как самореализация и работа над чем то значимым сообща с другими людьми.
Если начать «уравнивать», то во первых — многие вещи станут дороже, потому что платить остальным 99% надо больше, а во вторых — у вас у самих станет сильно меньше денег.
Это достаточно умозрительное утверждение, неявно предполагает игру с нулевой суммой.
Смотря что понимать под «уравнивать». Если просто «взять и поделить», то конечно ничего хорошего не выйдет. Второй вариант это, например, прогрессивный налог, при этом все поступления по этой статье направлять напрямую на повышение доступности высшего образования.
Важна не сама сумма в некоторых попугаях, а ее покупательная способность (иллюстрация на тему). Да, возможно, сама сумма будет меньше, но не будет ли производительность труда в стране и соотвественно ВВП выше если в ней население будет более высокообразованным? Производительность труда выше — покупательная способность (кол-во доступных товаров на 1 попугая) выше. Т.е. тут, на мой взгляд, надо смотреть систему в целом с учетом обратной связи.
Текущее положение дел гораздо лучше.
Во вторых, на мой взгляд, текущая ситуация должна волновать и этот 1%, потому что такой разрыв в доходах это рецепт для революции в перспективе и система может пойти в разнос. Например, в основном люди с низкими доходами поддерживают Трампа.
На деле — жизнь только начинается как раз в этом самом TOP 1%, это всего лишь начиная от $250K в год (для человека), т.е. примерно senior software engineer. И на этом уровне вы очень много чего еще не можете себе позволить.
И на последок, хотелось бы поинтересоваться, что на ваш взгляд недоступно человеку с доходом в 250к$, но доступно с 1кк$?
>потому что его отсутствие — это не справедливо
с этим я абсолютно согласен, wealth gap должен быть, никакой уравниловки. в идеале, ИМХО, он должен быть сопоставим (быть пропрорциональным) с прикладываемыми усилиями человеком, его достижениями и пользе которую он несет обществу в целом.
НО, что совсем не кажется справедливым так это
https://upload.wikimedia.org/wikipedia/commons/1/1b/Wealth_Inequality_in_America_by_politizane.webm
Есть еще гибридный. Я люблю писать красивый код (один проект много лет), и мне не особо важно как его используют (продуктовая часть за пределом конкретных фич в моем проекте меня интересует мало) -- главное что используют и пользователи довольны.
Но писать красивый код в стол желания никакого нет.
Отдельно, часть команды full time занимается разработкой HTTP3.
Забыли упомянуть еще один проект bellard.org/quickjs
Текущие кодеки изначально исходят не из максимальной компрессии. А из возможной компрессии с учетом ограничений (сложности и цены) декодера (https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles). Поэтому в таких кодеках используются ассиметричные алгоритмы, такие что декодирование должно быть достаточно простым, легко параллелизуемым и локальным (что бы можно было создать специализированные чипы). Тогда как кодирование может быть в разы более трудоемким.
К сожалению, тут есть практическая проблема того что nginx использует разделяемую память между воркерами для многих задач. Киляние воркеров может оставить разделяемую память в несогласованном состоянии. Потом, например, приходят люди в рассылку и удивляются, почему у них перестало работать удаление устаревших файлов из кеше при превышении лимита или времени (реальная ситуация).
Сам nginx вполне себе справляется с ситуацией нехватки памяти и корректно её обрабатывает.
На первый взгляд звучит достаточно просто. Однако тут встает вопрос как же обучить эту нейросеть оценки (особенно на первых этапах), если фидбек будет получен только в конце игры (за время игры порядка 100 ходов, как понять какие из них были хорошими, а какие нет. Была ли сделана ошибка вначале, или в самом конце, например).
Вероятно имелась ввиду эта статья
вопрос был скорее про теоретические ограничения текущих моделей RL Т.е. какие задачи (и какого уровня сложности) можно уже решать при их помощи, а какие все еще нет. Какие у них есть ограничения и недостатки (например есть ли аналог ADVERSARIAL EXAMPLES как в случае CNN) Понятное дело что ограничения вообще достаточно сложно представить.
Отдельный вопрос разве AlphaZero это не реально прорыв? И кстати в чем именно, Какой фактор оказался наиболее важным?
Аналогичный вопрос про Deepmind capture the flag Это прорыв, или реально просто огромный перебор параметров (на что намекает использование эволюционных алгоритмов)?
>В Reinforcement Learning, пожалуй, больше математики по сравнению с другими областями Deep Learning, да еще со статистическим и вероятностным уклоном. И тянущие многие термины с 70-х годов.
да, именно поэтому я открываю статьи по теме и почти сразу их закрываю, потому что читается с огромным трудом.
тут проблема скорее не в njs, а в том что nginx не умеет асинхронно ждать пока переменная вычислится. Модули тупо зовут ngx_http_complex_value() для вычисление значения переменной (пример), и ожидают что она либо вычислится либо нет. Если сюда добавить некий NGX_AGAIN это все сломает в куче мест.
На данный момент нет. Доступ к общей памяти процесса не предполагается. Тогда как мы думаем над тем как и в каком виде добавить функционал аналогичный ngxshareddict (глобальный словарь в разделяемой памяти доступный всем воркерам).
>Работа с файлами, базами, сетью на уровне конфига не предполагается.
Тут вы ошибаетесь. Работа с файлами уже есть (правда на данный момент блокирующая).
Чего в perl модуле нет так это асинхронного выполения кода, тогда как njs это уже есть в виде таймеров и асинхронных подзапросов (пример).
>Работа с файлами, базами, сетью на уровне конфига не предполагается.
Причем тут конфиг? Модель выполнения несколько другая. Вам доступно несколько хуков для различных фаз выполнения запроса где вы можете написать произвольный код который будет выполнятся для каждого запроса. Вот практический пример использования для openId Connect.
В частности интересует источник для утверждения
Если компиляцию в байт-код по типу CPython то да.
Если компиляцию в нативный код процессора то нет. JIT малоактуален, если у вас мало кода, или ваш код высокоуровневый (дергаете методы окружения, что как раз типично для кода на стороне прокси) потому что никакого преимущества вы от него не получите. Если же у вас, например, много математических расчетов то JIT будет кстати, но для этого есть другие инструменты.
people.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs-kqueue.html
idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12
news.ycombinator.com/item?id=3028687
1) не было упомянуто семейство *sanitizer (https://github.com/google/sanitizers), clang.llvm.org/docs/UndefinedBehaviorSanitizer.html Уже несколько лет регулярно пользуемся ими на дебажных билдах при прогоне тестов. Отловили в тестах приличное количество проблем которые или себя никак не проявляли или проявляли себя спорадически.
2) до сих пор кто-то использует супер медленный и тормозной valgrind. Что-то более или менее интенсивно потребляющее CPU или память под ним запустить практически невозможно. Asan же дает всего 2x замедление и ~2x потребление памяти. Еще одна проблема valgrind в том что множество юзкейсов связанных с таймингом на нем не воспроизводятся.
Подробнее, на уровне биохимии тут http://www.filedropper.com/biochemistry8thed-jeremymbergetalwhfreemanandcompany2015
CHAPTER 16
Glycolysis and Gluconeogenesis
Excessive fructose consumption can lead to pathological conditions
Fructose, a commonly used sweetener, is a component of sucrose and high fructose corn syrup (which con-
tains approximately 55% fructose and 45% glucose). Epidemiological as well as clinical studies have linked excessive fructose consumption to fatty liver, insulin insensitivity, and obesity. These conditions may eventually result in type 2 diabetes (Chapter 27). Studies have shown that these disorders are not necessarily the result of simple excess energy consumption, but rather how fructose is processed by the liver.
Давайте, не будем сами себе льстить. Конечно, существуют выдающиеся программисты и computer scientists которые радикально изменили мир за последние четверь века, но это единицы. Остальные это, по большому счету, более или менее профессиональные ремесленники, в массе своей пишущие очередное приложение для доставки пиццы. Сказать что они создают новые технологии или делают что то уникальное будет большой натяжкой.
ИМХО, нам надо признать что текущее особое положение айтишников это в значительной степени результат внешних к нам факторов, таких как спрос на рынке труда превышающий предложение, а это в свою очередь следствие текущих экономических реалий в виде предельно низких процентных ставок в развитом мире и готовность инвесторов вкладывать в IT (кстати этот тренд уже развернулся и пошел вниз), а так же непопулярность профессии инженера на западе в предыдущие десятилетия что создало нехватку кадров. Как следствие зарплаты в отрасли в разы превышают зарплаты других профессий.
Предыдущему поколению инженеров, ученых повезло гораздо меньше, но не потому что они были менее талантливы.
честно говоря не знаю где вы берете такие дикие цены). коллега с работы, путешествовал через Аргентину в Антарктиду, за ~ 10к$. я примерно за эту же сумму добрался в Новую Зеландию через Австралию и обратно, живя в отелях и ни в чем себе не отказывая. Я это к тому что можно путешествовать по всему миру, самым удивительным местам, не имея 1кк$ дохода, просто не надо жить в бунгало за 4к$ в сутки). Потому что ценны они не дорогими отелями, очевидно, а красотой природы и переменой обстановки. С этой точки зрение, жить в самой обычной хижине местного жителя, под пальмой в гамаке, является гораздо более запоминающимся опытом. Мне вообще сложно себе представить что может стоит 4к$ за сутки кроме статусного потребления (рациональным это точно назвать нельзя).
Вы неявно предполагаете несколько достаточно спорных утверждений:
классическое проявление just-world cognitive bias. Ну, т.е. я согласен, что определенно существует большое кол-во людей которые бедные потому что они лентяи, но статистически это кажется совершенно маловероятным что в США 40% лентяев (сюда например попадают фермеры и часть учителей).
Есть достаточно много исследований, например упомянутых тут, которые говорят о том что после некоторого порога (в статье упомянута сумма 200к$), каждый следующий доллар сверху перестает влиять на well being. Деньги лишь один из факторов, хотя и один из основных.
После того как как вопрос денег решен, или другими словами эта потребность достигла насыщения, обычно людей начинают волновать совершенно другие темы, такие как самореализация и работа над чем то значимым сообща с другими людьми.
Это достаточно умозрительное утверждение, неявно предполагает игру с нулевой суммой.
Смотря что понимать под «уравнивать». Если просто «взять и поделить», то конечно ничего хорошего не выйдет. Второй вариант это, например, прогрессивный налог, при этом все поступления по этой статье направлять напрямую на повышение доступности высшего образования.
Важна не сама сумма в некоторых попугаях, а ее покупательная способность (иллюстрация на тему). Да, возможно, сама сумма будет меньше, но не будет ли производительность труда в стране и соотвественно ВВП выше если в ней население будет более высокообразованным? Производительность труда выше — покупательная способность (кол-во доступных товаров на 1 попугая) выше. Т.е. тут, на мой взгляд, надо смотреть систему в целом с учетом обратной связи.
Во вторых, на мой взгляд, текущая ситуация должна волновать и этот 1%, потому что такой разрыв в доходах это рецепт для революции в перспективе и система может пойти в разнос. Например, в основном люди с низкими доходами поддерживают Трампа.
И на последок, хотелось бы поинтересоваться, что на ваш взгляд недоступно человеку с доходом в 250к$, но доступно с 1кк$?
с этим я абсолютно согласен, wealth gap должен быть, никакой уравниловки. в идеале, ИМХО, он должен быть сопоставим (быть пропрорциональным) с прикладываемыми усилиями человеком, его достижениями и пользе которую он несет обществу в целом.
НО, что совсем не кажется справедливым так это
https://upload.wikimedia.org/wikipedia/commons/1/1b/Wealth_Inequality_in_America_by_politizane.webm