Подготовка к установке

Если вы только первый раз начинаете пользоваться консолью, вам нужно для начала задать пароль администратора

~$ passwd

Далее, вам нужно отключить режим readonly, для того чтобы иметь возможность устанавливать пакеты

~$ sudo steamos-readonly disable

А далее, устанавливаем нужные нам пакеты

~$ sudo pacman -S libxcb xcb-util-cursor opengl-driver iptables

Далее было предложено установить Xwayland, но этого делать категорически не нужно, потому что у Valve присутствует своя версия которая сочетает как запуск Wayland приложение так и X11 без танцев с бубнами.

Скачиваем бинарный файл и начинаем его устанавливать

Скачать: https://github.com/amnezia-vpn/amnezia-client/releases/download/4.8.10.0/AmneziaVPN_4.8.10.0_linux_x64.tar.zip

1. Извлекаем AmneziaVPN_4.8.10.0_linux_x64.tar.zip сначала просто из zip файла, а потом просто командой tar -xf AmneziaVPN_Linux_Installer.tar
2. Далее мы получаем AmneziaVPN_Linux_Installer.bin, с которым нам и осталось отработать
3. Далее прописываем права на исполнение файла chmod 755 AmneziaVPN_Linux_Installer.bin
4. Ну и на последнее, запускаем файл и устанавливаем приложение, которое будет работать как обычная программа: QT_QPA_PLATFORM=xcb ./AmneziaVPN_Linux_Installer.bin

Всем приятное игры, если будут вопрос, исправим статью, добавим дополнительных комментариев!

Живя в России я всегда думал, какой ужас, какой кошмар что всю власть забрали по сути те, кто был авторитетом в 90-х, ну и какой-то процент просто людей, которые туда попали и тоже неплохо поживились.

Но вдруг, тут наступает война, да, именно война, война между нациями, двумя державами, Россией и США, можете сколь угодно говорить что “бомбят хохлов” (простите, украинцы), но это не их война, и время уже это показало.

На войне убивают людей, людей жалко , я вообще про мирных промолчу, причем мирных убивают с двух сторон, а также война двигатель прогресса, и что прикажете думать? Доллар надоел, США везде лезет, недавно было собрание по поводу регулирования криптовалюты, может еще ядерную Кима отрегулируете?

Я ни в коем случае не поддерживаю политику России и США, Украина в данном случае лишь пешка, ею играют два реально сильных игрока, и она, как бы грубо или смешно это не звучало — ради власти и денег. В красном случае больше ради власти, в синем, больше ради денег, кажется не будет победы или проигрыши, выведут мистер Пу, просто выведет войска или, что он там любит там делать, и типа ничего и не было.

Все настолько плохо, что люди стоящие рядом с мистером Пу, также врут ему, воруют и вообще неплохо доживают те дни, пока еще можно чем-то насладиться.

Живя в стране, которая когда-то сходила в состав СССР, я осознал много вечей, да, Россия действительно имеет сильных ученых, айтишников, систему образования, развалившуюся на половину правда, но имеет. Вижу глупость стран, думающим, что из России приезжают богатые люди, меня много раз пытались нагреть, но мы не об этом (нагревали, если интересно).

Мишустин со своими «давайте делать свои системы», может успешно идти в сами знаете какое место, вместо того, чтобы создать пространство как Маск, типа OpenAI, арендовать здание, платить хорошие бабки айтишникам просто тупо для того чтобы они "что-то делали" и придумывали, мы покупаем яхты, отправляет детей в Лондоны, «потому что я не хочу чтобы мои дети жили также как когда-то жил я», да пошел ты в пизду, проблема «плохо» заработанных денег в «плохом их инвестировании». И вот весь мир «охуевать» от chatGPT, от его движка в целом и так далее, я уже молчу про другие разработки данной компании. Выложи свои деньги продай ссаную яхту ублюдок, если надеюсь, ее еще не конфисковали. У нас нет частной космонавтики именно из-за таких как вы.

Я просто набросал мыслей, который крутятся в голове каждый день, будет продолжение, и не одно. Плохого дня.

Эта статья изначально была размещена на dYdX, которая в свою очередь была размещена на The Pomp Letter.

С созданием базового блока Bitcoin в мире появилось первое по-настоящему децентрализованное финансовое приложение. Bitcoin позволил любому человеку в мире хранить богатство без необходимости в централизованной организации. Это богатство можно было взять и отправить в любую точку мира, единственным требованием было подключение к Интернету. По мере того, как сеть Bitcoin росла с увеличением количества владельцев и передаваемой ценности, разработчики начали искать способы создания более сложных финансовых операций. Это противоречило тому, как сообщество Bitcoin относилось к компромиссам между безопасностью и выгодными финансовыми инструментами, что создавало нераскрытые возможности для создания блокчейна, которая могла бы способствовать заключению более сложных финансовых контрактов.

Когда был запущен Ethereum, он стремился стать глобальным компьютером, способным обеспечивать работу произвольного количества приложений с помощью "умных" контрактов. Мания ICO 2017 года отразила это видение, но Ethereum как платформа в конечном итоге оставила желать лучшего для большинства приложений. Среди всего этого шума, стало все более очевидным, что Ethereum является плодородной почвой для экспериментов в финансовых приложениях. Ethereum резко сократил расходы, связанные с различными финансовыми операциями, включая формирование капитала, выпуск активов (отсюда и пузырь ICO), обмен активами, администрирование займов, управление залоговым обеспечением и многое другое. После того, как в 2017 году завалы были расчищены, сообщество Ethereum начало активно развиваться и получило название "DeFi" (сокращение от "децентрализованное финансирование").

DeFi имел огромные перспективы с учетом того, насколько неэффективным является традиционное финансирование, а также с учетом того, насколько хорошо его цели согласуются с основной идеей крипто-сообщества. Умные контракты Ethereum позволяли управлять деньгами программно, без необходимости центральной инстанции, что, в свою очередь, создавало много преимуществ с точки зрения эффективности. Аналогичным образом, приложения DeFi были открыты и не требовали разрешений. Как и Bitcoin, любой мог получить к ним доступ, все, что ему было нужно, это подключение к Интернету.

Сравните это с традиционной финансовой системой, и вы легко поймете, насколько более привлекателен DeFi. В традиционном мире финансовые приложения труднодоступны, сложны в использовании, а главное, дорогостоящи.

Ранние признаки соответствия продукта рынку
Вскоре после того, как сообщество Ethereum сплотилось вокруг DeFi и выделило инженерные ресурсы на создание инфраструктуры, появились первые признаки движения. В эти первые дни наиболее многообещающими разработками были примитивы DeFi: строительные блоки, которые можно было строить друг на друге для создания более эффектных приложений. Компетентность этих примитивов помогает создавать сильные сетевые эффекты, в которых ценность продуктов и услуг растет по мере увеличения числа пользователей DeFi.

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

Стаблконы действительно начали расти, когда на рынке появились новые примитивы. Возможность обмена стаблкойнов через децентрализованные биржи, такие как dYdX, 0x и Kyber, или возможность занимать и выдавать стаблкоины через такие платформы, как dYdX и Compound, сделала стаблконы намного более мощными. Пользователи могут оставаться на связи для многих своих банковских потребностей.

Мы ясно видим, что эмиссия стаблекойн действительно взлетела в конце 2018 года, как раз в то время, когда многие из первых примитивов DeFi появились на рынке. Сумма долларов в USDT, выделенная в Ethereum, выросла до более чем 6 миллиардов долларов США практически с 0. USDC также наблюдал астрономический рост, увеличившись до более чем 1 миллиарда долларов США в течение менее чем двух лет.

Децентрализованный обмен был еще одним примитивом, который взлетел в 2019 году. При децентрализованных биржах "умные" контракты обрабатывают все части биржевого процесса — они проверяют, что каждый владелец владеет активами, что он одобрил передачу, и, как только они удовлетворяют требованиям, контракты атомизируют обмен активами между двумя контрагентами. Опять же, это кажется простым, но традиционный процесс обмена может быть дорогостоящим и подвергает пользователей большому риску со стороны контрагента. Как мы видели снова и снова, обмены могут идти вниз с криптой всех своих клиентов.

Автоматизированные маркет-мейкеры продвинули концепцию децентрализованной биржи на шаг вперед, устранив необходимость в централизованном маркет-мейкере для цитирования обеих сторон книги. Есть много причин, по которым AMM стали прорывной моделью для децентрализованных бирж. Во-первых, для токен-проектов привлечение маркет-мейкеров является чрезвычайно дорогостоящим – сделки очень односторонние и концентрируют слишком большое влияние в руках маркет-мейкера. Во-вторых, для маркет-мейкеров предоставление ликвидности на децентрализованных биржах является дорогостоящим, учитывая латентность и стоимость внутрицепочечных сделок. С помощью AMM проекты могут иметь ликвидность с первого дня, что значительно облегчает загрузку сообществ и сетей.

Последний примитив DeFi, о котором стоит упомянуть, это заимствование и кредитование рынков, а точнее, заимствование и кредитование непосредственно из "умного" контракта. Эти системы позволяют любому, у кого есть простаивающие активы, вложить их в общий кредитный пул, а любому, кто хочет занять активы, снять их из этого пула в обмен на проценты. Девелоперы смогли создать мощные продукты, сформировав топ-рынок этих кредитных рынков. Например, кредитные рынки dYdX поддерживают глобальную систему маржинальной торговли — способность трейдеров зарабатывать проценты помогает приносить больше ликвидности в платформу.

Куда идет DeFi?

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

Недавний бум добычи ликвидности на самом деле представляет собой интересную игру на генерации доходности. Хотя большая часть доходности зависит от инфляции, а не от реальных процентов или денежных потоков, она предлагается в то время, когда большинство традиционных банков предлагают ставки по сбережениям, близкие к 0%. В связи с этим мы наблюдаем огромный приток капитала в экосистему. Даже если это краткосрочная перспектива, этот новый капитал помогает стимулировать эксперименты до тех пор, пока не будет найдено что-то ценное. Точно так же, эти протоколы имеют внутреннюю ценность через свои денежные потоки. Так что даже если доходность со временем обвалится, у них все равно есть пол, который намного больше, чем все, что предлагается в традиционной банковской системе.

Децентрализованная биржа — это также вертикаль, которая будет продолжать расти в краткосрочной и среднесрочной перспективе, и мы ожидаем, что в ближайшие несколько лет она превзойдет большинство централизованных бирж. Уже сегодня было много дней, в течение которых торговля на Uniswap превосходила торговлю на Gemini, Kraken и даже на Coinbase. Такие события, как добыча ликвидности, повысят ликвидность, предлагаемую на децентрализованных биржах, до такой степени, что трейдеры смогут обмениваться по более дешевому курсу, чем на централизованных биржах, и без KYC. Кроме того, децентрализованные биржи все еще находятся в режиме v1.0. На dYdX мы приложили все усилия, чтобы построить маржинальную торговлю и самый первый синтетический BTC бессрочный своп, все в цепочке, так что пользователям никогда не придется отказываться от опеки над своими средствами. В ближайшие несколько месяцев мы также запустим наше решение Layer 2 со Starkware, которое значительно сократит расходы, увеличит пропускную способность и позволит торговать большим количеством торговых пар, а также предоставит возможность кросс-маржинальной торговли на наших вечных рынках.

Еще одной областью, в которой децентрализованное финансирование подрывает деятельность своих централизованных контрагентов, является кредитование. Кредитование по цепочке всегда критиковалось за неспособность администрировать кредиты с недостаточным залоговым обеспечением из-за отсутствия средств правовой защиты и идентичности, но вскоре ситуация может измениться в связи с новым порядком кредитования, разработанным Aave для делегирования кредитов. С помощью своей системы владельцы токенов смогут ставить свои активы под кредитную репутацию другого адреса (привязанного к пользователю), что позволит этому адресу заимствовать средства без избыточного обеспечения кредита. Если этот пользователь не погасит кредит, то именно его стейкер [Прим. И: держатель] будет наказан, то есть держатели токенов будут мотивированы действовать таким образом, чтобы не навредить им, фактически помогая гарантировать, что только кредитоспособные заемщики смогут брать беззалоговые кредиты.

Наконец, в экосистеме DeFi появились собственные предложения страхования, позволяющие пользователям приобрести защиту от рисков, связанных с "умными" контрактами. Одним из самых больших барьеров на пути внедрения DeFi в первые дни существования компании было отсутствие страховки. Ни один традиционный страховщик не входил в пространство, поэтому участники экосистемы строили свои собственные решения. С помощью таких протоколов, как Nexus Mutual и Opyn, пользователи DeFi могут защитить свои депозиты без необходимости в традиционном банке или учреждении.

Все инновации, происходящие в экосистеме DeFi, подтверждают тот факт, что децентрализованное финансирование может создавать финансовые приложения, которые более желательны, чем те, которые существуют в традиционном мире. Мы уже видим, как некоторые проекты DeFi обгоняют части централизованной криптоэкономики, и вскоре эта деятельность начнет обгонять традиционный мир. Никогда еще не было такой потребности в финансовой системе, которая была бы более справедливой, открытой и эффективной. В dYdX мы не могли придумать более захватывающей миссии, к которой можно было бы стремиться.

Ларри Пейдж и Сергей Брин
— Основатели Alphabet

Письмо опубликовано 03 Декабря 2019 года. Источник.

Наше самое первое письмо основателей в 2004 году началось с S-1:

Google — это не типичная компания. Мы не намерены ею становиться. На протяжении всей эволюции Google, как частной компании, мы управляли Google по-разному. Мы также подчеркиваем, что атмосфера творчества и вызовов помогает нам обеспечивать объективный, точный и свободный доступ к информации для тех, кто на нас рассчитывает во всем мире.

Мы считаем, что эти основные постулаты остаются в силе и по сей день. Компания не является традиционной и продолжает делать амбициозные ставки на новые технологии, особенно на структуру нашей компании Alphabet. Креативность и вызовы остаются как никогда актуальными, если не более актуальными, и все чаще применяются в различных областях, таких как машиностроение, энергоэффективность и транспорт. Тем не менее, основной сервис Google - предоставление непредвзятого, точного и свободного доступа к информации - остается в центре внимания компании.

Однако с тех пор, как мы написали первое письмо основателей, компания развивалась и становилась зрелой. В Google есть все популярные потребительские сервисы, которые последовали за Поиском, такие как Карты, Фотографии и YouTube; глобальная экосистема устройств на базе наших платформ Android и Chrome, включая наши собственные устройства Google; Google Cloud, включая GCP и G Suite; и конечно же основа основных технологий для обучения машин, облачных вычислений и разработки ПО. Это честь, что миллиарды людей решили сделать эти продукты центральным элементом своей жизни - это доверие и ответственность, над которыми Google всегда будет работать.

И в организационном плане в 2015 году компания превратилась в Alphabet. Как мы и сказали в письме-основании Alphabet в 2015 году:

Alphabet — это процветание бизнеса благодаря сильным лидерам и независимости.

С тех пор как мы написали это, сотни жителей Финикса в настоящее время ездят на машинах Waymo - многие из них без водителей! Wing стала первой беспилотной компанией, которая осуществила коммерческие поставки для потребителей в США. И Verily и Calico делают важную работу, благодаря сотрудничеству с рядом других медицинских компаний. Некоторые из наших "Других ставок" имеют собственные советы директоров с независимыми членами и внешними инвесторами.

Это лишь несколько примеров технологических компаний, которые мы создали в рамках Alphabet, в дополнение к инвестиционным дочерним компаниям GV и Capital G, которые поддержали еще сотни компаний. Вместе со всеми сервисами Google это формирует красочный набор ставок на технологии в различных отраслях промышленности - и все это с целью помочь людям и решить основные проблемы.

Наше второе письмо основателей было начато так:

Google родился в 1998 году. Если бы это был человек, то начальную школу он бы начал в конце лета прошлого года (около 19 августа), а сегодня почти закончил бы первый класс.

Сегодня, в 2019 году, если бы компания была человеком, ей бы исполнился 21 год, и пришло время покинуть покой. Хотя для нас было огромной честью принимать активное участие в повседневном управлении компанией так долго, мы считаем, что пришло время взять на себя роль гордого родителя, предлагающего советы и любовь, но не ворчащего каждый день!

Теперь, когда Alphabet хорошо зарекомендовал себя, а Google и другие компании эффективно работают как независимые компании, настало подходящее время упростить нашу структуру управления. Мы никогда не держались за руководящие должности, когда думали, что есть лучший способ управлять компанией. А Alphabet и Google больше не нуждаются в двух генеральных директорах и президенте. В дальнейшем Сундар будет генеральным директором как Google, так и Alphabet. Он будет отвечать за руководство компанией Google и управление инвестициями компании в наши "Другие ставки", а также отвечать за руководство компанией. Мы глубоко привержены принципам Google и Alphabet в долгосрочной перспективе и будем продолжать активно работать в качестве членов Совета директоров, акционеров и соучредителей. Кроме того, мы планируем продолжать регулярно общаться с Сундаром, особенно на темы, которые нас очень интересуют!

Сундар несет смирение и глубокую страсть к технологиям нашим пользователям, партнерам и нашим сотрудникам каждый день. Он тесно сотрудничал с нами в течение 15 лет, создавая компанию Alphabet в качестве генерального директора Google и члена совета директоров компании Alphabet. Он разделяет нашу уверенность в ценности структуры Alphabet и в том, что она дает нам возможность решать большие задачи с помощью технологий. Нет никого, на кого мы могли бы положиться с момента основания Alphabet, и нет человека, который мог бы лучше вести Google и Alphabet в будущее.

Мы глубоко смирились с тем, что небольшой исследовательский проект превратился в источник знаний и возможностей для миллиардов людей, ставку, которую мы сделали в качестве двух студентов Стэнфордского университета и которая привела к множеству других технологических ставок. Мы и представить себе не могли, в 1998 году, когда мы переместили наши серверы из общежития в гараж, путешествие, которое должно было последовать за этим.

Во вторник, 3 декабря, Сундар отправил следующее письмо всем сотрудникам компании Google:

Привет всем,

Когда несколько недель назад я посетил сотрудников Google в Токио, я говорил о том, как Google изменился за эти годы. На самом деле, за 15 с лишним лет работы в Google, единственное постоянство, что я наблюдал, это перемены. Этот процесс непрерывной эволюции, который основатели часто называют "неудобно захватывающим", является частью того, кем мы являемся. Это утверждение будет особенно актуально сегодня, когда вы прочтетете новости, которые Ларри и Сергей только что опубликовали в нашем блоге.

Ключевая идея, которую разделяют Ларри и Сергей, заключается в следующем:

Хотя для нас было огромной честью принимать активное участие в повседневном управлении компанией так долго, мы считаем, что пришло время взять на себя роль гордого родителя, предлагающего советы и любовь, но не ворчащего каждый день!

Теперь, когда Alphabet хорошо зарекомендовал себя, а Google и другие компании эффективно работают как независимые компании, настало подходящее время упростить нашу структуру управления. Мы никогда не держались за руководящие должности, когда думали, что есть лучший способ управлять компанией. А Alphabet и Google больше не нуждаются в двух генеральных директорах и президенте. В дальнейшем Сундар будет генеральным директором как Google, так и Alphabet. Он будет отвечать за руководство компанией Google и управление инвестициями компании в наши "Другие ставки", а также отвечать за руководство компанией. Мы глубоко привержены принципам Google и Alphabet в долгосрочной перспективе и будем продолжать активно работать в качестве членов Совета директоров, акционеров и соучредителей. Кроме того, мы планируем продолжать регулярно общаться с Сундаром, особенно на темы, которые нас очень интересуют!

Впервые я встретился с Ларри и Сергеем еще в 2004 году и с тех пор пользуюсь их советами и идеями. Хорошая новость заключается в том, что я буду продолжать работать с ними, хотя и в разных ролях для них и для меня. Они будут продолжать консультировать как членов совета директоров, так и соучредителей.

Я хочу, чтобы было ясно, что этот переход не повлияет на структуру Alphabet и работу, которую мы выполняем изо дня в день. Я буду продолжать уделять большое внимание Google и той глубокой работе, которую мы проводим для расширения границ вычислений и создания более полезного Google для всех. В то же время, я очень рад за Alphabet и его долгосрочной ориентации на решение больших задач с использованием современных технологий.

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

— Сундар

Because I couldn't find proper and working documentation for installing mongoDB on Debian 10 (Buster), I thought it would be useful to describe how I literally lost time with it.

Prerequisites

This guide assumes that you are using Debian 10. Before you begin, you should have a non-root user with sudo privileges set up on your system. You can learn how to set this up by following the initial server setup for Debian 10 tutorial.

Step 1. Add MongoDB repository

At the moment, the mongoDB repository simply doesn't have a stable version 4 of the database for Debian 10, so we'll have to go round the clock and look for everything ourselves (good thing I already did).

First, we need to add the MongoDB signing key with apt-key add. We’ll need to make sure the curl command is installed before doing so:

~$ sudo apt install curl

Next we download the key and pass it to apt-key add:

~$ curl https://www.mongodb.org/static/pgp/server-4.4.asc | sudo apt-key add -

Next we’ll create a source list for the MongoDB repo, so apt knows where to download from. To do this, we execute the command:

~$ echo "deb http://repo.mongodb.org/apt/debian buster/mongodb-org/development main" | sudo tee /etc/apt/sources.list.d/mongodb-org.list

Step 2. Install libcurl3

The libcurl3 package is required by mongodb-org-server. Since the default version for Debian 10 is libcurl4, this package will be downloaded from added Debian 9 repository. To return the curl command to work, follow the steps described in this article.

~$ echo "deb http://deb.debian.org/debian/ stretch main" | sudo tee /etc/apt/sources.list.d/debian-stretch.list
~$ sudo apt update
~$ sudo apt -y install libcurl3

Step 3. Install MongoDB Server on Debian 10 (Buster)

We have added required repositories and installed libcurl3. Let’s now install MongoDB Server on Debian 10 (Stretch).:

~$ sudo apt -y install mongodb-org

Get package information with apt info command.

~$ apt info mongodb-org
Package: mongodb-org
Version: 4.2.1~latest
Priority: optional
Section: database
Maintainer: Ernie Hershey <ernie.hershey@mongodb.com>
Installed-Size: 13.3 kB
Depends: mongodb-org-shell, mongodb-org-server, mongodb-org-mongos, mongodb-org-tools

The installation of the above package will install the following dependency packages:

mongodb-org-server – This provides MongoDB daemon mongod
mongodb-org-mongos – This is a MongoDB Shard daemon
mongodb-org-shell – This provides a shell to MongoDB
mongodb-org-tools – MongoDB tools used for export, dump, import etc

Step 4. Start MongoDB Server on Debian 10 (Buster)

The server daemon is named mongod. Start and set it to start on server reboot/boot up:

~$ sudo systemctl enable --now mongod

Check its running status:

~$ sudo systemctl status mongod
● mongod.service - MongoDB Database Server
   Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-10-18 14:53:55 MSK; 4s ago
     Docs: https://docs.mongodb.org/manual
 Main PID: 6596 (mongod)
   Memory: 78.5M
   CGroup: /system.slice/mongod.service
           └─6596 /usr/bin/mongod --config /etc/mongod.conf

Oct 18 14:53:55 220943.simplecloud.ru systemd[1]: Started MongoDB Database Server.

If you have caught an error the first time you run it, the following steps are likely to help you:

~$ sudo systemctl stop mongod
~$ sudo rm -rf /var/lib/mongodb
~$ sudo mkdir /var/lib/mongodb
~$ sudo chown -R mongodb:mongodb /var/lib/mongodb
~$ sudo systemctl start mongod

The service listens on localhost TCP port 27017 by default, check it:

~$ ss -tunelp
Netid            State             Recv-Q            Send-Q                             Local Address:Port                          Peer Address:Port
udp              UNCONN            0                 0                             96.123.217.94%eth0:68                                 0.0.0.0:*                uid:102 ino:82671 sk:1 <->
udp              UNCONN            0                 0                                        0.0.0.0:68                                 0.0.0.0:*                ino:14242 sk:2 <->
tcp              LISTEN            0                 128                                      0.0.0.0:22                                 0.0.0.0:*                ino:15174 sk:3 <->
tcp              LISTEN            0                 128                                    127.0.0.1:27017                              0.0.0.0:*                uid:106 ino:259576 sk:7 <->
tcp              LISTEN            0                 128                                      0.0.0.0:80                                 0.0.0.0:*                ino:144683 sk:4 <->
tcp              LISTEN            0                 128                                         [::]:22                                    [::]:*                ino:15185 sk:5 v6only:1 <->
tcp              LISTEN            0                 128                                         [::]:80                                    [::]:*                ino:144684 sk:6 v6only:1 <->

That's all, thanks for reading.

Ричард Варбертон из Opsian имел честь встретиться с Алексеем Шипилевым и узнать его мнения по целому ряду вопросов. В первой части интервью Алексей и Ричард обсуждают текущее состояние обновлений JDK.

Ричард: Для тех, кто не знает, кто вы есть, не желаете ли вы представиться или рассказать нам немного о себе?

Алексей: Привет, я Алексей Шипилев, занимаюсь Java и производительностью уже около 15 лет. Вероятно, я могу перечислить проекты, в которых я принимал участие в OpenJDK: различные инструменты, такие как JMH, JCStress и JOL. Я сделал несколько параллельных тестов, провел общую работу по повышению производительности и некоторые из них включали в себя JEP. После работы в Red Hat я также работал с Epsilon и Shenandoah и помогаю с обновлениями OpenJDK для Red Hat.

Ричард: Точно. И вы бы сказали, что большую часть времени проводите в эти дни, работая над Shenandoah?

Алексей: Я бы сказал, что это половина с половиной: Я трачу половину своего времени на работу с Shenandoah, а половину - на общую работу в JVM. Последние несколько месяцев были заняты выпуском обновлений с первой волной исправлений после того, как Red Hat взял на себя техобслуживание 8u и 11u. Мы надеемся, что сейчас объем работы снизится, поэтому я бы тратил на это, может быть, день в неделю, или что-то в этом роде. Но да, до сих пор я провожу много времени, занимаясь выпуском обновлений.

Ричард: Так наверное, это хорошее место для начала, потому что я думаю, что в Java сообществе в целом довольно много путаницы по поводу того, что происходит на самом деле с обновлениями. Существует множество " не бесплатных обновлений, не безопасности", много забот и всего остального. Я знаю, что есть несколько человек, которые выпустили более подробную документацию или информацию - возможно, вы захотите объяснить, что вы делаете и что Red Hat делает в этих обновлениях?

Алексей: Я думаю, что существует путаница вокруг того, что такое OpenJDK. Есть OpenJDK "проект" и OpenJDK "дистрибутив". Путаница в том, что в дистрибутиве нет золотого двоичного кода для OpenJDK. Сайт OpenJDK не содержит двоичных файлов, что означает, что для создания сборки вам придется полагаться на нижестоящие дистрибутивы. [Редактор: Red Hat начал публиковать ванильные сборки на https://adoptopenjdk.net/upstream.html через некоторое время после этого интервью.]

Во времена Sun/Oracle, это было обычное Sun/Oracle производство собственных нижестоящих дистрибутивов JDK на основе OpenJDK исходников. Недавно компания Oracle решила реализовать свои собственные разработки только при наличии коммерческой поддержки. Они также любезно публикуют сборки OpenJDK на своем сайте https://jdk.java.net/

Будучи поставщиком нижестоящих версий, как и все остальные, Oracle вольна выбирать, какие сборки публиковать. И на данный момент они предпочитают публиковать только последние сборки OpenJDK 12. Если вы хотите 11u или 8u от Oracle, вы должны пойти на их коммерческое предложение. Но это и есть часть Oracle, также существуют другие участники экосистемы, которые используют OpenJDK в качестве проекта, то есть репозитории исходных кодов, которые находятся в открытом доступе, и создают из них свои 8u и 11u бинарные файлы. Их много, включая, но не ограничиваясь ими, Red Hat, SAP, AdoptOpenJDK и т.д.

Теперь вопрос в том, что содержат эти бинарные файлы? На это есть два ответа. Во-первых, существуют репозитории с открытым исходным кодом для 8u и 11u, из которых вы можете создавать свои сборки. Во-вторых, некоторые производители предпочитают применять некоторые дополнительные патчи, поскольку, например, не могут дождаться появления патча, чтобы он появился в потоке, а затем предоставить его своим пользователям. Тем не менее, я полагаю, что существует внутреннее давление на процесс распространения этих патчей, поскольку это помогает сбалансировать нагрузку на работу над обновлениями.

Когда вы услышите новость о том, что Red Hat "принимает" права собственности на релизы 8u и 11u - это новость об Эндрю Хейли, который является официальным лидером проекта в этих проектах обновления OpenJDK. Речь идет скорее об официальной роли, которая делает Red Hat официально ответственным за эти исходные деревья и процессы вокруг них. Фактическая работа выходит за рамки этих формальностей. Если вы посмотрите, что там делается для текущей версии 8u212 и 11.0.3, вы увидите, что в то время как Red Hat выполняет значительную часть бэкпортных исправлений, есть и другие команды и другие компании, в частности SAP, которые очень активны. Другие производители, такие как Amazon и Google, также принимают активное участие в проекте.

Существует общая площадка, где поставщики могут сотрудничать в выпусках обновлений, а затем создавать их на основе вышестоящего репозитория. Так что их собственные бинарные файлы 8u и 11u обычно сходятся в OpenJDK. Некоторые могут захотеть изобразить его как бесплатные джунгли для всех, когда у вас несколько поставщиков и вы не знаете, какой поставщик что поставляет, но в действительности большинство поставщиков действительно работают через этот вышестоящий процесс 8u и 11u, и таким образом в основном соглашаются, какие они имеют исходники.

Думаю, это отвечает на вопрос о бесплатных обновлениях и бесплатных исправлениях ошибок. Исходные коды обновляются в рамках процесса обновления OpenJDK. Выберите производителя, который предоставляет вам бесплатные сборки (большинство из них) из тех исходников, и вы получите бесплатные обновления.

Ричард: Понятно. Таким образом, практическое значение для Java-разработчика заключается в том, что он все еще может использовать Java-приложение и запускать его на JVM разных производителей. И они вольны выбрать того, кто предложит лучший вариант поддержки по договору и процессу и тому подобное?

Алексей: Да, спецификация... Я имею в виду, есть обязательное тестирование, которое каждый релиз должен пройти под названием Java. Обычно поставщики проводят дополнительные тесты дополнительно к этому. Я надеялся на такой же уровень совместимости с другими версиями JDK.

Если вы очень внимательно посмотрите на списки исправлений, публикуемые производителями, или на то, как они описывают свое отклонение от вышестоящих версий, то эти исправления окажутся незначительными. Например, вещи, которые помогают им встраивать в свою среду, предоставляют дополнительные сертификаты CA или делают что-то другое, что не является исправлением совместимости. Некоторые из них являются исправлениями ошибок или производительности, которые уже находятся в процессе обновления, но еще не перенесены в ванильный исходный код, который вы можете собрать прямо сейчас.

Ричард: Интересно, интересно. Ну, это немного меняющаяся экосистема для разработчиков Java, и им нужно понять, как адаптироваться и куда лучше всего двигаться.

Алексей: Да, я имею в виду, для некоторых людей. Другие, как и многие люди, работающие под Linux, с незапамятных времен привыкли иметь бинарные файлы OpenJDK от своих дистрибутивов, поскольку это было для них самым простым решением. Дистрибутивы Linux обычно собирают OpenJDK для вас. Полагаю, это в основном культурный сдвиг. До этого, только пользователи Linux привыкли к тому, что это был необязательный шаг, чтобы скачать бинарный файл Oracle со своего сайта...

Ричард: Точно, да, вы можете просто воспользоваться пакетом дистрибутива.

Алексей: Да. Для всех остальных, посещение Oracle было первым выходом, верно? Например, если вам нужен Java на рабочем столе Windows. Итак, то, что мы видим сейчас, это переход от менталитета одного производителя к менталитету Linux, когда вы выбираете провайдера, который предоставляет вам дистрибутив для продукта, в таких условиях, которые вам нравятся: платформы, для которых они собираются, частота/ оперативность выпуска, структура поддержки и т.д. Если вы не доверяете ни одному из существующих поставщиков, вы даже можете собрать OpenJDK самостоятельно и запустить его.

Ричард: И как бы вы прокомментировали, например, существующие дистрибутивы Linux и степень предоставляемого ими тестирования совместимости? Я имею в виду, вы упомянули, что Red Hat, очевидно, имеет большой доступ к тестированию, и как вы думаете, все ли дистрибутивы этого добиваются?

Алексей: Я не знаю, что именно дистрибутивы делают, но большинство из них строятся из одних и тех же исходных деревьев. Так что, если вы являетесь пользователем дистрибутива, то, вероятно, в ваших интересах пойти и спросить их об этом. По словам Эндрю Хейли: если вы не можете доверять пакету, который собирает ваш дистрибутив, то, возможно, вам не стоит использовать этот дистрибутив в первую очередь.

Ричард: Возможно. Да.

Алексей: Итак, да, если у вас есть сомнения относительно того, какие продукты входят в дистрибутив вашей операционной системы, тогда идите и спросите разработчиков, что находится в нем. Я бы сказал, что поскольку существует общая база кода для большинства сборщиков OpenJDK, то даже если вы вообще не будете тестировать и просто опубликуете бинарный файл и позволите пользователям установить его, существует очень большая вероятность, что непроверенный выпуск не будет нарушен. Поставщики, которые проводят тестирование, будут исправлять ошибки и публиковать исправления в деревьях исходных кодов.

Ричард: Да.

Алексей: Недочеты могут появиться, если ваша инструментальная связка слегка отличается от любой другой, такие вещи случаются. Я бы сказал, что скорость Red Hat в основном была протестирована так: мы собираем OpenJDK в виде RPM, а затем тестируем его. Поэтому мы уверены, что созданные нами бинарные файлы на самом деле проходят все тесты. Я не думаю, что это уникальная ситуация. Я думаю, это то же самое предложение для любого поставщика бинарных файлов: вы собираете что-то, проверяете, что бинарные программы работают, а затем вы публикуете их...

Ричард: Ага.

Алексей: Так что спросите у своего поставщика. Различия должны быть незначительными.

На этом завершаем первую часть нашего интервью с Алексеем. Мы все еще готовим вторую часть, в которой речь пойдет о параллельных сборщиках мусора и Shenandoah в частности. Это будет в прямом эфире на следующей неделе, так что не забудьте.

Мы хотели бы поблагодарить Алексея за то, что он уделил нам немного времени и посидел с нами, чтобы поделиться своими мыслями.

Источник: раз, и еще ссылки на различные OpenJDK сборки со StackOverflow: два.

Я рад представить плагины всему сообществу Figma, вместе с сотнями разработчиков, которые создали и опубликовали плагины во время нашей бета-версии. Сегодня все пользователи могут использовать эти плагины, разработанные нашим сообществом, и создавать свои собственные плагины, адаптированные к их рабочим процессам.

Большую часть своей профессиональной карьеры я посвятил разработке инструментов, которые позволяют другим людям создавать вещи. Предоставление другим людям возможности творческого подхода - это весело для меня, и работа над расширяемыми архитектурами - еще более веселая версия этого.

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

1. Хотя разработчики используют плагины, они не всегда надежны и безопасны. Это связано с тем, что они часто построены на не полностью поддерживаемых API.
2. Дизайнеры находятся во власти других, чтобы создавать плагины для них, если они сами не знают, как писать код. И получить инженерно-технические знания всегда непросто.

К счастью, мне пришлось работать с супер талантливыми инженерами и разработчиками плагинов из нашего сообщества, чтобы помочь решить эти проблемы. Конечно, мы хотели, чтобы наши плагины были безопасными, стабильными и работоспособными. Но мы также хотели, чтобы программирование плагинов Figma было похоже на веб-программирование. Наш внутренний девиз - "Если вы можете запрограммировать веб-страницу с помощью базовых HTML и JavaScript, вы можете создать плагин Figma."

Получается, что для этого возникло много технических сложностей (о которых мы поговорим в одном из последующих технических блогов). Нам также впервые пришлось выяснить, как выглядит архитектура плагина для веб-платформы, когда речь заходит об инструментах проектирования. Но при такой архитектуре платформы плагинов мы надеялись, что эти первоначальные затраты позволят большему числу создателей плагинов создавать более креативные, интересные плагины.

Плагины Figma обеспечивают легкость защиты себя и других, давая мне возможность создавать необходимые инструменты проектирования, а не скрещивать пальцы, надеясь, что кто-то другой сделает их за нас.
— Тиффани Чен, дизайнер UX Designer в Microsoft

Всего через 6 недель бета-тестирования, у нас появилось более 40 публичных плагинов, доступных для сообщества Figma, с каждым днем их становится все больше. Вы можете просмотреть все плагины прямо в программе Figma. Установка плагина займет всего один клик. В своем проектном файле просто щелкните правой кнопкой мыши, чтобы получить все доступные плагины.

Источник статьи, а также ссылка на мой репозиторий на Github, где я начал перевод документации Plugin API.

И следом за одним переводом, перевод другой статьи, но уже про работу GIL в Python.

Проще говоря, Python Global Interpreter Lock или GIL — это мьютекс (или замок), который позволяет только одному потоку контролировать интерпретатор Python.

Это означает, что только один поток может находиться в состоянии выполнения в любой момент времени. Влияние GIL не заметно разработчикам, выполняющим однопоточные программы, но оно может быть узким местом в многопоточном коде, привязанном к процессору.

Поскольку GIL позволяет выполнять только один поток одновременно даже в многопоточной архитектуре с более чем одним ядром процессора, GIL завоевал репутацию "печально известной" функции Python.

В этой статье вы узнаете, как GIL влияет на производительность ваших программ Python, и как вы можете смягчить его влияние на ваш код.

Какую проблему GIL решил для Python?

Python использует подсчет ссылок для управления памятью. Это означает, что объекты, созданные в Python, имеют переменную счетчика ссылок, которая отслеживает количество ссылок, указывающих на объект. Когда это число достигает нуля, освобождается память, занимаемая объектом.

Давайте рассмотрим краткий пример кода, чтобы продемонстрировать, как работает подсчет ссылок:

>>> import sys
>>> a = []
>>> b = a
>>> sys.getrefcount(a)
3

В приведенном выше примере счетчик ссылок для объекта пустого списка [] равен 3, объект списка ссылается на a, b и аргумент переданный в sys.getrefcount().

Вернемся к GIL:

Проблема заключалась в том, что эта переменная числа ссылок нуждалась в защите от состояния гонки, когда два потока одновременно увеличивают или уменьшают свое значение. Если это произойдет, то это может привести либо к утечке никогда не высвобождающейся памяти, либо, что еще хуже, к некорректному освобождению памяти при сохранении ссылки на этот объект. Это может привести к сбоям или другим "странным" ошибкам в ваших программах Python.

Эта переменная счетчика ссылок может быть сохранена путем добавления блокировок во все структуры данных, которые являются общими для всех потоков, чтобы они не изменялись непоследовательно.

Но добавление блокировки к каждому объекту или группам объектов означает, что будет существовать несколько блокировок, что может привести к другой проблеме deadlock'ов (блокировка может произойти только при наличии нескольких блокировок). Еще одним побочным эффектом было бы снижение производительности, вызванное повторным приобретением и разблокировкой замков.

GIL - это единственный замок на самом интерпретаторе, который добавляет правило, что выполнение любого байт-кода Python требует получения блокировки интерпретатора. Это предотвращает возникновение тупиковых ситуаций (поскольку существует только один замок) и не приводит к значительным накладным расходам. Но это эффективно делает любую программу Python, привязанную к процессору, однопоточной.

GIL, хотя и используется переводчиками для других языков, таких как Ruby, но это не единственное решение этой проблемы. Некоторые языки избегают необходимости использования GIL для управления поточно безопасной памятью, используя подходы, отличные от подсчета ссылок, такие как сбор мусора.

С другой стороны, это означает, что этим языкам часто приходится компенсировать потерю однопоточных преимуществ производительности GIL, добавляя другие функции повышения производительности, такие как компиляторы JIT.

Почему в качестве решения был выбран именно GIL?

Итак, почему подход, который кажется таким мешающим, использовался в Python? Было ли это плохое решение разработчиков Python?

Ну, по словам Ларри Гастингса, дизайнерское решение GIL сделало Python таким же популярным, как и сегодня.

Python существует со времен, когда операционные системы не имели понятия потоков. Python был разработан для простоты использования, чтобы сделать разработку более быстрой, и все больше и больше разработчиков начали использовать его.

Много расширений было написано для существующих библиотек на языке С, возможности которых были необходимы в Python. Для предотвращения непоследовательных изменений эти расширения C требовали управления памятью, обеспечиваемого GIL, в соответствии с требованиями безопасности потока.

GIL прост в реализации и был легко добавлен в Python. Это обеспечивает повышение производительности однопоточных программ, так как необходимо управлять только одной блокировкой.

Библиотеки языка С, которые не были потоко-безопасными, стало легче внедрять. И эти расширения C стали одной из причин, по которым Python был легко принят различными сообществами.

Как вы видите, GIL был прагматичным решением сложной проблемы, с которой разработчики CPython столкнулись в самом начале жизни Python.

Влияние на многопоточные программы Python

Когда вы смотрите на типичную программу Python - или любую другую компьютерную программу для этой цели - есть разница между теми, которые привязаны к процессору, в производительности и теми, которые привязаны к вводу/выводу.

Связанные с процессором программы - это те, которые толкают процессор до предела. Сюда входят программы, выполняющие математические вычисления, такие как умножение матриц, поиск, обработка изображений и т.д.

I/O-связанные программы — это те, которые проводят время в ожидании ввода/вывода, который может исходить от пользователя, файла, базы данных, сети и т.д. Иногда программам ввода-вывода приходится ждать значительное количество времени, пока они получат то, что им нужно от источника, из-за того, что источнику может понадобиться сделать свою собственную обработку, прежде чем ввод/вывод будет готов, например, пользователь подумает о том, что делать во входной запрос или запрос к базе данных, выполняемый в его собственном процессе.

Давайте посмотрим на простую программу, привязанную к процессору и выполняющую обратный отсчет:

# single_threaded.py
# однопоточный
import time
from threading import Thread

COUNT = 50000000

def countdown(n):
    while n > 0:
        n -= 1

start = time.time()
countdown(COUNT)
end = time.time()

print('Время в секундах -', end - start)

Выполнение этого кода на моем компьютере с 4 ядрами дало следующий результат:

$ python single_threaded.py
Время в секундах - 6.20024037361145

Теперь я немного изменил код, чтобы сделать то же самое с обратным отсчетом, используя два параллельных потока:

# multi_threaded.py
# многопоточный

import time
from threading import Thread

COUNT = 50000000

def countdown(n):
    while n > 0:
        n -= 1

t1 = Thread(target=countdown, args=(COUNT//2,))
t2 = Thread(target=countdown, args=(COUNT//2,))

start = time.time()
t1.start()
t2.start()
t1.join()
t2.join()
end = time.time()

print('Время в секундах -', end - start)

И потом, когда я запустил его снова:

$ python multi_threaded.py
Время в секундах - 6.924342632293701

Как видите, обе версии занимают почти одинаковое количество времени для завершения. В многопоточной версии GIL предотвращал параллельное выполнение потоков, связанных с CPU.

GIL не оказывает значительного влияния на производительность многопоточных программ, так как блокировка разделяется между потоками, пока они ожидают ввода/вывода.

Однако программа, потоки ��оторой полн��стью привязаны к процессору, например, программа, обрабатывающая образ по частям с помощью потоков, не только станет однопоточной из-за блокировки, но и увеличит время выполнения, как показано в приведенном выше примере, по сравнению со сценарием, в котором она была написана как полностью однопоточная.

Это увеличение является результатом увеличения накладных расходов, связанных с блокировкой.

Почему GIL еще не удалили?

Разработчики Python получают множество жалоб по этому поводу, но такой популярный язык, как Python, не может принести таких значительных изменений, как удаление GIL, не вызывая проблем с обратной несовместимостью.

Очевидно, что GIL может быть удален, и это делалось несколько раз в прошлом разработчиками и исследователями, но все эти попытки сломали существующие расширения C, которые сильно зависят от решения, которое предоставляет GIL.

Конечно, есть и другие решения проблемы, которые решает GIL, но некоторые из них снижают производительность однопоточных и многопоточных программ ввода-вывода, а некоторые из них слишком сложны. В конце концов, вы же не хотите, чтобы ваши существующие программы Python работали медленнее после выхода новой версии, не так ли?

Создатель и BDFL (Великодушный пожизненный диктатор) Python Гвидо ван Россум в своей статье "Нелегко удалить GIL" в сентябре 2007 года дал ответ сообществу:

"Я бы приветствовал набор патчей к Py3k только в том случае, если бы производительность однопоточной программы (и многопоточной, но связанной с вводом/выводом программы) не снизилась"

И это условие не было выполнено ни одной из попыток, предпринятых с тех пор.

Почему его не удалили в Python 3?

У Python 3 был шанс запустить множество функций с нуля, и в процессе работы он сломал некоторые из существующих расширений C, которые затем потребовали обновления и портирования для работы с Python 3. Именно по этой причине ранние версии Python 3 были приняты сообществом не так быстро.

Но почему GIL не был удален вместе с ним?

Удаление GIL сделало бы Python 3 медленнее по сравнению с Python 2 в однопоточной производительности, и вы можете себе представить, к чему бы это привело. Вы не можете спорить с преимуществами однопоточной производительности GIL. В результате у Python 3 остался GIL.

Но Python 3 действительно привнес значительные улучшения в существующий GIL...

Мы обсудили влияние GIL на "только CPU-связанные" и "только I/O-связанные" многопоточные программы, но как насчет программ, где некоторые потоки являются I/O-связанными, а некоторые CPU-связанными?

В таких программах GIL Python был известен тем, что не давал возможности получить GIL из потоков, связанных с процессором, что приводило к потере связи между вводом/выводом и выводом данных.

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

>>> import sys
>>> # Интервал установлен в 100 команд:
>>> sys.getcheckinterval()
100

Проблема в этом механизме заключалась в том, что большую часть времени процессорный поток перезагружал сам GIL, прежде чем другие потоки могли его получить. Это было исследовано Дэвидом Бизли и визуализации, которую можно найти здесь.

Эту проблему в версии Python 3.2 в 2009 году исправил Антуан Питру, добавив механизм просмотра количества запросов на получение GIL другими потоками, которые были удалены, и не позволив текущему потоку перезагрузить GIL до того момента, пока у других потоков не появится возможность его запустить.

Как справиться с GIL в Python

Если GIL вызывает у вас проблемы, попробуйте несколько подходов:

Мультипроцессорная обработка по сравнению с многопоточной: Наиболее популярным способом является использование мультипроцессорного подхода, при котором вместо потоков используется несколько процессов. Каждый процесс Python получает свой собственный интерпретатор Python и область памяти, так что GIL не будет проблемой. Python имеет модуль multiprocessing, который позволяет нам легко создавать подобные процессы:

from multiprocessing import Pool
import time

COUNT = 50000000
def countdown(n):
    while n>0:
        n -= 1

if __name__ == '__main__':
    pool = Pool(processes=2)
    start = time.time()
    r1 = pool.apply_async(countdown, [COUNT//2])
    r2 = pool.apply_async(countdown, [COUNT//2])
    pool.close()
    pool.join()
    end = time.time()
    print('Время в секундах -', end - start)

Запуск этой программы в моей системе дал такой результат:

$ python multiprocess.py
Время в секундах - 4.060242414474487

Приличный прирост производительности по сравнению с многопоточной версией, верно?

Время не сократилось до половины того, что мы видели выше, потому что управление процессами имеет свои накладные расходы. Несколько процессов тяжелее, чем несколько потоков, поэтому имейте в виду, что это может стать узким местом в масштабировании.

Альтернативные интерпретаторы Python: У Python имеется несколько реализаций интерпретаторов. Наиболее популярными из них являются CPython, Jython, IronPython и PyPy, написанные на C, Java, C# и Python соответственно. GIL существует только в оригинальной реализации Python - CPython. Если ваша программа с библиотеками доступна для одной из других реализаций, то вы также можете попробовать их.

Просто подождите: В то время как многие пользователи Python используют преимущества однопоточной производительности GIL. Многопоточным программистам не нужно беспокоиться, так как одни из самых ярких умов сообщества Python работают над удалением GIL из CPython. Одна из таких попыток известна под названием "Gilectomy".

Python GIL часто рассматривается как загадочная и сложная тема. Но имейте в виду, что как на Pythonista, на вас это обычно влияет, только если вы пишете расширения на C или если вы используете многопоточный процессор в ваших программах.

В этом случае, эта статья должна дать вам все, что вам нужно, чтобы понять, что такое GIL и как с ним обращаться в ваших собственных проектах. И если вы хотите понять низкоуровневую внутреннюю работу GIL, я бы порекомендовал вам посмотреть выступление Дэвида Бизли "Понимание работы GIL в Python".

В надежде все-таки перенести свой сайт на иную платформу, мне как-то стало лень, и я решил остаться временно здесь. Тем более мне здесь вполне комфортно. Итак, продолжим мы молгое молчание с перевода статьи про то, как сильно изменился PHP к 2019 году и продолжает развивается.

Помните популярную заметку в блоге "PHP: фрактал плохого дизайна"? Впервые прочитав ее, я работал в ужаснейшем месте с большим количеством legacy-проектов на PHP. Эта статья заставила меня задуматься, что мне стоит просто уйти и заняться чем-то совершенно иным, ежели программированием.

К счастью для меня, я смог поменять работу сразу после увольнения, и, что более важно, PHP удалось развиться довольно быстро с тех пор, как он был еще версии 5.*. Сегодня я обращаюсь к людям, которые либо больше не программируют на PHP, либо застряли в legacy-проектах.

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

Сегодня я хочу посмотреть на положительные стороны: давайте сосредоточимся на том, что изменилось, и на том, как написать чистый и удобный для обслуживания PHP-код. Я хочу попросить вас отложить любые предрассудки на несколько минут.

После этого вы можете думать о PHP точно так же, как и раньше. Хотя есть шансы на то, что вы будете удивлены некоторыми улучшениями, внесенными в PHP за последние несколько лет.

TL;DR

• PHP активно развивается с каждым новым релизом каждый год
• Производительность с момента появления PHP 5 удвоилась, если не утроилась
• Существует крайне активная экосистема фреймворков, пакетов и платформ
• За последние несколько лет в PHP было добавлено много новых функций, и язык продолжает развиваться
• Инструменты, такие как статические анализаторы, выросли за последние годы и только продолжают расти

Update: Люди попросили меня показать какой-либо реальный код. Я рад сообщить, что это возможно! Вот исходный код одного из моих хобби-проектов, написанный на PHP и Laravel; вот список из нескольких сотен OSS пакетов, которые мы поддерживаем в нашем офисе. Оба являются хорошими примерами того, как выглядят современные PHP-проекты.

Давайте начнем.

История в целом

Для хорошей оценки, давайте быстро рассмотрим цикл выпуска PHP на сегодняшний день. Сейчас мы на PHP версии 7.3, 7.4 ожидается в конце 2019 года. PHP 8.0 будет следующей версией после 7.4.

Начиная с конца эры 5.*, основная группа старается поддерживать ежегодный цикл выпуска релизов, и добилась успеха в течение последних четырех лет.

В целом, каждый новый релиз активно поддерживается в течение двух лет и получает еще один год на "исправление проблем безопасности". Цель заключается в том, чтобы мотивировать разработчиков PHP оставаться как можно более современными: небольшие обновления каждый год намного проще, чем, например, переход с версии 5.4 на версию 7.0.

Ознакомиться с активным графиком развития над PHP можно здесь.

И, наконец, PHP 5.6 был последним релизом 5.*, следующим был 7.0. Если вы хотите узнать, что случилось с PHP 6, вы можете послушать подкаст круглого стола PHP.

Разобравшись с этим, давайте опровергнем некоторые распространенные ошибочные представления о современном PHP.

Производительность PHP

Вернувшись в дни версии 5.*, производительность PHP была... в лучшем случае средней. Однако с выходом 7.0 большие куски ядра PHP были переписаны с нуля, что привело к увеличению производительности в два-три раза.

Но слов недостаточно. Давайте посмотрим на бенчмарки. К счастью, другие люди потратили много времени на сравнительный анализ производительности PHP. Я считаю, что у Kinsta имеется хороший обновленный список.

С момента обновления 7.0 производительность только возросла. Настолько, что веб-приложения PHP имеют сопоставимую - в некоторых случаях лучшую - производительность, чем веб-фреймворки на других языках. Взгляните на этот обширный набор тестов.

Конечно, PHP-фреймворки не превзойдут C и Rust, но они работают намного лучше Rails или Django и сравнимы с ExpressJS.

Фреймворки и экосистема

Кстати о фреймворках: PHP больше не просто WordPress. Позвольте мне сказать вам кое-что как профессиональный разработчик PHP: WordPress ни в коей мере не представляет современную экосистему.

В целом, существует два основных фреймворка веб-приложений, и несколько более мелких: Symfony и Laravel. Конечно, есть также Zend, Yii, Cake, Code Igniter и т.д. — но если вы хотите знать, как выглядит современная разработка PHP, вы хорошо справляетесь с одним из этих двух.

Оба этих фреймворка имеют большую экосистему, состоящую из пакетов программ и продуктов. От панелей администрирования или CRM до отдельных пакетов, от CI до профайлеров, от многочисленных сервисов, таких как серверы веб-сокетов, менеджеры очередей, платежные системы; честно говоря, их слишком много, чтобы перечислить.

Однако эти фреймворки предназначены для продолжительного развития. Если вам нужен чистый контент-менеджмент, такие платформы, как WordPress и CraftCMS, совершенствуются все больше и больше.

Одним из способов измерения текущего состояния экосистемы PHP является использование Packagist, основного репозитория пакетов для PHP. Он демонстрирует экспоненциальный рост. Имея ±25 миллионов загрузок в день, может с уверенностью сказать, что экосистема PHP не такая уж маленькая и отстающая экосистема, какой она была раньше.

Посмотрите на этот график с указанием количества пакетов и версий с течением времени. С ним также можно ознакомиться на сайте Packagist.

Помимо фрейворков, приложений и CMS, мы также наблюдаем рост асинхронных фреймворков за последние годы.
Эти фреймворки и серверы, написанные на PHP или других языках, позволяют пользователям запускать по-настоящему асинхронный PHP. Несколько примеров в качестве примеров этого - Swoole, Amp и ReactPHP.

С тех пор как мы осмелились войти в мир асинхронности, такие вещи, как веб-сокеты и приложения с большим количеством I/O, стали актуальными в мире PHP.

Также, шла речь о списке рассылки внутренних почтовых рассылок — месте, где разработчики ядра обсуждают развитие языка — чтобы добавить libuv в ядро. Для тех, кто не знаком с libuv: это та же самая библиотека, которую использует Node.js, чтобы позволить себе всю ее асинхронность.

Сам язык

Хотя async и await еще не доступны, за последние годы язык значительно улучшился. Вот неполный список новых возможностей PHP:

• Короткие замыкания, также называемые функциями стрелок
• Оператор объединения с null
• Трейты
• Типизированные свойства
• Оператор распространения
• JIT-компилятор
• Интерфейс внешних функций
• Анонимные классы
• Объявление типа возвращаемой функцией
• Современная криптография
• Генераторы
• И многое другое

Раз уж мы заговорили об особенностях языка, давайте поговорим о том, как он развивается сегодня. Существует активная основная группа добровольцев, которые продвигают язык вперед, хотя сообществу разрешено предлагать RFC.

Далее, эти RFC обсуждаются в списке рассылки "внутренних устройств", который также можно прочитать в интернете. Перед добавлением новой языковой функции необходимо провести голосование. В ядре допускается только RFC с большинством голосов не менее 2/3.

Существует, вероятно, около 100 человек, которым разрешено голосовать, хотя от вас не требуется голосовать по каждому RFC. Членам основной группы, конечно, разрешено голосовать, они должны вести базу данных. Кроме них, есть группа людей, которые были выбраны индивидуально сообществом PHP. В их число входят сопровождающие документации PHP, участники проекта PHP в целом и известные разработчики в сообществе PHP.

Хотя большая часть основной работы выполняется на добровольной основе, один из основных разработчиков PHP, Никита Попов, недавно был принят на работу в JetBrains для работы над языком на полной ставке. Другой пример — Linux Foundation, который недавно решил инвестировать во фреймворк Zend. Подобные случаи найма и присоединения обеспечивают стабильность для будущего развития PHP.

Инструментарий

Помимо самого ядра, за последние несколько лет мы стали свидетелями увеличения количества инструментов вокруг него. На ум приходят статические анализаторы типа Psalm, созданный Vimeo, Phan и PHPStan.

Эти инструменты будут статически анализировать ваш PHP код и сообщать о любых типах ошибок, возможных ошибках и т.д. В некотором смысле, функциональность, которую они предоставляют, можно сравнить с TypeScript, хотя на данный момент язык не является открытым, поэтому не допускается использование пользовательского синтаксиса.

Несмотря на то, что это означает, что нам нужно полагаться на документарные блоки, Расмус Лердорф, оригинальный создатель PHP, все же упомянул идею добавления в ядро статического анализатора. Несмотря на наличие большого потенциала, это огромная работа.

Кстати, говоря о том, что все это происходит под влиянием сообщества JavaScript; были предприняты усилия по расширению синтаксиса PHP в пользовательском пространстве. Проект под названием Pre делает именно это: разрешает новый синтаксис PHP, который появляется в обычном PHP коде.

Хотя идея и зарекомендовала себя в мире JavaScript, она сможет работать в PHP только при наличии соответствующей поддержки статического и IDE-анализа. Это очень интересная идея, но она должна вырасти, прежде чем можно будет назвать ее "мейнстримом".

В заключение

При этом не стесняйтесь думать о PHP как о дерьмовом языке. Хотя язык, безусловно, имеет свои недостатки и 20-летнее наследие, я могу с уверенностью сказать, что мне нравится работать с ним.

По моему опыту, я могу создать надежное, удобное в обслуживании и качественное программное обеспечение. Клиенты, на которых я работаю, как и я, довольны конечным результатом.

Хотя с PHP все еще можно делать много запутанных вещей, я бы сказал, что это отличный выбор для веб-разработки, если использовать его с умом и правильно.

Разве вы не согласны? Дай мне знать, почему! Вы можете связаться со мной через Twitter или по электронной почте.

Вы едете в машине бизнес-класса, ваша работа заключается в том, чтобы делать автомобили за заказ. Объектно-ориентированный программист говорит вам: "нет проблем, я сделаю чертеж, который я могу использовать, чтобы сделать столько автомобилей, сколько я хочу!"...

class Car
{
    public function drive()
    {
        // ...
    }
}

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

class Car
{
    public function __construct()
    {
        $this->engine = new Engine();

        $this->wheels = [
            new Wheel(), new Wheel(), 
            new Wheel(), new Wheel(),
        ];
    }

    public function drive() { ... }
}

Есть план для каждой машины, которую вы сделаете! Далее, ваш босс приходит к вам и говорит, что есть новый клиент и он хочет электрическую машину.

Так что в конечном итоге вы делаете это.

class ElectricalCar extends Car
{
    public function __construct()
    {
        parent::__construct();

        $this->engine = new ElectricalEngine();
    }
}

"Отличное решение" — думаете вы. Конечно, есть избыточный нормальный двигатель, который создается при вызове parent::__construct(), но, по крайней мере, вы могли бы повторно использовать колеса!

Я думаю, вы понимаете к чему это все приведет. Следующий клиент захочет машину с необычными чехлами на руль, другой бы дизельный двигатель с теми же колпаками, еще один просит гоночной автомобиль, и последний хочет самоуправляемую машину.

О, так был же клиент, который хотел купить двигатель, чтобы построить лодку с самим собой, но Вы сказали своему боссу, что это невозможно.

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

Объектно-ориентированные программисты часто попадают в эту ловушку наследования, заканчивающуюся полностью испорченной кодовой базой. Итак, давайте рассмотрим лучший подход. Может быть, вы слышали о" композиции над наследством" раньше?

Композиция над наследованием является принципом, что классы должны достичь полиморфного поведения и повторного использования кода по их составу, а не наследование от базового или родительского класса — Wikipedia

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

Слово polymorphic буквально означает "много форм" и подразумевает, что автомобиль должен иметь возможность управлять многими различными способами, в зависимости от контекста, в котором он используется.

При повторном использовании кода мы пытаемся сделать код многократно используемым, чтобы в конечном итоге десятки классов не делали почти то же самое.

Какое это имеет отношение к инъекции зависимости?

Вместо того, чтобы сделать уникальный план, который описывает все возможные варианты автомобиля, мы предпочли бы, чтобы Car сделал одну вещь и сделал это хорошо: ездил.

Это означает, что это не должно быть заботой автомобиля о том, как построен его двигатель, какие колеса на нем прикреплены. Он должен знать только следующую вещь:

Учитывая работающий двигатель и четыре колеса, я могу управлять.

Можно сказать, что для того, чтобы Car работал, ему нужны двигатель и колеса. Другими словами: Car зависит от Engine и Wheels.

Эти зависимости должны быть переданы Car. Или, сказал иначе: инъектированы.

class Car
{
    public function __construct(
        Engine $engine, 
        array $wheels
    ) {
        $this->engine = $engine;
        $this->wheels = $wheels;
    }

    public function drive()
    {
        $this->engine->connectTo($this->wheels);

        $this->engine->start();

        $this->engine()->accelerate();
    }
}

Хотите гоночный автомобиль? Нет проблем!

$raceCar = new Car(new TurboEngine(), [
    new RacingWheel(), new RacingWheel(),
    new RacingWheel(), new RacingWheel(),
]);

Тот клиент, которому нужны были специальные крышки для колес? У тебя все под контролем!

$smugCar = new Car(new Engine(), [
    new FancyWheel(), new FancyWheel(),
    new FancyWheel(), new FancyWheel(),
]);

Теперь у вас гораздо больше гибкости!

Dependency injection — это идея дать классу свои требования извне, вместо того, чтобы этот класс отвечал за них сам.

Чего внедрение зависимостей не может

Существуют фреймворки и инструменты, построенные на этом простом принципе и переводящие его на новый уровень. Возможно, вы слышали о них, давайте посмотрим на них ниже.

Общие зависимости

Одним из наиболее полезных побочных эффектов инъекционных зависимостей является то, что внешний контекст может контролировать их. Это означает, что вы можете предоставить один и тот же экземпляр класса нескольким другим, которые имеют зависимость от этого класса.

Зависимые или повторные зависимости, используемые чаще всего, получают метку «dependency injection». Безусловно, очень хорошая практика, но разделение зависимости в сущности не является основным значением инъекции зависимости.

Контейнер зависимостей

Иногда это также называют контейнером «инверсии контроля (inversion of control)», хотя это не точное имя.

Каким бы ни было точное имя, контейнер представляет собой набор определений классов. Это большая коробка, которая знает, как объекты в вашем приложении могут быть созданы с другими зависимостями. Хотя в таком контейнере определенно много вариантов использования, нет необходимости делать инъекции зависимостей.

Автоматическая проводка

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

Здесь много волшебства, но автоматическая проводка может быть полезным инструментом для быстрой разработки приложений.

Расположение службы (Service location)

Вместо того, чтобы вводить зависимости в класс, есть некоторые инструменты и фреймворки, которые позволяют классу просить контейнер «дать ему экземпляр другого класса».

Сначала это может показаться полезным, потому что нашему классу больше не нужно знать, как построить определенную зависимость. Однако: разрешая классу запрашивать зависимости от собственной учетной записи, мы вернемся к квадрату.

Для того, чтобы местоположение службы работало, наш класс должен знать о системах снаружи. Он не сильно отличается от вызова нового в самом классе. Эта идея на самом деле противоположна тому, что пытается сделать инъекция зависимости. Это неправильное использование контейнера.

Инъектировать все подряд

Как это происходит в реальных ��роектах, вы заметите, что инъекция зависимостей не всегда является решением вашей проблемы.

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

Подводя итоги

Основная идея внедрения зависимостей очень проста, она позволяет лучше поддерживать, тестировать и отделять код, который будет написан.

Поскольку это такая мощная модель, что вокруг нее появляется множество инструментов. Я считаю, что главное в начале понять основной принцип, прежде чем использовать инструменты, построенные на нем.